Deprecated macros

J-M-L:
When the UART sends something out the Tx pin does change state, right ?

Of course, but I don't think this goes through the PORTD register, the USART peripheral controls the output driver directly, without writing to PORTD.

I'm referring to §13.3 of the ATmega328P datasheet, figure 13-5 specifically, as well as §13.3.3, table 13-11.
Enabling the USART enables PVOE (port value override enable) and connects PVOV (port value override value) to the TXD output of the USART peripheral. In other words, when the USART is enabled, the PORTD register is bypassed for the TX pin, and it is driven directly from the USART. As far as I can see, PORTD is not written to by the UART ISRs.

Good info - thx

I had assumed you could always check the status of the pin with the port register. My bad then.

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.

Disabling interrupt anywhere in your library/function can potentially break libraries that rely on interrupts, which brings us back to

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

Well disabling interrupts should only be done when critical for what you need (ie address à risk of a bug if Murphy strikes in your critical section) and for a very short period of time. If it breaks something else then it means you have either a code design issue or are using the wrong board / components

J-M-L:
something like this

noInterrupts();

PORTD &= 0b11;
interrupts();

This is not entirely interrupt-safe. avr-libc: Compiler optimization

Is that true when your single statement in the critical section includes a volatile? I thought that was OK.

The added comments can be put back on the original topic. Which of the replies in this topic belong on the original ?

UKHeliBob:
The added comments can be put back on the original topic. Which of the replies in this topic belong on the original ?

I have deleted one of my replies which is no longer relevant.

I think that the Replies that are now numbered #26 and #27 probably belong in the original - but I would lose no sleep if both were deleted :slight_smile:

...R

[gfvalvo] would make it atomic to be absolutely certain of the result.

Atomicity seems to be a particular concern to gfvalvo; they mention it quite often. Perhaps they have been bitten by an atomicity bug at smoe time; those are REALLY ANNOYING TO DEBUG!

It is very likely that a statement like "PORTD &= 0xC0;" does NOT NEED to be atomic (and adding atomicity will significantly reduce performance, of that particular statement.

avr-libc provides a neat atomicity primitive:

     ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
       PORTD &= 0xC;
     }

Unfortunately, it's not present on other architectures like SAMD, and can also be more expensive and dangerous to implement (and ARM has 8+ different priorities for interrupts, and you might only want to prevent the ones that actually cause interference. And it has other ways to do things atomically.)