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

[Joerg Wunsch]

As ThomasK wrote:

> So, with my understanding, all 
> other cases will raise the interrupt immediately and __before__ the next 
> instruction.

The experiments Klaus and I made contradict to this conclusion.

Just because there's no statement about other cases doesn't imply
there were no further delay.

My guess is that the delay is simply due to the way the opcode
decoding in the AVR works: by the time the "out" instruction
triggering the interrupt actually gets in effect (in our examples,
this is the "out" instruction writing to UCSRB), the next instruction
is already being decoded, and thus also executed.  So it's probably
not an additional delay in the interrupt *acceptance*, but rather an
additional delay in the part that *triggers* the interrupt.  However,
for all practical cases, the only difference between these two cases
is relevant for asynchronously triggered external interrupts.  But
then, for these interrupts, there's always a cut-off in time which
will decide whether one more instruction is going to be executed or
not.

If anyone is interested, the "Simulator V2" in AVR Studio (for those
parts where it is supported) is supposed to work exactly the same as
the hardware, because it uses a model which is directly generated
after the Verilog code which is used to implement the hardware itself.
So when in doubt, try it there.
-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)