pert:
I have been maintaining a list of the instances of the usage of the deprecated macros here:
Use GCC binary constants format · Issue #3561 · arduino/Arduino · GitHub
and added your link to it. If you find any others, please let me know and I'll add it to the list.
I randomly checked this list.
That one is stroked out:
for me that means "fixed", but there is still a
PORTD = PORTD & B00000011; // clear out bits 2 - 7, leave pins PD0 and PD1 untouched (xx & 11 == xx)
noiasca:
That one is stroked out:
Arduino Reference - Arduino Reference
I guess you accidentally wrote the wrong URL in the text I quoted. If you're talking about one of the Arduino Reference - Arduino Reference links, the reason you will still see the deprecated macro/enums in the arduino.cc content is because, even though the source content was fixed by Replace "B..." binary constants with "0b..." by cousteaulecommandant · Pull Request #793 · arduino/reference-en · GitHub, that hasn't yet been published to arduino.cc. That PR was only merged a couple days ago and pretty much everyone at Arduino is on holiday vacation.
So perhaps I was premature to strike out those list items, but as far as the work on GitHub is concerned, it is indeed done.
I'll add that I also submitted a PR (to a private repository) to update the contents of the two tutorial pages on that list, but since that PR hasn't been merged yet I didn't strike those list items out.
noiasca:
for me that means "fixed", but there is still aPORTD = PORTD & B00000011; // clear out bits 2 - 7, leave pins PD0 and PD1 untouched (xx & 11 == xx)
A much bigger problem than a non-standard macro is the fact that operation is non-atomic. Hence, it is not interrupt-safe.
mcmahad:
Why does Arduino deprecate and hide the use of main(), and instead create the setup() and loop() functions?
launch the IDE and type this
int main()
{
Serial.begin(115200);
Serial.println(F("It all works fine!"));
Serial.flush();
return 0;
}
click to compile and upload to your Arduino Uno. Open the Serial monitor at 115200 bauds. you'll see it works.
But the point was an attempt to make it easy for new comers and it does a pretty good job at that because the code above does not configure my arduino pins, timers, etc... to make it easy for me. that's what they perform in main() and then call your setup() and the loop() in an infinite loop (and a few more things on the side).
A much bigger problem than a non-standard macro is the fact that operation is non-atomic. Hence, it is not interrupt-safe.
What would make it "interrupt-safe"?
hzrnbgy:
What would make it "interrupt-safe"?
something like this
noInterrupts();
PORTD &= 0b11;
interrupts();
Do you do that for every line of code you write to make it "interrupt-safe"?
Well you think hard first before disabling interruptions... but yes if you want something atomic then you need to disable the interruptions that could modify what you are playing with.
hzrnbgy:
Do you do that for every line of code you write to make it "interrupt-safe"?
Only non-atomic code that will result in unexpected behavior should an interrupt occur in the middle of it.
gfvalvo:
A much bigger problem than a non-standard macro is the fact that operation is non-atomic. Hence, it is not interrupt-safe.
Why does interrupt safety matter here? Are there any interrupts in the Arduino Core that write to the PORTD register?
If there's user code updating PORTD in both the main loop and in an ISR, that's a different situation, but then it's up to the user to make sure there are no race conditions in his/her code. (But I wouldn't expect that to be the default assumption in an introductory discussion of direct port manipulation.)
Pieter
PieterP:
Why does interrupt safety matter here? Are there any interrupts in the Arduino Core that write to the PORTD register?
Pieter
Perhaps in a library that's being used? I would make it atomic to be absolutely certain of the result. If there were a conflict, it would be a real pain to debug.
gfvalvo:
Perhaps in a library that's being used? I would make it atomic to be absolutely certain of the result. If there were a conflict, it would be a real pain to debug.
That's a good point. I could see the Servo library causing problems, for instance.
Perhaps in a library that's being used? I would make it atomic to be absolutely certain of the result. If there were a conflict, it would be a real pain to debug.
If that is the case, then you'll have to disable interrupts for each library call, which in my honest opinion is going to cause more issue
PieterP:
Why does interrupt safety matter here? Are there any interrupts in the Arduino Core that write to the PORTD register?
eg Serial sending something out
J-M-L:
eg Serial sending something out
Don't quote me on this, but IIRC, the UART operates independently of the GPIO registers.
I have the impression some of you total miss the context.
Read where this line come from, and than decide if you really would like to read about interrupt safeness in that article: Arduino Reference - Arduino Reference
PieterP:
Don't quote me on this, but IIRC, the UART operates independently of the GPIO registers.
When the UART sends something out the Tx pin does change state, right ?
So you are at risk of writing back an old value on Tx which could impact a module (BT, GPS, GPRS,...) connected on pins 0 and 1 (Serial). Eg your read PORTD and see a 0 for Tx, then there is a Serial interrupt that sets Tx to a 1, then your code resume and perform the mask and write back the 0 into Tx)
hzrnbgy:
If that is the case, then you'll have to disable interrupts for each library call, which in my honest opinion is going to cause more issue
Fortunately, you're wrong. You only need to disable interrupts in non-ISR code when you want an absolutely safe read / modify / write of a PORT register.
noiasca:
I have the impression some of you total miss the context.Read where this line come from, and than decide if you really would like to read about interrupt safeness in that article: Arduino Reference - Arduino Reference
I think it’s relevant to mention you need to be careful as those pin masking stuff are not atomic (except writing on PINx when you flip a pin with a direct write).