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 _______________________________________________ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
