Developer Request: Sketch Require Hardware

Maybe we could have a way to ensure a certain platform from the sketch?
Or possibly to explicity disallow a platform.

Something like:

/*
  Serial echo server for the Arduino Mega

  Uses Serial1

  @require Mega
*/

void setup()
{
   Serial1.begin(9600);
}

void loop()
{
  // if we get a valid byte, read analog ins:
  if (Serial1.available() > 0) {
    Serial1.print( Serial1.read() );
  }
}

AlphaBeta,

I think you could do that now by checking the #define'd processor type. To make it easy, you could define a macro that says, "if processor != desired_type generate compile error"

Regards,

-Mike

Oh.. I know I could do it. :sunglasses: Hehe...

But if I where to share that Sketch with a nonprogrammer, I think I would've gotten some questions about all the #ifndef stuff.

Just an idea to keep things simple and self explanatory.

[edit]Oh the shame! :wink:
Wayoda's post below made me realize I could not do it, even if I used all the preprocessor directives available.[/edit]

I think you could do that now by checking the #define'd processor type.

No you can't. For instance the Duemilanove and the Nano board both have a 328p processor, but only the Nano board supports the analog inputs A6 and A7.

Eberhard

wayoda,

Excellent point. Maybe the request could be to #define a board type, if the IDE doesn't already do this.

Regards,

-Mike

Hi,
since arduino-0018 allows to build sketches for third party boards some generic naming scheme is needed here.

Not even the entries in hardware/arduino/boards.txt can currently provide a distinct name for a board.

Eberhard

Why not add something like this to the top of your sketch?

// Check if compiling for ATmega128, otherwise display error and quit
#ifndef __AVR_ATmega128__
#error "This sketch requires a Mega."
#endif

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.

Excellent point. Maybe the request could be to #define a board type, if the IDE doesn't already do this.

Seconded!

Very good idea this is the kind of thing I was alluding to in my thread on standard hardware platforms. Your is actually a more straight forward and practical idea.

I agree, I posted the same thing before I saw this thread.
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1270214240

It would be very easy to do in "pins_arduino.h" to do
#define BOARD_MEGA etc.

I have already started doing that with the Liquidware core files and a couple other non-standard cores. By putting it in the .h file, no changes have to be made to the Arduino IDE.

Mark

What's really needed are hardware abstractions.

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.

Lefty

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?