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. ;-) _______________________________________________ Simulavr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/simulavr-devel
