BITs Bytes struct

[c beginner (Gast)]

Hallo zusammen,

folgende Aufgabe würde ich gerne lösen aber ich komme nicht auf die 
Lösung. Ich möchte einen "uint8_t" BITweise befüllen. Dazu habe ich mir 
BIT Felder angesehen wie im Tutorial beschrieben.

    struct {
        uint8_t RS:1;
        uint8_t RW:1;
        uint8_t ENABLE:1;
        uint8_t LedBacklight:1;
        uint8_t DATA_4:1;
        uint8_t DATA_5:1;
        uint8_t DATA_6:1;
        uint8_t DATA_7:1;
    } I2C_Data;

    I2C_Data.RS = 1;
    I2C_Data.RW = 0;
    I2C_Data.DATA_7 = 1;

I2C_Data hat nun auch den Wert 81H aber ist nicht vom Typ uint8_t. Will 
ich also damit weiterarbeiten dann scheint es ein int zu sein. Frage: 
Wie kann ich das so hinbekommen das I2C_Data vom Typ uint8_t ist ?

2te Frage, wie kann ich I2C_Data direkt befüllen ? eine Zuweisung wie...
I2C_Data = 0xFF;
ist ja nicht zulässig. Ich kann hier nur BITweise befüllen. Gibt es eine 
Möglichkeit auch noch direkt auf I2C_Data eine Zuweisung zu machen ?

Ich hoffe man versteht die Idee aber ich kann es nicht besser 
formulieren.

[Einer K. (Gast)]

union ? ! ?

[c beginner (Gast)]

>> union ? ! ?
Ist das eine Antwort oder Frage ? Lese mich da gerade ein aber ein 
Beispiel wäre da hilfreich.

[Cyblord -. (cyblord)]

Arduino Fanboy D. schrieb:
> union ? ! ?

Nein. Eine Union ist eben gerade NICHT zur Typumwandlung gedacht. Dafür 
nimmt man einfach einen Cast.
Eine Union soll verschiedenen Datentypen ermöglichen NACHEINANDER 
denselben Speicher zu belegen.

[Cyblord -. (cyblord)]

 I2C_Data.RS = 1;

Erst mal muss man eine Variable vom Typ des Structs erzeugen. So wie du 
das machst ist das natürlich falsch.
Wäre Äquivalent zu int=8. Macht keinen Sinn.
struct I2C_Data ist der Datentyp und noch keine Variable.

Mach I2C_Data mal zum Typen mit typedef. Macht alles leichter.

I2C_Data i2c;

i2c.RS=1;

uint8_t x=(uint8_t)i2c;

[Einer K. (Gast)]

zum Glück sagt die AVR-Gcc Doku, dass dieses unerlaubte Verfahren 
funktioniert.

Andere Kompiler können sich anders verhalten.

    struct I2CData{
        uint8_t RS:1;
        uint8_t RW:1;
        uint8_t ENABLE:1;
        uint8_t LedBacklight:1;
        uint8_t DATA_4:1;
        uint8_t DATA_5:1;
        uint8_t DATA_6:1;
        uint8_t DATA_7:1;
    };

    
    union Datensatz
    {
      I2CData asI2cData;
      uint8_t asByte;
    }datensatz;

   
    datensatz.asI2cData.RS = 1;
    datensatz.asI2cData.RW = 0;
    datensatz.asI2cData.DATA_7 = 1;
    datensatz.asByte = 0x42;

[Cyblord -. (cyblord)]

Arduino Fanboy D. schrieb:
> zum Glück sagt die AVR-Gcc Doku, dass dieses unerlaubte Verfahren
> funktioniert.

Ich weiß. Aber man sollte sich sowas erst gar nicht angewöhnen.

[c beginner (Gast)]

>> zum Glück sagt die AVR-Gcc Doku, dass dieses unerlaubte Verfahre
>> funktioniert.

Bei mir leider nicht, da hagelt es Fehlermeldungen.
request for member 'RW' in something not a structure or union
und so weiter.

@ Cyblord, kannst du deinen Ansatz mal so formulieren das ich damit was 
anfangen kann ? wie muß das mit dem typedef aussehen ? vielen Dank

[zitter_ned_aso (Gast)]

c beginner schrieb:
> Bei mir leider nicht

weil da ein "struct" vor I2CData fehlt. Aber es ist ja nur die Syntax. 
Die Idee ist doch super.


Arduino Fanboy D. schrieb:
> union Datensatz
>     {
>      struct I2CData asI2cData;
>       uint8_t asByte;
>     }datensatz;

[Niklas Gürtler (Gast)]

Hier sind die diversen Tücken und Lösungen dieses Standardproblems 
erläutert: Serialisierung

[Einer K. (Gast)]

c beginner schrieb:
> Bei mir leider nicht, da hagelt es Fehlermeldungen.

Habs mit C++ getestet.
Für C muss man das ein winziges bisschen umbauen.(typedef)
Das Prinzip kann erhalten bleiben.

[c beginner (Gast)]

@ zitter_ned_aso, danke für den Hinweis. Damit funkioniert die Version 
von Arduino Fanboy D schon einmal. Auch dir ein Danke.

Ich will den Hinweis von Cyblord dennoch ernst nehmen und würde mich 
über ein portierbares (C konformes) Beispiel freuen. Nochmals vielen 
Dank an Alle.

[Dergute W. (derguteweka)]

Moin,

c beginner schrieb:
> würde mich
> über ein portierbares (C konformes) Beispiel freuen.

i2cdata = 0x81; /* set rs=1; data_7=1; others=0 */

Muss nicht immer alles komplett overengineered werden und auf zig 
headerfiles und definitionen verteilt sein.

Gruss
WK

[Rufus Τ. F. (rufus)]

Dergute W. schrieb:
> Muss nicht immer alles komplett overengineered werden

Daß das die schlechtestmögliche Lösung ist, ist hinreichend bekannt und 
ausdiskutiert worden. "Magic Numbers" im Code gelten außerhalb Deines 
spezifischen persönlichen Standards als fehleranfällig und schlecht 
wartbar.

Dein Argument, man müsse ja eh' im Datenblatt nachsehen, macht das jetzt 
nicht besser.

[Cyblord -. (cyblord)]

c beginner schrieb:
> Ich will den Hinweis von Cyblord dennoch ernst nehmen und würde mich
> über ein portierbares (C konformes) Beispiel freuen. Nochmals vielen
> Dank an Alle.

Ich hab dir praktisch den kompletten Code hingeschrieben. Was willst du 
noch?

Wenn man structs ohne typedef verwendet, muss man immer (u.a.) immer das 
Schlüsselwort struct voranstellen. Das habe ich mir geschenkt.

Das Prinzip sollte aber wohl klar sein, zusammen mit meiner Erklärung: 
Cast statt Union.
Wenn du nicht weißt was ein Cast ist, schlags nach!

[Eric B. (beric)]

Rufus Τ. F. schrieb:
> Dergute W. schrieb:
>> Muss nicht immer alles komplett overengineered werden
>
> Daß das die schlechtestmögliche Lösung ist, ist hinreichend bekannt und
> ausdiskutiert worden. "Magic Numbers" im Code gelten außerhalb Deines
> spezifischen persönlichen Standards als fehleranfällig und schlecht
> wartbar.

Abgesehen von den Magic Numbers, die man, je nach Sprachvariante, in 
einem #define oder constexpr packen kann, ist die Lösung einfach und 
portabel und stützt nicht auf Undefined Behaviour, wie das die Lösungen 
mit structs und unions tun.

#define I2C_RS  0x01
#define I2C_RW  0x02
#define I2C_ENA 0x04
#define I2C_LED 0x08
#define I2C_DATA(x) ((x) & 0x0F) << 4)

i2c_data = I2C_RS | I2C_DATA(8);

[Tüt (Gast)]

Klammerfehler, richtig:

#define I2C_DATA(x)   (((x) & 0x0F) << 4)

[Tüt (Gast)]

#define I2C_DATA(x)   (x << 4)

ist einfacher zu lesen

[Rufus Τ. F. (rufus)]

Tüt schrieb:
> ist einfacher zu lesen

aber je nach Kontext im Vergleich zu Deiner vorherigen Variante falsch.

[c beginner (Gast)]

Nochmals meinen Dank für die Rückmeldungen. Es geht mir hier gewiss 
nicht um Abstraktion aus langeweile. Die Idee ist hier natürlich 
lesbaren Code zu schreiben und hier auch nochmal der Hinweis das ich 
gelegentlich C Programme schreibe aber das ist am Ende immer noch ein 
Hobby.

Wie in der Struktur hoffentlich zu erkennen war ging es darum ein Byte 
mittels I2C Bus zu übertragen. Dieses Byte sollte BITweise beschrieben 
werden können um dann anschließend als Byte an den I2C Layer übergeben 
zu werden.

Arduino Fanboy D hat das direkt erkannt und ich habe seine Idee auch so 
übernommen.

struct I2CData {
    uint8_t RS:1;
    uint8_t RW:1;
    uint8_t ENABLE:1;
    uint8_t Backlight:1;
    uint8_t DATA_4:1;
    uint8_t DATA_5:1;
    uint8_t DATA_6:1;
    uint8_t DATA_7:1;
};

union I2cDataSet {
    struct I2CData BIT;
    uint8_t asByte;
} I2cData;

Dank dieser Struktur kann man nun den Code, wie folgt, schreiben.

/* ---- Display Ausgabe Steuersignale ------------------------------------------------------------------- */
/*                                                                                                        */
void WriteCommandToLCD (uint8_t displayCommand)
{
    I2cData.BIT.RS = 0;                                             // Steuersignal ausgeben (RS BIT=0)
    I2cData.BIT.RW = 0;
    LCDputC (displayCommand);
    _delay_ms (5);
    I2cData.BIT.RS = 1;                                             // Zurückstellen auf Datenausgabe
}

/* ---- Display Ausgabe Zeichen ------------------------------------------------------------------------- */
/*                                                                                                        */
void LCDputC (uint8_t displayData)
{
    uint8_t n=2;                                                    // Sende 2x 4 BIT (oberes Nibble zuerst)

    do  {                                                           // oberes Nibble, Display Daten anordnen
        if (displayData & (1 << 4)) I2cData.BIT.DATA_4 = 1;
        else I2cData.BIT.DATA_4 = 0;
        if (displayData & (1 << 5)) I2cData.BIT.DATA_5 = 1;
        else I2cData.BIT.DATA_5 = 0;
        if (displayData & (1 << 6)) I2cData.BIT.DATA_6 = 1;
        else I2cData.BIT.DATA_6 = 0;
        if (displayData & (1 << 7)) I2cData.BIT.DATA_7 = 1;
        else I2cData.BIT.DATA_7 = 0;

        I2cData.BIT.RW = 0;

        I2cData.BIT.ENABLE = 1;
        I2cStart (PCF8574_Write_Adr);                               // I2C Device Adresse PCF 8574
        I2cWrite (I2cData.asByte);                                  // Daten an PCF 8574 senden
        I2cStop ();

        I2cData.BIT.ENABLE = 0;
        I2cStart (PCF8574_Write_Adr);                               // I2C Device Adresse PCF 8574
        I2cWrite (I2cData.asByte);                                  // Daten an PCF 8574 senden
        I2cStop ();

        displayData <<= 4;
    } while (--n);
    _delay_us (42);
}

Aus meiner Sicht wird der Code gut lesbar. Es hat den Vorteil das man 
nun mit einzelnen BITs (Steuerbits für das Display) die Logikpegel 
eindeutig steuern kann. Die Display Ansteuerung ist somit vom I2C Layer 
entkoppelt und das I2C Byte wird an den I2C Layer übergeben.

Folgendes würde ich gerne noch verstehen:
1. Wo findet man so einen Konstrukt in der GCC Doku ?
2. Was ist an dieser Kombi Struct / Union nicht C konform und warum ?
3. Wie kann man bei gleicher Schreibweise des Codes diese Strukur C 
konform anders formulieren ?

Im Prinzip ist die Sache aber für mich derzeit gelöst und ich bedanke 
mich nochmal hier besonders bei Arduino Fanboy D.

[Niklas G. (erlkoenig)]

c beginner schrieb:
> 1. Wo findet man so einen Konstrukt in der GCC Doku ?

Das findet man im C Standard.

c beginner schrieb:
> 2. Was ist an dieser Kombi Struct / Union nicht C konform und warum ?

Da das Ergebnis stark von der Plattform abhängt, ist es nicht portabel. 
C definiert es daher als "implementation defined", d.h. du kannst dich 
nicht auf das Ergebnis verlassen. Mit einem anderen Compiler kann etwas 
anderes herauskommen. In C++ ist es ganz verboten. "union" ist nur zum 
Speicher sparen da, nicht zum Daten konvertieren - man darf nicht einen 
Member beschreiben und dann einen anderen lesen.

c beginner schrieb:
> 3. Wie kann man bei gleicher Schreibweise des Codes diese Strukur C
> konform anders formulieren ?

Gleiche Schreibweise geht in C nicht. Korrekte Schreibweisen wurden 
genannt. Mithilfe von Bibliotheken lässt sich in C++ eine ähnliche, aber 
korrekte Schreibweise erreichen.

[Rufus Τ. F. (rufus)]

Ich hätte da noch einen Änderungsvorschlag:

struct I2CData {
    uint8_t RS:1;
    uint8_t RW:1;
    uint8_t ENABLE:1;
    uint8_t Backlight:1;
    uint8_t DATA:4;
};

union I2cDataSet {
    struct I2CData BIT;
    uint8_t asByte;
} I2cData;

und

void LCDputC (uint8_t displayData)
{
    uint8_t n=2;                                                    // Sende 2x 4 BIT (oberes Nibble zuerst)

    do  {                                                           // oberes Nibble, Display Daten anordnen
        I2cData.BIT.DATA = displayData >> 4;

        I2cData.BIT.RW = 0;

        I2cData.BIT.ENABLE = 1;
        I2cStart (PCF8574_Write_Adr);                               // I2C Device Adresse PCF 8574
        I2cWrite (I2cData.asByte);                                  // Daten an PCF 8574 senden
        I2cStop ();

        I2cData.BIT.ENABLE = 0;
        I2cStart (PCF8574_Write_Adr);                               // I2C Device Adresse PCF 8574
        I2cWrite (I2cData.asByte);                                  // Daten an PCF 8574 senden
        I2cStop ();

        displayData <<= 4;
    } while (--n);
    _delay_us (42);
}

[zitter_ned_aso (Gast)]

c beginner schrieb:
> 2. Was ist an dieser Kombi Struct / Union nicht C konform und warum ?

Ich glaube das hat was mit der Speicherbelegung zu tun. Die 
member-Variablen einer Struktur werden nicht zwangsläufig hintereinander 
im Speicher abgelegt. Es gibt Lücken, die mit padding bits gefühlt 
werden.

Wenn du so eine Struktur in eine Union packst (wie oben), dann kannst du 
nicht den gesamten struct-Block mit einer Zahl überschreiben (wie oben) 
und damit alle member-Variablen initialiseren.

[c beginner (Gast)]

>>  Rufus Τ. F Ich hätte da noch einen Änderungsvorschlag:

Sehr schön, warum seh ich sowas nicht selbst ? Vielen Dank.

[Markus F. (mfro)]

Eric B. schrieb:
> stützt nicht auf Undefined Behaviour, wie das die Lösungen
> mit structs und unions tun

Das tun sie nicht.

Bitfelder sind implementation defined (muss jeder selbst wissen, ob das 
für ihn ein k.o.-Kriterium ist oder nicht).

"Unions zur Typumwandlung" mittlerweile offiziell erlaubt.

[Eric B. (beric)]

Noch ein Änderungsvorschlag:

struct I2CData {
    uint8_t RS:1;
    uint8_t RW:1;
    uint8_t ENABLE:1;
    uint8_t Backlight:1;
    uint8_t Data: 4;
};

union I2cDataSet {
    struct I2CData BIT;
    uint8_t asByte;
} I2cData;

/* ---- Display Ausgabe Steuersignale - */
void WriteCommandToLCD (uint8_t displayCommand)
{
    I2cData.BIT.RS = 0;   // Steuersignal ausgeben (RS BIT=0)
    I2cData.BIT.RW = 0;
    LCDputNibble (displayCommand >> 4);
    LCDputNibble (displayCommand);
    _delay_ms (5);
    I2cData.BIT.RS = 1;   // Zurückstellen auf Datenausgabe
}

/* ---- Display Ausgabe Zeichen ------- */

void LCDputNibble (uint8_t displayData)
{
  I2cData.BIT.Data = displayData;

  I2cData.BIT.ENABLE = 1;
  I2cStart (PCF8574_Write_Adr); // I2C Device Adresse PCF 8574
  I2cWrite (I2cData.asByte);    // Daten an PCF 8574 senden
  I2cStop ();

  I2cData.BIT.ENABLE = 0;
  I2cStart (PCF8574_Write_Adr); // I2C Device Adresse PCF 8574
  I2cWrite (I2cData.asByte);    // Daten an PCF 8574 senden
  I2cStop ();
}

[Niklas G. (erlkoenig)]

Markus F. schrieb:
> "Unions zur Typumwandlung" mittlerweile offiziell erlaubt.

Nur in C, und das Ergebnis ist immer noch plattform-abhängig. Wenn man 
den Code auf eine andere Plattform kopiert, kann das Ergebnis komplett 
anders sein. Die "umständliche" Schreibweise mit bitweisen Operationen 
ist übrigens auch nicht weniger effizient, die Compiler können das gut 
optimieren. "union" zur Konvertierung zu verwenden ist also in 90% der 
Fälle nur der Schreibfaulheit geschuldet und resultiert in schlecht 
portier- und wartbarem Code.

[Niklas G. (erlkoenig)]

Hier ein Beispiel, wie es mit meiner µSer Bibliothek in C++ gehen kann:

#include <iostream>
#include <iomanip>
#include <cstdint>
#include <uSer.hh>

struct I2CData {
    // Begin declaration
    USER_STRUCT (I2CData, uSer::AttrNone)
    
    USER_MEM(std::uint8_t, RS, uSer::Width<1>)
    USER_MEM(std::uint8_t, RW, uSer::Width<1>)
    USER_MEM(std::uint8_t, ENABLE, uSer::Width<1>)
    USER_MEM(std::uint8_t, Backlight, uSer::Width<1>)
    USER_MEM(std::uint8_t, Data, uSer::Width<4>)
    
    // Make members known to µSer
    USER_ENUM_MEM (RS, RW, ENABLE, Backlight, Data)
} I2cData;

// Dummy
static constexpr std::uint8_t PCF8574_Write_Adr = 0x12;
void I2cStart (std::uint8_t adr) {
  std::cout << "I2cStart(0x" << std::hex << std::setw(2) << std::setfill('0') << int { adr } << ");\n";
}
void I2cWrite (std::uint8_t data) {
  std::cout << "I2cWrite(0x" << std::hex << std::setw(2) << std::setfill('0') << int { data } << ");\n";
}
void I2cStop () {
  std::cout << "I2cStop();\n";
}

void _delay_ms (...) {}

void LCDputNibble (uint8_t displayData)
{
  I2cData.Data = displayData;
  I2cData.ENABLE = 1;
  
  std::uint8_t asByte [1];
  uSer::serialize (asByte, I2cData);

  I2cStart (PCF8574_Write_Adr); // I2C Device Adresse PCF 8574
  I2cWrite (asByte [0]);    // Daten an PCF 8574 senden
  I2cStop ();

  I2cData.ENABLE = 0;
  uSer::serialize (asByte, I2cData);
  
  I2cStart (PCF8574_Write_Adr); // I2C Device Adresse PCF 8574
  I2cWrite (asByte [0]);    // Daten an PCF 8574 senden
  I2cStop ();
}


/* ---- Display Ausgabe Steuersignale - */
void WriteCommandToLCD (uint8_t displayCommand)
{
    I2cData.RS = 0;   // Steuersignal ausgeben (RS BIT=0)
    I2cData.RW = 0;
    LCDputNibble (static_cast<std::uint8_t> (displayCommand >> 4));
    LCDputNibble (static_cast<std::uint8_t> (displayCommand));
    _delay_ms (5);
    I2cData.RS = 1;   // Zurückstellen auf Datenausgabe
}


int main () {
  WriteCommandToLCD (0x34);
}

Mit Dummy-Funktionen, damit es am PC testbar ist. Es ist etwas 
umständlicher als die union-Variante, aber man kann immer noch recht 
übersichtlich die Aufteilung der Bit definieren. Dafür ist es portabel 
auf alles, was C++17 unterstützt bei exakt identischem Ergebnis, 
unabhängig von Padding-Bytes, Endianness, Alignment...

Die Bibliothek: https://github.com/Erlkoenig90/uSer

[c beginner (Gast)]

@ Eric B.
Das verändert die Funktion und ist daher keine Optimierung aber dennoch 
danke für den Versuch.

@ Niklas G.
c++ ist leider nichts für mich.

>> Nur in C, und das Ergebnis ist immer noch plattform-abhängig.
Ich habs gestern mal auf meinen diversen Compilern getestet und es 
funktioniert soweit auf diesen korrekt.

@ Markus F.
>> "Unions zur Typumwandlung" mittlerweile offiziell erlaubt.

Das ist wirklich gut zu wissen.

[Niklas G. (erlkoenig)]

c beginner schrieb:
> Ich habs gestern mal auf meinen diversen Compilern getestet und es
> funktioniert soweit auf diesen korrekt.

Solange es nur ein einzelnes Byte ist funktioniert es "vermutlich" 
überall gleich. Aber möchte man für maximal 8 Einträge so etwas 
unschönes nutzen? Unterschiedliche Compiler für den selben Prozessor 
haben wahrscheinlich oft das gleiche Ergebnis. Wenn man andere 
Prozessoren einbringt (AVR, ARM, x86, x86-64, PowerPC, DSP-Plattformen) 
sieht das vermutlich anders aus. Es funktioniert halt nur "zufällig" und 
"mit Glück".

c beginner schrieb:
> c++ ist leider nichts für mich.

Dann mach es so wie vorgeschlagen:

Eric B. schrieb:
> #define I2C_RS  0x01
> #define I2C_RW  0x02
> #define I2C_ENA 0x04
> #define I2C_LED 0x08
> #define I2C_DATA(x) ((x) & 0x0F) << 4)
>
> i2c_data = I2C_RS | I2C_DATA(8);

Lieber C als C++ verwenden zu wollen, es dann aber zu umständlich finden 
und daher lieber einen unportablen Hack verwenden ist vielleicht nicht 
die beste Herangehensweise.

[c beginner (Gast)]

>> Aber möchte man für maximal 8 Einträge so etwas unschönes nutzen?
Wie gesagt, für mich in diesem Fall ok, ich weiß ja das ich beim 
portieren dann aufpassen muß.

>> Wenn man andere Prozessoren einbringt (AVR, ARM...
Ich habs für ARM, AVR, 8x51 getestet und es passt soweit.

[Niklas G. (erlkoenig)]

c beginner schrieb:
> Ich habs für ARM, AVR, 8x51 getestet und es passt soweit.

Mach das mal mit bis zu 64bit großen Typen auf ARM und AVR. Da kommen 
dann die Unterschiede (ARM braucht Padding, AVR nicht). Hast du 
Unit-Tests geschrieben, um alle Fälle automatisiert testen zu können? 
Das ist nötig, damit du auch nach jeder kleinsten Änderung 
(Compiler-Optionen, Compiler-Version, Prozessor-Version, 
Plattform-Wechsel) prüfen kannst ob es noch stimmt.
Das gemeine an C (und C++) ist ja dass viele Dinge den Anschein haben zu 
funktionieren, aber dennoch falsch sind und früher oder später schief 
gehen können. Da kann man entweder mit viel Aufwand alles testen, oder 
es direkt richtig machen.

[Cyblord -. (cyblord)]

Aber was genau spricht denn jetzt dagegen, die Struktur einfach auf ein 
uint8 zu Casten?

[W.S. (Gast)]

Dergute W. schrieb:
> i2cdata = 0x81; /* set rs=1; data_7=1; others=0 */

Rufus Τ. F. schrieb:
> Daß das die schlechtestmögliche Lösung ist, ist hinreichend bekannt und
> ausdiskutiert worden. "Magic Numbers" im Code gelten außerhalb Deines
> spezifischen persönlichen Standards als fehleranfällig und schlecht
> wartbar.

Daß das keineswegs die schlechtestmögliche Lösung ist, sondern 
schlichtweg die pragmatischste und fehler-UN-anfälligste, ist 
hinreichend bekannt.

Die meisten Fehler kommen nämlich genau dadurch zustande, daß jemand 
überkomplizierte Konstrunkte verwendet, die oftmals auch noch über 
mehrere Quelldateien verstreut sind.

Nur die Leute, die eifrigst bemüht sind, zusätzlich zu den Regeln der 
Sprache C noch weitergehende möglichst einschränkende Regeln zu 
erfinden, pflichten deiner Ansicht bei. Ich nicht. Mein Horizont ist 
größer als nur C.

Mal zur Richtigstellung des Ganzen:
Es geht - so wie sich mir das darstellt - um Hardware-Angelegenheiten, 
also um ganz spezielle Registerbelegungen, die nur für eine einzige 
Hardware (hier wohl AVR) zutreffen.

Deshalb sind erstens alle Argumente bezüglich einer Portierbarkeit 
gegenstandslos. Einen speziellen Lowlevel-Hardwaretreiber kann man 
nirgendwohin portieren.

Zweitens gehören solche Dinge wie die Belegung eines HW-Registers in 
einen genau dafür zuständigen Treiber und haben gefälligst dort drin 
gekapselt zu sein, so daß man außerhalb eben dieses Treibers auf gar 
keinen Fall mit derartigen Details in Berührung kommt.

Und deshalb ist die allereinfachste und pragmatischste Ausführung 
dessen, was tatsächlich dort drin getan werden muß, auch die beste. Ohne 
irgendwelche Verrenkungen. Und wer dort drin herumwursteln will, hat 
gefälligst das betreffende Kapitel im Manual zu studieren.

Kurzum, Rufus, du liegst mit deiner hier vorliegenden Verallgemeinerung 
mal wieder falsch.

W.S.

[Niklas G. (erlkoenig)]

Cyblord -. schrieb:
> Aber was genau spricht denn jetzt dagegen, die Struktur einfach auf ein
> uint8 zu Casten?

Das Gleiche wie bei union. Das Ergebnis ist plattform-abhängig. 
Bitfelder sind nicht portabel.

[Niklas G. (erlkoenig)]

W.S. schrieb:
> Es geht - so wie sich mir das darstellt - um Hardware-Angelegenheiten,
> also um ganz spezielle Registerbelegungen, die nur für eine einzige
> Hardware (hier wohl AVR) zutreffen.

Es ist die Registerbelegung eines Displays. Das könnte man durchaus auch 
mal an einem ARM anschließen.

[Rufus Τ. F. (rufus)]

W.S. schrieb:
> Kurzum, Rufus, du liegst mit deiner hier vorliegenden Verallgemeinerung
> mal wieder falsch.

Geisterfahrer, tausende.

Ich bewundere zwar Deinen Ehrgeiz, anderen Leuten das C-Programmieren 
nahebringen zu wollen ("Lernbetty" etc.), kann mich aber mit Deinen 
elementaren Einstellungen zu Sprachdetails überhaupt nicht anfreunden.

Ich verdiene seit mehreren Jahrzehnten meinen Lebensunterhalt damit, daß 
ich mit dieser Sprache arbeite, und ich sehe recht viel professionellen, 
von anderen Leuten geschriebenen Code.

"Magic numbers" im Quelltext verwendet praktisch niemand davon - aus 
gutem Grund: Das ist wartungsfeindlich und fehlerträchtig.

> Deshalb sind erstens alle Argumente bezüglich einer Portierbarkeit
> gegenstandslos. Einen speziellen Lowlevel-Hardwaretreiber kann man
> nirgendwohin portieren.

Genau das kann man. Wenn man keine "magic numbers" verwendet.