[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] FAQ #27: "Why are interrupts re-enabled in the middle
Re: [avr-libc-dev] FAQ #27: "Why are interrupts re-enabled in the middle of writing the stack pointer?"
Tue, 15 May 2007 15:11:42 -0400
Opera Mail/9.10 (Win32)
On Tue, 15 May 2007 14:51:26 -0400, Joerg Wunsch <address@hidden>
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.
I always thought that was required because of the internal synchronization
to get the asynchronous PINx synchronized to CLKio. I did not realize
it was more a side effect of the Fetch/Execute state machine.
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.
Good to know, but would still like to see the behaviour officially