|
| From: | Bob Paddock |
| Subject: | Re: [avr-libc-dev] FAQ #27: "Why are interrupts re-enabled in the middle of writing the stack pointer?" |
| Date: | Tue, 15 May 2007 15:11:42 -0400 |
| User-agent: | Opera Mail/9.10 (Win32) |
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 delay,
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
Unfortunate.
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 documented
by Atmel.
| [Prev in Thread] | Current Thread | [Next in Thread] |