Pages: [1]   Go Down
Author Topic: Developer Request: Sketch Require Hardware  (Read 2030 times)
0 Members and 1 Guest are viewing this topic.
Norway@Oslo
Offline Offline
Edison Member
*
Karma: 12
Posts: 2033
loveArduino(true);
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Something like:
Code:
/*
  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() );
  }
}
Logged

Huntsville, Alabama, USA
Offline Offline
Sr. Member
****
Karma: 2
Posts: 327
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Norway@Oslo
Offline Offline
Edison Member
*
Karma: 12
Posts: 2033
loveArduino(true);
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Oh.. I know I could do it. 8-) 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! smiley-wink
Wayoda's post below made me realize I could not do it, even if I used all the preprocessor directives available.[/edit]
« Last Edit: February 16, 2010, 07:46:03 am by AlphaBeta » Logged

Wuppertal/Germany
Offline Offline
God Member
*****
Karma: 1
Posts: 895
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
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
Logged

Huntsville, Alabama, USA
Offline Offline
Sr. Member
****
Karma: 2
Posts: 327
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

wayoda,

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

Regards,

-Mike
Logged

Wuppertal/Germany
Offline Offline
God Member
*****
Karma: 1
Posts: 895
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Offline Offline
Edison Member
*
Karma: 3
Posts: 1001
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

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

London
Offline Offline
Tesla Member
***
Karma: 10
Posts: 6250
Have fun!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Global Moderator
Dallas
Online Online
Shannon Member
*****
Karma: 197
Posts: 12742
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

South Africa
Offline Offline
Full Member
***
Karma: 1
Posts: 141
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

South African Arduino User Group

http://arduino.za.net

USA
Offline Offline
Full Member
***
Karma: 2
Posts: 213
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

0
Offline Offline
God Member
*****
Karma: 25
Posts: 606
Always making something...
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Left Coast, CA (USA)
Offline Offline
Brattain Member
*****
Karma: 361
Posts: 17259
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
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
Logged

0
Offline Offline
God Member
*****
Karma: 25
Posts: 606
Always making something...
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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?
Logged

Pages: [1]   Go Up
Jump to: