In my search I found this post.
It did not end in a clear description ,but maybe now 10 years later .....
https://forum.arduino.cc/t/define-ledpin-13-vs-int-ledpin-13/197009?_gl=1qwnpdm_upMQ.._gaMTE2NDMxMjEzNC4xNzMzOTIwMzk1_ga_NEXN8H46L5*MTczMzkyMDM5NC4xLjAuMTczMzkyMDM5NC4wLjAuMTM3MDc2NTk5MQ..
Seems pretty clear to me
What happens with int LedPin = 13; at compile time?
Probably the compiler will see that the value is never changed elsewhere in the code, and so it knows it can simply replace LedPin with the value 13 each time it occurrs. The result is the same as using #define.
that symbol, LedPin is allocated memory and the value initialized with 13.
since it's a variable, that value can be changed at run time.
whenever that symbol is referenced in code (e.g. digitalWrite (LedPin, HIGH);, that value is read from memory.
if the symbol were defined as a const, the symbol would be replaced with the value at compile time (e.g. digitalWrite (LedPin, HIGH);), not read from memory
It's a C++ Best Practice to use one of the forms:
const byte ledPin = 13;
const byte ledPin {13};
const uint8_t ledPin = 13;
const uint8_t ledPin {13};
This brings the compiler's full error checking capability and strong typing to bear. The compiler is much more sophisticated than the preprocessor that handles macros (like #define). Things are kind of the Wild West with preprocessor macros and they should only be used when absolutely necessary.
1 Like
As the program itself is also in memory, it would still be read from memory...
It has been debated ad nauseam, and the overwhelming conclusion is that defining a const variable is far superior from an error checking and type safety point of view. And modern compiler optimization capabilities make arguing about memory use pointless.
4 Likes
Thanks.
So it is clear that both.
#define LedPin = 13;
int LedPin = 13;
will replace LedPin with 13 at compile time.
So also does int LedPin = 13;
Thanks , at this time I would just like to get a reasonable clear explanation and not a work around.
Not sure what that means. How is Best Practice a "work around"?
1.
==>
#define ledPin 13 //correct syntax and Arduino Camel-case style for a multi-word identifier
In a program, during compilation, wherever the symobolic name ledPin is found, it is replaced by 13 and is stored in a RAM memory location. Is there any chance that the value of that memory location would be changed during run time -- I have no idea?
2.
int ledPin = 13;
To me, it is same as 1.
3.
const int ledPin = 13;
The value will never be chnaged as the holding RAM location is marked read only (my idea). This feature I have seen/practiced in the PAVM (Protected Virtual Address Mode) Mode architectre of 80286.
I am curious to know how a RAM location in ATmega328P MCU is marked read only?
It's not. const is an instruction to the compiler and it will check if that variable (what is in a name) is modified by accident.
2 Likes
Example
const uint8_t ledPin = 13;
void setup()
{
Serial.begin(115200);
while (!Serial) {}
ledPin = 12;
}
void loop()
{
// put your main code here, to run repeatedly:
}
Compile results:
C:\Users\bugge\AppData\Local\Temp\.arduinoIDE-unsaved20241111-12056-13gadpy.1ox5\sketch_dec11a\sketch_dec11a.ino: In function 'void setup()':
C:\Users\bugge\AppData\Local\Temp\.arduinoIDE-unsaved20241111-12056-13gadpy.1ox5\sketch_dec11a\sketch_dec11a.ino:8:12: error: assignment of read-only variable 'ledPin'
ledPin = 12;
^~
exit status 1
Compilation error: assignment of read-only variable 'ledPin'
1 Like
That means that there is no architectural protection feature in ATmega328P like the 80286. The protection has been implemented artificially through the const modifier -- am I correct?
Indeed.
Just like in C++ for the 80286; it's part of the language since its inception.
Let's keep it at that so the topic is not derailed.
2 Likes
good so far
No. likely the value 13 will be compiled into the program, not set aside as a variable. Using a variable unnecessarily means the compiler must manage an address for the variable, and compile code that will read that address at runtime.
Which is what
int ledPin = 13;
results in, because a memory variable needs to be allocated, since the declaration implies it may be changed at runtime.
const int ledPin = 13;
tells the compiler 'look, this value is never going to change; place it in the code however you deem is most efficient, but ensure that I never try to modify it'. I expect that that will usually be an inline value in code space, for simple things like ints. Structs, Strings, and even strings, not so much. Hence, we end up with tools like the F macro, to move things into code space, saving RAM.
For the #define, you asked
Is there any chance that the value of that memory location would be changed during run time -- I have no idea?
No; for the #define approach described here, there is no memory location that can be modifed; the value is inline in the code, therefore in 'untouchable' space. Someone else can speak to whether there is a context for a #define that would result in RAM usage.
1 Like
Being afraid that the main topic might be derailed as has been warned by @sterretje, the respected Moderator may split the thread so that further discussion may continue about the value is inline in the code, etc.
I think we're still discussing the differences between the approaches, but I'll defer to any moderator's wishes.
However, further discussion of the topic will delve into what the compiler does when compiling these constructs, which is beyond my knowledge. I can speculate, but explanation will involve generating assembly code to be discussed. Perhaps, if you're interested, you could do the code generation and make the comparison. There are plenty of threads here about inspecting/dissecting the compiler's output.
# define happens before compilation and is performed in a simple case like this exactly equivalently to finding instance of the identifier and replacing it with the value.
You can get the source code after this step in building the code, which step will have textual inclusion of any included files as well. Intersting reading. You'll also see all the work the IDE does to keep ppl needing to declare functions before they are used and stuff like that.
Same with more complicated #defines, it happens at the text level in the source code before the compiler ever sees it.
I'm old fashioned and still use # define, though occasionally try to get myself into the 21st century.
One place where # define is the only way to fix something is
# define PRESSED LOW
so you can
bool launchTheNukes = digitslRead(bigRedButton) == PRESSED;
because believe it I still almost cannot, digitalRead() returns LOW or HIGH. Anything else you do with the return value but compare it to LOW and HIGH (or pass it to digitatWrite() which similarly takes only LOW and HIGH) is in disagreement with the API, no matter we get away with, well, what makes more sense and woukd have at the moment whoever decided they knew better.
a7
Not quite true, but this would be splitting hairs
enum ButtonStates
{
PRESSED = LOW,
RELEASED = HIGH
};
const byte bigRedButton = A0;
void setup()
{
Serial.begin(115200);
bool launchTheNukes = digitalRead(bigRedButton) == PRESSED;
if (launchTheNukes)
{
Serial.println("**BOOM**");
}
}
void loop()
{
}