Re: [Simulavr-devel] irq handling is broken in simulavr

[ThomasK]

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