I am wondering if there is a constant of which board your sketch is currently running on or is there constants for the amount of total sram/eeprom along with cpu. Also, the boards firmware number might be nice to know during execution, allowing people to write more compatible code across the different boards.
Thanks for any help!
I know that my49plymouth will not respond, or even see this post, but Arduino Playground - AvailableMemory lets you see how many bytes of SRAM is remaining.
my49plymouth:
I am wondering if there is a constant of which board your sketch is currently running on ... [and/or a variable for] amount of eeprom [remaining]
I would like to know that too!
P.S. This post has been unanswered for 159 days! Why do some posts get ignored?
dkl65:
P.S. This post has been unanswered for 159 days! Why do some posts get ignored?
Because questions on forums are answered at will.
I'm not sure why age of the post matters, I don't go perusing for 6 month old threads to answer...
I'm not sure why age of the post matters, I don't go perusing for 6 month old threads to answer...
It doesn't! I was just saying. I was actually looking at some unanswered threads.
dkl65:
my49plymouth:
I am wondering if there is a constant of which board your sketch is currently running on ... [and/or a variable for] amount of eeprom [remaining]I would like to know that too!
There is no way to know the board but there is a way to determine the processor...
#if defined( AVR_ATmega328P )
// 328 stuff goes here (probably an Uno compatible board)
#elif defined( AVR_ATtiny85 )
// 85 stuff goes here
#else
//
#endif
E2END+1 is the total EEPROM space available (in bytes). It's up to you, the programmer, to determine how much of that space is "remaining".
But surely the #defines are resolved at compile time and don't tell you what your are running on? It has to be predetermined.
But surely the #defines are resolved at compile time
Yup.
and don't tell you what your are running on? It has to be predetermined.
Yup. At compile time.
my49plymouth:
Also, the boards firmware number might be nice to know during execution, allowing people to write more compatible code across the different boards.
What firmware? The code your wrote or the bootloader? Why would the running program care what bootloader is on the board?
James,
I assume he meant what version of Arduino core code and libraries is being used.
For that, as long as the IDE is being used to build the image, you can look at the define ARDUINO.
Well unless you are unlucky enough to have revisions in the 0016 to 0018 range
in which case the ARDUINO define was messed up and stuck at 0016.
to check for pre 1.0 and post 1.0 you can use:
#if ARDUINO < 100
// pre 1.0 code here
#else
//post 1.0 code here
#endif
For the board, what is usually more important is to know the core or "variant" being using.
And what is truely sad is that (at least with post 1.0) the IDE knows both the core and the variant because it is is specified
in the boards.txt file, but neither the IDE nor the variant header files bother to set any type of define
to let the code being compiled to know about it.
So it is very difficult to tell what board/core/variant is being used. To fully qualify a board you not only have
to look at the processor type as Coding Badly pointed out but you have to potentially also look around at
some other defines as well.
This is because there are multiple boards that can use the same processor that can use different cores or different pinouts.
Examples of this are Teensy vs Leonardo
Sanguino vs BobDuino, vs Mighty 1284p.
While it is possible to be able to determine a board type/variant at compile time, it isn't as simple as just looking at processor type.
Currently it is a PITA as depending on the processor type you sometimes also have to look around for some
unique defines in that core/variant files to help figure out the variant as well.
This can be a special define that is unique (this works for Teensy) or you can peek into pin mapping defines by checking things like
pwm support on pins or analog to digital pin number mappings which works for the Sanguino, et al boards.
--- bill