0

this already took me hours to figure out.

With:

in r18, SREG-0x20

the I-bit is not stored (0x94 in SREG translates to 0x14 in r18).

The same outcome happens with this:

ldi r30, lo8(0x5f)
ldi r31, hi8(0x5f)

ld r18, Z

Maybe this is on purpose? Or is it just the simulator? I tested it with other registers, but it seems to be only SREG- I-bit.

Also i am running an mixed c/asm project.

Tobey66
  • 73
  • 9
  • 1
    How is `SREG` defined? 0x5f or 0x3f? In this [m64def](https://github.com/DarkSector/AVR/blob/master/asm/include/m64def.inc) is 0x3f so it's already the IO address. – Margaret Bloom Sep 13 '17 at 14:39
  • You should post your code too, or at least a piece of it – Frazzo Sep 13 '17 at 15:01
  • There is not much more relevant code than this (i guess). The address is the right one since i tried and manipulated those bits. the value 0x94 which is in SREG comes out as 0x14 in r18 after this instruction. – Tobey66 Sep 13 '17 at 15:19
  • Where I'm from, we don't subtract 0x20 from SREG before accessing it. I'm afraid you're fetching something else. – tofro Sep 13 '17 at 15:31
  • No, i already confirmed that i dont catch something else! – Tobey66 Sep 13 '17 at 15:38
  • First: put #define _SFR_ASM_COMPAT 1 #define __SFR_OFFSET 0 at the top of your asm file and you can avoid - 0x20 for in/out instructinos. Second: are you sure interrupts are not disabled when you're reading the SREG? E.g. you are not in tthe middle of interrupt routine or something like that. Or weer interrupts enabled by sei? in from SREG always copy all it's bits, including the interrupt flag – AterLux Sep 29 '17 at 13:48

0 Answers0