Hi Petr,
back again from my little lab:
I executed the follwing code on a atmega32 (real device on stk500 )
1 #include <avr/io.h>
2 #include <avr/interrupt.h>
3
4 #undef _SFR_IO8
5 #define _SFR_IO8(x) (x)
6 #undef _SFR_IO16
7 #define _SFR_IO16(x) (x)
8
9
10 .global main
11 main:
12 ldi r16, 0xff ; all pins output
13 out DDRB, r16 ; all pins output
14 ldi r16, 0x01 ; one pin on
15 out PORTB, r16 ; initial only 1 pin
16
17 ldi r17, 0x55
18 sei ; enable interrupts
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!
22
23 ; normaly never execute any of the following instructions, we caught
into irq handler
24 ldi r17, 0x0f; ; if irq will not be executed or comes back
25 out PORTB, r17 ; we see 0x0f on port b which should not
happen
26 ret ; this will result in going back to
ctors_end -> exit
27
28 .global USART_UDRE_vect
29 USART_UDRE_vect:
30 rjmp USART_UDRE_vect
31
32 .global stopsim
33 stopsim:
34 reti
35
The result is:
PORTB shows 0x55 pattern!
That is exactly what I expect but seems first unbelievable :-)
What we have: After raising the irq on line 20 we have one more
instruction executed which writes the port value to the 0x55 pattern.
The reason for this is not manipulating the I flag in the instruction
before. So it looks that every pending interrupt will execute a single
instruction on normal program flow before entering the irq handler.
If there is no coding error or an interpretation issue I think my patch
is exactly doing what the real device do in respect of the instruction
following the pending irq.
What I could not check is the timing behavior for the wait states of the
next instructions. Maybe it is possible to setup a timer and read back
the counter after execution or some other idea. But I think that is not
so important in the moment (for me).
I will do some more testcases on real device and on simulavr and make
unit tests for them.
Please tell me if you could find any mistakes!
Regards
Klaus
_______________________________________________
Simulavr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/simulavr-devel