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

[Klaus Rudolph]

Joerg Wunsch schrieb:
> As Klaus Rudolph wrote:
> 
>>  19     ldi r16, (1<<UDRIE)    ; lets generate a usart data register
>> empty irq
>>  20     out UCSRB, r16         ; which should exactly now take place BUT ->
>>  21     out PORTB, r17         ; if this instruction is executed, we
>> will see 0x55 on portb!
> 
> Note that setting the portpins after an OUT instruction takes place
> *after* the opcode fetch for the next instruction.  What you are
> seeing here might be the net effect of this behaviour.

The question regarding the instruction ordering while rising an irq is
not related to the read/write of "in" and "out" instructions. You are
right that the subsequent call of out and in on the same register gives
the "maybe unexpected" old value from the register, but this is
meaningless regarding the question, if one more instruction will be
executed before the irq vector will be executed.

> Let's slightly change the example:
> 
> #define __SFR_OFFSET 0
> #include <avr/io.h>
> #include <avr/interrupt.h>
> 
> .global main
> main:
>     ldi r16, 0xff
>     out DDRB, r16
>     ldi r16, 0x01
>     out PORTB, r16
> 
>     ldi r17, 0x55
>     sei
>     ldi r16, (1<<UDRIE)
>     out UCSRB, r16
>     inc r17
>     inc r17
>     ret
> 
> .global USART_UDRE_vect
> USART_UDRE_vect:
>    com r17
>    out PORTB, r17
> 1: rjmp 1b
> 
> .global stopsim
> stopsim:
>     reti
> 

For my understanding this shows the same result: The instruction after
firing the irq will be executed, independent from the reason which fires
the irq ( setting I flag while hw irq is pending or setting hw irq while
I flag is already set).

>From that point of view I think the simulation works now as real
hardware does.

If there is something wrong: Please let us know :-)

Thanks
 Klaus