C -> Bitfeld

[Jan H. (janiiix3)]

Guten Morgen,

wenn ich jetzt ein Bitfeld habe

typedef struct
{
  uint8_t bStepperActive  :1; // Schrittmotoren sind aktiv (beide)
  uint8_t bStepperAutoOff :1; // Automatische Motorabschaltung nach Zeit
  uint8_t bButtonStart  :1; // Start wurde gedrückt
  uint8_t bChangeRotation  :1; // Richtung wurde geändert
  uint8_t bRotation    :1; // 0 = links (default) , 1 = rechts
}sFlags_t;

Kann ich davon ausgehen das z.B "bStepperActive" immer das erste Bit im 
"Byte" ist?
Sprich das der erste Eintrag in diesem Fall "bStepperActive" immer das 
erste Bit ist..

[Teo D. (teoderix)]

Nein -> Data Alignment
https://en.wikipedia.org/wiki/Data_structure_alignment

Wenn aber klar ist, wo vorn und hinten ist, JA. Also in deinem Programm, 
bleibt die Position immer gleich.


PS: Du verschwendest in deinem Beispiel 3Bit....

[Jan H. (janiiix3)]

Teo D. schrieb:
> Wenn aber klar ist, wo vorn und hinten ist, JA. Also in deinem Programm,
> bleibt die Position immer gleich.

Sorry. Stehe auf dem Schlauch. Wie meinst Du das mit vorn und hinten?

Teo D. schrieb:
> PS: Du verschwendest in deinem Beispiel 3Bit....

Das war nur ein Beispiel jetzt.

[foobar (Gast)]

> Kann ich davon ausgehen das z.B "bStepperActive" immer das erste Bit
> im "Byte" ist?

Nicht vom C-Standard her - der schreibt keine Reihenfolge vor.  Wovon du 
allerdings ausgehen kannst, ist, dass ein bestimmter Compiler immer die 
gleiche Reihenfolge verwendet.

[Teo D. (teoderix)]

Naj H. schrieb:
> Sorry. Stehe auf dem Schlauch.

Du ich hab den Link nicht aus Jux gepostet!

[Wilhelm M. (wimalopaan)]

Naj H. schrieb:
> Sprich das der erste Eintrag in diesem Fall "bStepperActive" immer das
> erste Bit ist..

Nein, nicht immer (kommt drauf an, was Du mit immer meinst).

https://en.cppreference.com/w/c/language/bit_field

Im wesentlichen: die Eigenschaften, die Du gerne haben möchtest, sind 
implementation-defined.

[Frickler (Gast)]

Die Idee ist doch sicher Binärdaten auf irgendeiner Schnittstelle zu 
empfangen und die Auswertung statt mit Hilfe der üblichen Bitschubserei 
elegant durch das Lesen/Schreiben der Felder im Bitfield zu erledigen.

Die Idee hatten schon viele zuvor und alle sind zur selben ernüchternden 
Erkentnis gelangt, dass dieser Code schlecht wartbar und unportierbar 
wird.

[fop (Gast)]

foobar schrieb:
> Nicht vom C-Standard her - der schreibt keine Reihenfolge vor.  Wovon du
> allerdings ausgehen kannst, ist, dass ein bestimmter Compiler immer die
> gleiche Reihenfolge verwendet.

Wobei "bestimmter Compiler" sehr eng zu sehen ist. Ich hatte schon mal 
den Brüller, dass bei einem Update des Compilers die Reihenfolge sich 
umdrehte.

Es soll ja auch Compiler geben, die per Kommandozeilenargument oder 
Pragma Anweisung da was drehen. Hölle, wenn man 2 fremde Bibliotheken 
einbinden muss, die das unterschiedlich handhaben.

[Niklas Gürtler (Gast)]

Frickler schrieb:
> Die Idee ist doch sicher Binärdaten auf irgendeiner Schnittstelle zu
> empfangen

In diesem Fall: Serialisierung.

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

fop schrieb:
> Wobei "bestimmter Compiler" sehr eng zu sehen ist. Ich hatte schon mal
> den Brüller, dass bei einem Update des Compilers die Reihenfolge sich
> umdrehte.

Um welchen Prozessor ging es dabei? Man kann sowas nämlich auch in 
Hardware falsch machen, um das später zu korrigieren.

Motorola hatte sich auf Befehlsebene ins Knie geschossen, weshalb die 
Einzelbitbefehle der 68000 von rechts nach links adressierten, die mit 
68020 hinzu gekommenen Bitfeldbefehle aber von links nach rechts.

> Es soll ja auch Compiler geben, die per Kommandozeilenargument oder
> Pragma Anweisung da was drehen.

Die Anordnung von Bitfeldern orientiert sich sinnvollerweise nicht an 
der offiziellen Bitreihenfolge des Prozessors, sondern an dessen 
Bytereihenfolge. Also ob das obere oder das untere Byte eines Wortes im 
Speicher adressiert wird. Es gibt allerdings Architekturen, bei denen 
diese Bytereihenfolge erst im Rahmen der Systemimplementierung 
festgelegt wird. Weshalb Compiler flexibel sein müssen.

[GEKU (Gast)]

Bitfields sind zu vermeiden:

- Register mit unterschiedlicher Bedeutung der Daten für Lesen und 
Schreiben

- Register mit spezieller Behandlung einzelner Bits, z.B. Quittierung 
von Interrupts

[GEKU (Gast)]

Bei MCs die einzelne Bits manipulieren können werden Bitfields vom 
Kompiler meist nicht effizient umgesetzt. Ist mir z.B. beim 8051 
aufgefallen. Es werden immer alle 8 Bits behandelt.

[Wilhelm M. (wimalopaan)]

fop schrieb:
> Wobei "bestimmter Compiler" sehr eng zu sehen ist. Ich hatte schon mal
> den Brüller, dass bei einem Update des Compilers die Reihenfolge sich
> umdrehte.

Deswegen sagte ich ja: implementation-defined.

Ändert sich dahingehend das ABI, hat man den Salat ...

(wobei das recht selten vorkommt ;-))

[S. R. (svenska)]

Naj H. schrieb:
> Kann ich davon ausgehen das z.B "bStepperActive"
> immer das erste Bit im "Byte" ist?

Eindeutige Antwort: Nein.

[Rolf M. (rmagnus)]

Naj H. schrieb:
> Kann ich davon ausgehen das z.B "bStepperActive" immer das erste Bit im
> "Byte" ist?

Gegenfrage: Was ist für dich "das erste Bit im Byte"? Das mit der 
höchsten oder das mit der niedrigsten Wertigkeit?

[fop (Gast)]

Rolf M. schrieb:
> Was ist für dich "das erste Bit im Byte"?

Wo wir sind ist vorne !


Sorry, couldn't resist.