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

[Joerg Wunsch]

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.

(Remember, this is also the reason why you cannot perform an OUT
PORTx, ..., triggering some external hardware to assert a signal, and
then immediately read that signal back through a subsequent IN
instruction.  Sampling the input lines for the IN instruction already
takes place *before* the OUT instrcution did set the output portpins.
For code like this, a single NOP is mandatory between the OUT and the
IN.)

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

The "com r17" in the ISR is only there to negate the bit pattern since
the STK500's LEDs are low active.  That way, the LEDs directly display
the number from r17.  The pattern displayed is 0x56, which indicates
that the next "inc r17" instruction after setting UCSRB is executed
still before the IRQ fires.
-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

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