BenF, as Eberhard pointed out in post #3, knowing the processor may not give enough information to determine the capabilities of the board.

But even knowing the board may not be sufficient for a sketch to ensure that all needed resources are available as there is currently no way of determining if and when resources like pins and timers are being used by a library. This is an issue being looked at by the developers but its not an easy one to solve.

Rather than testing if a specific board is in use, if your sketch (or library) depends on analog input 7, you really need a macro that can test if analog 7 exists. Instead of restricting yourself to only a single board which is known to have analog 7, you code would then be compatible with all boards, current and future, which return something useful for analogRead(7).

For example, Firmata has a symbol called TOTAL_ANALOG_PINS, and in Firmata.h there are many #ifdef checks that attempt to define this for all known boards based on CPU type. Forthcoming versions of Firmata (which are available now in a branch within the Firmata svn) have a Boards.h hardware abstraction layer that offers more capabilities, but it's only available to Firmata.

For hardware abstraction symbols to be truly useful for everyone, they need to become part of the core, with "standard" names. As new boards are created, code which uses the hardware abstraction symbols will automatically work. Perhaps more types of abstractions will be needed over time, as completely envisioning all possible abstractions is nearly impossible. But certainly a lot that is commonly needed, like knowing if an analog pin exists, which (if any) digital pin it's shares, which digital pins share analog features, and how many of each exist are pretty easy.

I've been promoting the hardware abstraction idea, without much success, for about 1 year, around the time the Arduino Mega was released. In issue #59 I've posted some simple but very useful symbols.

http://code.google.com/p/arduino/issues/detail?id=59

More are appearing in Firmata, NewSoftSerial, GLCD, and as more libraries try to work on all boards, the need for hardware abstractions will only grow. It's certainly time to standardize on names and start including this stuff in the cores, so as more boards are developed, both by 3rd parties and the Arduino Team, library authors and people who publish widely used examples can start using this stuff.

Long term, rather then locking code to a single board, ways to make such code compatible with all other boards, including those not yet developed, will be a much, much nicer solution.

Long term, rather then locking code to a single board, ways to make such code compatible with all other boards, including those not yet developed, will be a much, much nicer solution.

It would be nice if the IDE had the means to do all that, but it does sound pretty ambitious.

In the mean time developers of user libraries could do us all a favor if they clearly commented on (maybe in the .H file) the hardware assumptions and resources the library requires. I know this is a burden somewhat, and many developers don't always have the means to test their libraries against all the possible board types now supported by the IDE.

It's not so ambitious to add the simplest hardware abstractions, which already exist in issue #59, and are starting to appear in Firmata and NewSoftSerial out of sheer necessity to support different boards. This stuff is just #define of symbols and macros, which do want to be correct, but they don't actually change a single byte of compiled object code within the Arduino core itself.

Ok, yes, it's more ambitious than asking other people to add comments their code. But really, how useful are comments within library header files? Do many users actually read the library headers?