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

2007-05-22 Thread Bob Paddock
On Monday 21 May 2007 06:22, Schwichtenberg, Knut wrote: the official documentation of the Mega32 CPU (doc2503.pdf) - the one I'm using - says When using the SEI instruction to enable interrupts, the instruction following SEI will be execued before any pending interrupts Yes it does, as most

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

2007-05-21 Thread Schwichtenberg, Knut
Bob Joerg, the official documentation of the Mega32 CPU (doc2503.pdf) - the one I'm using - says When using the SEI instruction to enable interrupts, the instruction following SEI will be execued before any pending interrupts ... You sould have a look in detail AVR CPU Core and within this

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

2007-05-15 Thread Bob Paddock
I have a question about AVR-LIBC FAQ #27: http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_spman Why are interrupts re-enabled in the middle of writing the stack pointer? I understand that when the SEI instruction is used, The instruction following SEI will be executed before any

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

2007-05-15 Thread 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

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

2007-05-15 Thread Bob Paddock
On Tue, 15 May 2007 14:51:26 -0400, Joerg Wunsch [EMAIL PROTECTED] wrote: 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