Re: [avr-libc-dev] FAQ #27: "Why are interrupts re-enabled in the middle of writing the stack pointer?"

[Joerg Wunsch]

As Bob Paddock wrote:

> However I have missed any Atmel documentation that says a 'out' to
> SREG applies that same protection?  Does that mean all 'out'
> instructions delay pending interrupts, or just 'out' instructions to
> SREG?  What document did I miss reading?

AFAIR it applies to every method that could set the I bit in SREG,
regardless of whether it's a SEI/CLI, a modification of SREG through
IO or memory address space, or a RETI.

It is not really a "protection" feature that has been added on
purpose, it rather appears to be an inherent feature of the way the
opcode fetch and decoding engine in the AVR works.  Remember, that all
IO bit manipulations happen quite late within the instruction cycle.
Thus you need a NOP between an OUT and an IN if the IN's result
depends on the previous OUT operation, as the sampling for the PINx
(of the *next* instruction!) happens before the POUTx change.  Similar
then does apply to the way the I bit is internally updated: the next
instruction is simply already decoded by that time, and will thus be
executed without any chance of an interrupt to fire.

It is not really documented anywhere, but Marek once mentioned they
somehow got confirmation from Atmel about that sequence being safe in
the early days of AVR-GCC.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)