Inkrementieren von Bits in Bitfeldern

[Hans (Gast)]

Hallo uC-Gemeinde,

ich habe ein Problem mit dem Inkrementieren eines oder mehrerer Bits in 
einem Bitfeld.

Folgender Code inkrementiert alle Member des Bitfelds:

static volatile struct{
    unsigned a:3;
    unsigned b:3;
    unsigned c:2;
  }status;

status.a++;

status.a += 1; funktioniert auch nicht.

Die direkte Zuweisung eines Wertes hingegen funktioniert.

Kann mir jemand sagen warum?

Vielen Dank im Voraus.

Gruß,
Hans.

[(prx) A. K. (prx)]

Das wäre ein Fehler des Compilers. Welcher Compiler? Einfaches 
compilierbares Beispiel?

[Hans (Gast)]

Hallo A.K.,

der Compiler ist der gcc. Ich glaube nicht, dass der Fehler hier liegt.
Hier dein kompilerbares Beispiel.

Hab leider keine echte Hardware da, aber kann es sein, dass der 
Simulator des AVR-Studios einen Bug hat?

static volatile struct{
      unsigned char a:3;
      unsigned char b:3;
      unsigned char c:2;
    }status;

int main(void){
  

    status.a = 0;
    status.b = 0;
    status.c = 0;
    status.a++;
}

Gruß,
Hans.

[(prx) A. K. (prx)]

Woran erkennst du in diesem Beispiel, dass das ganze Byte inkrementiert 
wird? Es wird so oder so 1 rauskommen.

[Stefan E. (sternst)]

Der Debugger im Studio wird vermutlich mit Bitfeldern einfach nichts 
anzufangen wissen. Deshalb wird er dir für alle drei (a, b und c) den 
Wert des kompletten Bytes als Inhalt präsentieren.

[Hans (Gast)]

A. K. schrieb:
> Woran erkennst du in diesem Beispiel, dass das ganze Byte inkrementiert
> wird? Es wird so oder so 1 rauskommen.

Ich schau mir die einzelnen Member im AVR-Simulator an.
"Es wird so oder so 1 rauskommen" -> Versteh grad nicht, was genau du 
mit dieser Aussage meinst...

@Stefan:
Mit der Aussage könnte ich schon mehr anfangen. ;-)

[(prx) A. K. (prx)]

Hans schrieb:

> "Es wird so oder so 1 rauskommen" -> Versteh grad nicht, was genau du
> mit dieser Aussage meinst...

Vorher:
  a = 0, b = 0, c = 0. Byte = 0.
Nachher:
  a = 1, b = 0, c = 0. Byte = 1.

[Hans (Gast)]

A. K. schrieb:
> Hans schrieb:
>
>> "Es wird so oder so 1 rauskommen" -> Versteh grad nicht, was genau du
>> mit dieser Aussage meinst...
>
> Vorher:
>   a = 0, b = 0, c = 0. Byte = 0.
> Nachher:
>   a = 1, b = 0, c = 0. Byte = 1.

Ok, das wäre das, was ich erwartet hätte. Der AVR-Simulator sagt aber 
folgendes:

Vorher:
   a = 0, b = 0, c = 0.
Nachher:
   a = 1, b = 1, c = 1.

[Simon K. (simon)]

Ja, weil:

Stefan Ernst schrieb:
> Der Debugger im Studio wird vermutlich mit Bitfeldern einfach nichts
> anzufangen wissen. Deshalb wird er dir für alle drei (a, b und c) den
> Wert des kompletten Bytes als Inhalt präsentieren.

[mizch (Gast)]

Inkrementiere mal b.  Wenn dann 8 angezeigt wird, siehst Du das ganze 
Byte, nicht das Bitfeld.

[Hans (Gast)]

Stimmt, das wars.
Danke.

[Hans (Gast)]

Hallo,

ich nochmal.
Ich habs es gerade nochmal auf der echten Hardware ausprobiert.
Da ist es genauso.
Der Fehler muss also doch woanders liegen...
Hat jemand ne Idee?

Gruß,
Hans

[Simon K. (simon)]

Hä? Was ist da genau so? Natürlich werden die 3 Bitfeldvariablen in 
einem Byte gespeichert, wieso sollte das auch anders sein?

Es funktioniert alles wie du willst.

[Karl H. (kbuchegg)]

Welcher Compilerversion?

Habs hier mit der WinAvr-20090313 ausprobiert.
Der Assemblercode sieht gut aus

int main(void){
  

    status.a = 0;
  7c:  80 91 60 00   lds  r24, 0x0060
  80:  88 7f         andi  r24, 0xF8  ; 248
  82:  80 93 60 00   sts  0x0060, r24
    status.b = 0;
  86:  80 91 60 00   lds  r24, 0x0060
  8a:  87 7c         andi  r24, 0xC7  ; 199
  8c:  80 93 60 00   sts  0x0060, r24
    status.c = 0;
  90:  80 91 60 00   lds  r24, 0x0060
  94:  8f 73         andi  r24, 0x3F  ; 63
  96:  80 93 60 00   sts  0x0060, r24
    status.a++;
  9a:  90 91 60 00   lds  r25, 0x0060
  9e:  9f 5f         subi  r25, 0xFF  ; 255
  a0:  97 70         andi  r25, 0x07  ; 7
  a2:  80 91 60 00   lds  r24, 0x0060
  a6:  88 7f         andi  r24, 0xF8  ; 248
  a8:  89 2b         or  r24, r25
  aa:  80 93 60 00   sts  0x0060, r24
}
  ae:  80 e0         ldi  r24, 0x00  ; 0
  b0:  90 e0         ldi  r25, 0x00  ; 0
  b2:  08 95         ret

Lass dir mal ein List-File erzeugen und sieh nach, was der Compiler 
daraus gemacht hat

[(prx) A. K. (prx)]

@Hans: Vermutlich hast du den gleichen defekten Debugger diesmal auf die 
echte Hardware gehetzt. Naturgemäss mit dem gleichen Ergebnis. Nicht die 
Simulator-Engine ist das Problem, sondern der entweder darauf oder auf 
der echten Hardware aufsitzende Debugger.

[Hans (Gast)]

So, jetzt hab glaube ich verstanden zu haben, was da vor sich geht.

static volatile struct{
    unsigned a:3;
    unsigned b:3;
    unsigned c:2;
  }status;

Für das Struct werden im Speicher 8Bit reserviert. (Erkennbar an den 
daraufolgenden Speicheradressen)

Komischerweise, liest das AVR-Studio 16 Bit ein.
Ich habe aber 2 dieser Structs nebeneinander im Speicher, daher liest er 
wenn Struct1 und Struct2 ist 257 als Wert für Struct1 ein.

Der Fehler ist nicht nur im Simulator, sondern auf dem Atmel läuft der 
Zugriff auch falsch ab, weil Abfragen auf Struct1 == 1 dann falsch 
ausgewertet werden.

Mit

static volatile struct{
    unsigned char a:3;
    unsigned char b:3;
    unsigned char c:2;
  }status;

funktioniert das Ganze.

Was sagt ihr dazu?

Gruß,
Hans.

[(prx) A. K. (prx)]

Bis zum Beweis des Gegenteils glaube ich dem Compiler und misstraue der 
Variablenanzeige des Debuggers. Probier mal mit der ursprünglichen 
Version
   volatile unsigned temp;
   ...
   status.a++;
   temp = status.b;
und schau danach rein, was in temp steht. Vermutlich der korrekte Wert.

M.a.W: Du kämpfst grad gegen Gepenster. Weder Compiler noch Simulator 
noch Hardware machen etwas falsch, sondern die Anzeige der Daten ist 
falsch. Hast du wohlmöglich den Optimizer eingeschaltet?

[Karl H. (kbuchegg)]

Hans schrieb:

> Was sagt ihr dazu?

All das was A.K. auch schon gesagt hat.
Plus: Bitfelder werden sowieso überbewertet