ATiny861A SREG sichern

[Lars L. (lale)]

Hallo zusammen,

ich versuche gerade eine atomare Berechnung "ordentlich", also mit 
zwischenspeichern des SREG zu programmieren.

Mein c-Code sieht so aus:

uint8_t lclSREG = SREG;
cli();
LN_UART_FR &= ~(0x1C << ShiftValue);
LN_UART_FR ^= 0x02;
SREG = lclSREG;

Im Disassembly sieht dann so aus:

    uint8_t lclSREG = SREG;
0000009F  IN R20,0x3F    In from I/O location 
    cli();
000000A0  CLI     Global Interrupt Disable 
    LN_UART_FR &= ~(0x1C << ShiftValue);
000000A1  LDS R21,0x0205    Load direct from data space 
000000A3  LDI R18,0x1C    Load immediate 
000000A4  LDI R19,0x00    Load immediate 
000000A5  MOVW R22,R18    Copy register pair 
000000A6  RJMP PC+0x0003    Relative jump 
000000A7  LSL R22    Logical Shift Left 
000000A8  ROL R23    Rotate Left Through Carry 
000000A9  DEC R25    Decrement 
000000AA  BRPL PC-0x03    Branch if plus 
000000AB  MOVW R24,R22    Copy register pair 
000000AC  COM R24    One's complement 
000000AD  AND R24,R21    Logical AND 
000000AE  STS 0x0205,R24    Store direct to data space 
    LN_UART_FR ^= 0x02;
000000B0  LDS R25,0x0205    Load direct from data space 
000000B2  LDI R24,0x02    Load immediate 
000000B3  EOR R24,R25    Exclusive OR 
000000B4  STS 0x0205,R24    Store direct to data space 
    SREG = lclSREG;
000000B6  OUT 0x3F,R20    Out to I/O location

Wenn ich (im AVR Studio 6 Simulator) bei 0x9F einen Breakpoint setze, 
kann ich im "Processor"-Fenster auch sehen, dass das I-Flag und H-Flag 
im SREG gesetzt sind. Einen Einzelschritt weiter ist dann R20 aber nur 
0x20. Das I-Flag wird also nicht übernommen und demnach auch bei 0xB6 
nicht wieder eingeschaltet.
Ein schneller Blick ins Datenblatt vermittel mir das Gefühl, dass das 
komplette SREG leß- und schreibbar ist, weshalb ich nicht verstehe, 
warum sich das I-Bit nicht auslesen läßt.

Kann mir da jemand auf die Sprünge helfen?

Dank und Gruß
Lars

[Karl H. (kbuchegg)]

Ich halte das ehrlich gesagt für einen Simulatorfehler.

[Lars L. (lale)]

Hallo Karl Heinz,

hab mir das gerade mal auf einem Steckbrett zusammengefummelt. Sieht so 
als hättest Du recht. Für's Simmulieren mit Stimuli muss ich mir dann 
wohl was anderes einfallen lassen.

Zwei Fragen schließen sich noch an:
1. Sind diese Simulatorfehler irgendwo katalogisiert (Errata), so dass 
ich mal einen Blick drauf werfen kann, was mich da ggf. noch so 
überraschen könnte.
2. Interessiert sich Atmel dafür, wenn man einen solchen Fehler entdeckt 
hat?

Gruß und Danke für den Tip
Lars

[H.Joachim S. (crazyhorse)]

Du bekommst ne nette mail, dass das geprüft und falls tatsächlich so 
behoben wird. Das wars dann.
Die nächste Version hat evtl. den bemängelten Fehler behoben, dafür neue 
eingebaut.
Ich halte inzwischen gar nicht mehr viel vom AVR-Studio, zuviele 
Enttäuschungen erlebt.
Am Ende zählt nur die tatsächliche Hardware, bei komischen Sachen lasse 
ich mir das lieber auf irgendeinem Weg ausgeben. Benutze die Simulation 
kaum noch.

[F. F. (foldi)]

ASM ist ja nicht meine Fraktion, aber kannst du dir das nicht mal 
ausgeben lassen, was im Register steht? Nötigenfalls mit Leds.

Sehe gerade, dass du das mit C machst. Bau doch mal ne Bildschirmausgabe 
rein, mit ner fetten Pause, dann siehst du was drin steht.
Ich habe auch schon mal merkwürdige Simulator Anzeigen gesehen.
Vom Simulator halte ich auch nicht besonders viel.

[spess53 (Gast)]

Hi

>1. Sind diese Simulatorfehler irgendwo katalogisiert (Errata), ..

Beim 4er Studio war das in der Hilfe zum Simulator unter 'Known Issues' 
zu finden.

>so dass >ich mal einen Blick drauf werfen kann, was mich da ggf. noch so
>überraschen könnte.

Vermeide einfach die IO-Module der AVRs zu simulieren, bringt nichts.

>2. Interessiert sich Atmel dafür, wenn man einen solchen Fehler entdeckt
>hat?

Nicht wirklich. Der Simulator ist m.A. von 4er zum 6er Studio eher 
schlimmer geworden.

Besorge dir einen AVR Dragon oder ein JTAGICE3.

MfG Spess