|
From: | ThomasK |
Subject: | Re: [Simulavr-devel] irq handling is broken in simulavr |
Date: | Sat, 26 Jan 2013 09:53:29 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 |
Hi Petr,
Klaus Rudolph and Joerg Wunsch say that: if interrupts were are enabled or just became enabled (because of SEI, RETI, OUT) and an interrupt was pending or just became pending, then one more instruction will be executed and then the interrupt handler (typically a JMP/RJMP instruction) will be executed.
Documentation in atmel datasheets describe:“When the AVR exits from an interrupt, it will always return to the main program and execute one more instruction before any pending interrupt is served.”
So, this means, that we have this "delay" of one instruction after a RETI, but only after a RETI! (as I understand this)
“When using the SEI instruction to enable interrupts, the instruction following SEI will be executed before any pending interrupts, as shown in the following example.”
And this too, after an SEI instruction! So, with my understanding, all other cases will raise the interrupt immediately and __before__ the next instruction.
I think, I'll take Klaus and Petr's example code and try to catch it. Because I had last time to "fight" with timer1 on attiny25 (and found a new bug in this chip, which isn't described in errata sheets), I have a experiment on my desk with that and also a logic analyzer to look, what's happen. If I find time this weekend, I can post the results.
cu, Thomas
[Prev in Thread] | Current Thread | [Next in Thread] |