Byte bitweise und als ganzes zugreifen als Datentyp in c

[Martin S. (mmaddin)]

Hallo zusammen,

ich möchte auf ein Byte bitweise und auch als ganzes zugreifen.

typedef struct led1bits
{
  uint8_t led1 :1,
          led2 :1,
          led3 :1,
          led4 :1,
          led5 :1,
          led6 :1,
          led7 :1,
          led8 :1;
};

led1bits leds;

Aber wie bekomme ich das ganze in eine union, sodass ich auch leds.byte 
schreiben kann? Es war ganz einfach, oder kann ich das Bitfeld auch 
direkt in der union amlegebn? wenn ja, wie geht das noch, sodass ich es 
als Datentyp wie ein int einsetzen kann?

Es ist zu lang her...

Danke

[Rahul D. (rahul)]

Martin S. schrieb:
> typedef struct led1bits
> {
>   uint8_t led1 :1,
>           led2 :1,
>           led3 :1,
>           led4 :1,
>           led5 :1,
>           led6 :1,
>           led7 :1,
>           led8 :1;
> };

typedef union led1union
{
 struct led1bits;
 uint8_t led1byte
};

[Johann L. (gjlayde)]

Martin S. schrieb:
> Aber wie bekomme ich das ganze in eine union, sodass ich auch
> leds.byte schreiben kann?

Das geht im einer GNU-C Erweiterung, "anonymous Struct" oder wie das 
heißt:

typedef union
{
    struct
    {
       uint8_t bit0 :1;
       uint8_t bit1 :1;
       uint8_t bit2 :1;
       uint8_t bit3 :1;
       uint8_t bit4 :1;
       uint8_t bit5 :1;
       uint8_t bit6 :1;
       uint8_t bit7 :1;
    };
    uint8_t byte;
} led_t

Damit geht der Zugriff dann so:

    led_t led;
    led.byte = 0x42;
    led.bit2 = 1;

Mit Standard-C muss die Struct benamt sein, also

typedef union
{
    struct
    {
       ...
    } bits;
    uint8_t byte;
} led_t

mit Zugriff:

    led.byte = 0x42;
    led.bits.bit2 = 1;

[Martin S. (mmaddin)]

Johann L. schrieb:
> Das geht im einer GNU-C Erweiterung,

Genau das habe ich gesucht, wollte mir alle "Zwischenamen" sparen, 
wusste aber nicht mehr, wie ich das ideal verschachteln kann, klasse, 
läuft schon, vielen Dank.

Ich mache das mit dem struct allerdings so:
struct
{
  uint8_t led1 :1,
          led2 :1,
          led3 :1,
          led4 :1,
          led5 :1,
          led6 :1,
          led7 :1,
          led8 :1;
};

 Wird das:

    struct
    {
       uint8_t bit0 :1;
       uint8_t bit1 :1;
       uint8_t bit2 :1;
       uint8_t bit3 :1;
       uint8_t bit4 :1;
       uint8_t bit5 :1;
       uint8_t bit6 :1;
       uint8_t bit7 :1;
    };

nachher wirklich ein byte?

würde dann ja auch so gehen:

    struct
    {
       bool bit0 :1;
       bool bit1 :1;
       bool bit2 :1;
       bool bit3 :1;
       bool bit4 :1;
       bool bit5 :1;
       bool bit6 :1;
       bool bit7 :1;
    };

[Rahul D. (rahul)]

Martin S. schrieb:
> nachher wirklich ein byte?

Teste es mit "sizeof"!

Martin S. schrieb:
> struct
>     {
>        bool bit0 :1;
>        bool bit1 :1;
>        bool bit2 :1;
>        bool bit3 :1;
>        bool bit4 :1;
>        bool bit5 :1;
>        bool bit6 :1;
>        bool bit7 :1;
>     };

Bool ist doch ein int und das ist 16Bit breit.

[Nemopuk (nemopuk)]

Rahul D. schrieb:
> Bool ist doch ein int und das ist 16Bit breit.

Mindestens bei AVR, ARM Cortex-M und gcc für Linux sind 8 Bit schon 
richtig. Bool ist ein unsigned char, nicht int.

[Christian M. (christian_m280)]

Warum tut Ihr Euch das an? Findet Ihr das geil, solche Konstrukte, nur 
um ein Bit zu adressieren? Dass man sowas überhaupt fragen muss, 
unglaublich! Nur weil Euer lustiges C "Standard" ist...

Bit-Adressierung in mikroBasic:

PORTB.5 = 0

Und in Oshonsoft-Basic:

TRISA.1 = 0

Low-Byte und High-Byte:

i = x.LB
j = x.HW

Während Ihr Euch mit der Syntax abmüht, kann man sich in anderen 
Programmiersprachen auf die Aufgabe konzentrieren!

Gruss Chregu

[Rahul D. (rahul)]

Christian M. schrieb:
> Während Ihr Euch mit der Syntax abmüht, kann man sich in anderen
> Programmiersprachen auf die Aufgabe konzentrieren!

"Kein ernsthafter Programmierer über 12 Jahre arbeitet mit Basic." - 
Spruch eines Profs aus dem Studium.
Basic ist was für alte Leute, die das vor zig Jahren mal gelernt haben 
(in der DDR war es wohl noch ziemlich verbreitet) oder was zum Einstieg.
Statt Basic nimmt man inzwischen doch eher python.

Christian M. schrieb:
> Oshonsoft-Basic:
Teuer...
> mikroBasic:
gleiches Problem.


gcc? Kost nix außer Hirnschmalz.

Außerdem ist C bei Mikrocontrollern wohl verbreiter als Basis.

[Nemopuk (nemopuk)]

Christian M. schrieb:
> Findet Ihr das geil, solche Konstrukte,

Es geht nicht darum, was wir geil finden. Wir können uns die 
Programmiersprache nicht einfach frei aussuchen.

Nur weil Microbasic hier und da eleganter ist, kann es noch lange nicht 
C ersetzen. Das closed-source Modell ist für viele Firmen schon ein 
Blocker. Dazu kommen zahlreiche bewährte Bibliotheken, die man nicht 
ohne wichtigen Grund neu schreibt. Die performance wäre auch noch ein 
Punkt.

[Joachim B. (jar)]

Rahul D. schrieb:
> "Kein ernsthafter Programmierer über 12 Jahre arbeitet mit Basic." -
> Spruch eines Profs aus dem Studium.

komisch in meinem E-Technik Studium zum Diplomingenieur war Basic am 
Terminal vom Großrechner Standard. Wir waren ALLE über 12 Jahre.
OK, ernsthaft programmieren wollten die meisten wohl nicht machen 
deswegen ja E-Technik und nicht Informatik.

[Gunnar F. (gufi36)]

Joachim B. schrieb:
> komisch in meinem E-Technik Studium zum Diplomingenieur war Basic am
> Terminal vom Großrechner Standard.

Wann? Ich durfte Assembler auf 8086 am Großrechner-Terminal lernen. War 
Anno 1986.

[Rahul D. (rahul)]

Joachim B. schrieb:
> komisch in meinem E-Technik Studium zum Diplomingenieur war Basic am
> Terminal vom Großrechner Standard.
Vermutlich weil die Konstrukteure des Großrechners das so wollten.
Großrechner != Mikrocontroller

> Wir waren ALLE über 12 Jahre.
Ja, und zu dem Spruch sollte man sich noch das Grinsen des Profs denken.
Im Bildverarbeitungslabor haben wir mit VisualBasic programmiert.
Einerseits gab es das damals (Anfang der 2000er) schon kostenlos von MS, 
andererseits hatten wir eine großen Anteil Kommilitonen, die gerade mal 
ihren PC zum Schreiben der Hausaufgaben einschalten konnten.

> OK, ernsthaft programmieren wollten die meisten wohl machen deswegen ja
> E-Technik und nicht Informatik.
Informatik hat eigentlich nur zweitrangig was mit der Verwendung von 
Programmiersprachen zu tun. Das ist (an der Uni) ziemlich theoretischer 
Kram, weswegen viele lieber an die FH gegangen sind (andere haben eine 
Ausbildung angefangen...).

[Gunnar F. (gufi36)]

Rahul D. schrieb:
> andere haben eine Ausbildung angefangen...

Das würde mich mal aus der Praxis interessieren: Der Beruf des 
Fachinformatiker für Anwendungsentwicklung: Wie viele davon entwickeln 
tatsächlich Anwendungen?

In meinem Berufsleben habe ich überwiegend Elektroingenieure kennen 
gelernt, die als Quereinsteiger programmieren.

[Joachim B. (jar)]

Rahul D. schrieb:
> Informatik hat eigentlich nur zweitrangig was mit der Verwendung von
> Programmiersprachen zu tun.

und trotzdem hatten wir in der Industrie eine studentische Hilfskraft 
die "unseren Ing. Code" sauber in Libs umsetzte damit sie für alle 
nutzbar wurde, stellenweise sogar in ASM weil der Prüfrechner PC zu 
wenig Speicher hatte.

Gunnar F. schrieb:
> In meinem Berufsleben habe ich überwiegend Elektroingenieure kennen
> gelernt, die als Quereinsteiger programmieren.

wie alle bei "uns" in der Prüfmittelentwicklung.

Der Abteilungsleiter war sogar verwundert warum unser Werkstudent die 
größte teuerste Maschine ein 486er mit 19" Monitor für 25.000,- DM bekam 
und nicht der Projekt führende Ingenieur. Wir mustem dem 
Abteilungsleiter erklären das alle Prüfingnieure davon provitieren wenn 
die studentische Hilfskraft mehr Compilerläufe pro Tag schafft, während 
wir auf dem blinkenden Cursor schauend über den nächsten Programmteil 
nachdachten, top down Entwicklung.

[Norbert (der_norbert)]

Ich finde es erstaunlich, dass man überhaupt auf einen solch dummen 
Kommentar eingeht.

Die korrekte Vorgehensweise wäre bei der bloßen Erwähnung von
>  … Basic …

Ein Folgeeintrag als Antwort (Ein einziger!):

* Im Titel steht ›C‹
* Im Eröffnungsbeitrag steht ›C‹
* Die Frage bezieht sich auf ›C‹

[Rahul D. (rahul)]

Norbert schrieb:
> Ein Folgeeintrag als Antwort (Ein einziger!):
>
> * Im Titel steht ›C‹
> * Im Eröffnungsbeitrag steht ›C‹
> * Die Frage bezieht sich auf ›C‹

Da das Ursprungsthema abgehandelt ist, kann man auch wieder etwas 
offtopic werden...

[Johannes (zuberjo)]

Basic spielt heute im E-Technik Studium keine Rolle mehr. C, C++, Java, 
C# und geringfügig Assembler. Zusätzlich noch ein wenig VHDL und mehr 
brauchts auch nicht im Berufsleben als E-Techniker. Und wenn doch, dann 
kann man es auch da noch lernen. Die Alten sehen das vllt anders.

Das mit dem Struct, union und Zuweisung mit Doppelpunkt ist jedenfalls 
sehr interessant und werde ich bei mir in C Projekten definitiv mal 
anwenden. Bisher hatte ich mir enumerationen erstellt und einzelne Bits 
über Bitoperatoren verändert.

uint8_t var
enum{
  Bit0 = 1,
  Bit1 = 2
}
Bit setzen: var |= (1<<Bit0)
Bit löschen dann var &= ~(1<<Bit0)

Ist auch ok und funktioniert halt auch genau so in C#. Werde jetzt kein 
Projekt umschreiben, aber bei einem neuen das mit den Struct mal 
ausprobieren

[Norbert (der_norbert)]

Johannes schrieb:
> Ist auch ok und funktioniert halt auch genau so in C#. Werde jetzt kein
> Projekt umschreiben, aber bei einem neuen das mit den Struct mal
> ausprobieren

Wenn man sich jetzt noch daran erinnert, dass man aus einer Union immer 
nur das ausliest, was man zuvor hinein geschrieben hat, dann ist alles 
prima.
* uint8_t ──▶ uint8_t
* bits ──▶ bits

Nicht aber:
* uint8_t ──▶ bits
* bits ──▶ uint8_t

[Nemopuk (nemopuk)]

Norbert schrieb:
> Nicht aber ...

Wetten, genau das war aber die Intention dahinter?

[Rahul D. (rahul)]

Norbert schrieb:
> Nicht aber:
> * uint8_t ──▶ bits
> * bits ──▶ uint8_t

Warum nicht?
Warum funktioniert das bei mir?

[Norbert (der_norbert)]

Nemopuk schrieb:
> Norbert schrieb:
>> Nicht aber ...
>
> Wetten, genau das war aber die Intention dahinter?

Ja klar war sie das, da würde ich doch nie dagegen wetten.

[Norbert (der_norbert)]

Rahul D. schrieb:
> Warum nicht?
> Warum funktioniert das bei mir?

Wenn man es testet und es funktioniert, dann funktioniert es. Oh Wunder.
Es funktioniert DIESES Mal. Auf DIESER Architektur und mit DIESEM 
Compiler auf DIESEM Release-Stand.

Das mag für's Hobby oftmals genug sein.
Aber ernsthaft darauf verlassen solltest du dich besser nicht.

[Rahul D. (rahul)]

Norbert schrieb:
> Es funktioniert DIESES Mal. Auf DIESER Architektur und mit DIESEM
> Compiler auf DIESEM Release-Stand.
Wir verwenden es auch in der Firma.
Liegt wohl daran, dass wir da nur Controller mit dem selben Endian 
verwenden (STM32 und AVR).
Der arm-Compiler ist inzwischen ein neues Release, und der "alte Kram" 
funktioniert trotzdem (wäre auch dämlich von Hitex, das einfach mal zu 
ändern)-

Norbert schrieb:
> Das mag für's Hobby oftmals genug sein.
> Aber ernsthaft darauf verlassen solltest du dich besser nicht.

Man sollte schon wissen was man tut...

[Bruno V. (bruno_v)]

Rahul D. schrieb:
> Warum nicht?
> Warum funktioniert das bei mir?

In C sind unions nur Container für verschiedene Datentypen, aber nicht 
zur Wandlung.

Es kommt zudem mit so vielen Unbekannten (Alignment, Reihenfolge, 
interne Darstellung von z.B. Pointern oder Float), dass es keinen Sinn 
macht, dafür "allgemeingültige" Regeln aufzustellen.

die einzige "erlaubte" Umwandlung ist von einen Datentyp in Bytes und 
vice versa. Deshalb funktioniert z.B. memcpy.

Das es von den meisten trotzdem zuverlässig angewendet wird, geschenkt. 
Dass andere auf irgendwelche Serialisierungen bestehen, auch.

Für Beispiele des TOs nutze ich praktisch nur noch Funktionen/Makros, 
die z.B. den LED-Typ in BYTE konvertieren. Plus ein paar 
Compile-Time-Asserts, die zumindest Allignment und Size überwachen.

uint8_t Led2B(led1bits leds)
{
    return *((uint8_t *)&leds);
}
led1bits B2Led(uint8_t b)
{
    return *((led1bits *)&b);
}

oder

#define bacc(d) (*((uint8_t *) &d))

   uint8_t x = bacc(led1);
   ...
   bacc(led1) = 0x55;

[Joachim B. (jar)]

Rahul D. schrieb:
> Man sollte schon wissen was man tut...

gilt aber nicht für die Systementscheider, die entscheiden nur und oft 
ohne Wissen, Wissen hindert zu oft an Entscheidungen.

[Johannes (zuberjo)]

Norbert schrieb:
> Nemopuk schrieb:
>> Norbert schrieb:
>>> Nicht aber ...
>>
>> Wetten, genau das war aber die Intention dahinter?
>
> Ja klar war sie das, da würde ich doch nie dagegen wetten.

Viel Meinung, wenig Ahnung. Kein Plan was der Usecase wäre, wie es mit 
Evaluierung etc aussieht aber schon das Ergebnis kennen..

[Norbert (der_norbert)]

Rahul D. schrieb:
> Man sollte schon wissen was man tut...

Da stimme ich dir zu, hatte ich allerdings als Voraussetzung angenommen.

Dann jedoch geht der Alte und es kommt der nächste Entwickler. Und 
verlässt sich auf saubere Programmierung in den zig-tausend Zeilen Code.
Nicht auf verborgene Tretminen.

[Norbert (der_norbert)]

Johannes schrieb:
> Viel Meinung, wenig Ahnung. Kein Plan was der Usecase wäre, wie es mit
> Evaluierung etc aussieht aber schon das Ergebnis kennen..

Das ist nun hohles Geschwätz, wenn man dein ursprüngliches Statement 
auch nur halbwegs ernst nimmt.

[Rahul D. (rahul)]

Joachim B. schrieb:
> gilt aber nicht für die Systementscheider, die entscheiden nur und oft
> ohne Wissen, Wissen hindert zu oft an Entscheidungen.

Politisches BlaBlaBla hat hier nichts zu suchen.
Selber machen! Besser machen!

[Rahul D. (rahul)]

Norbert schrieb:
> Dann jedoch geht der Alte und es kommt der nächste Entwickler. Und
> verlässt sich auf saubere Programmierung in den zig-tausend Zeilen Code.
> Nicht auf verborgene Tretminen.

Gibt's bei uns nicht in der Form. Dann müssten gleich alle Softies 
hinschmeißen, und dafür ist unser Betriebsklima zu gut. (Und ich 
verlassen den Betrieb entweder als Rentner oder auf ner Bare).

[Johannes (zuberjo)]

Norbert schrieb:
> Das ist nun hohles Geschwätz, wenn man dein ursprüngliches Statement
> auch nur halbwegs ernst nimmt.

Nein, nicht unbedingt. Zb eine MCU als Schnittstelle zwischen Elektronik 
und SPS. In einer Statusvariablen werden per Interrupt Bits gesetzt oder 
gelöscht. Der MCU ist hier der Datentyp egal. Die Statusvariable kann zb 
ein 16 Bit Short sein oder ein Struct. Wenn der Struct im Speicher die 
Größe einer Short hat, dann kann er auch als solcher gecastet und an die 
SPS weitergeleitet werden. Mir geht es primär um die Lesbarkeit von 
Code. Dies wäre bei einem Struct besser als mit Bitoperatoren

[Joachim B. (jar)]

Rahul D. schrieb:
> Politisches BlaBlaBla

nix Politik, Erfahrung aus 12 Jahren Industriezeit, wenn du da an 
Politik denkst kann ich dir nicht übelnehmen.

[Norbert (der_norbert)]

Johannes schrieb:
> Mir geht es primär um die Lesbarkeit von
> Code. Dies wäre bei einem Struct besser als mit Bitoperatoren

Eigentlich ist schon alles gesagt, daher vielleicht nur noch folgender 
(ganz allgemein geltender) Gedanke:
Wer mit Bitoperationen und einfacher boolescher Algebra in ›C‹ nicht 
klarkommt, der sollte besser erneut lesen und lernen. Oder eine 
einfachere Programmiersprache (vielleicht mit BA beginnend…) benutzen.

Die üblichen AND, OR, XOR und NOT Operationen lesen sich jedenfalls 
praktisch von allein und brauchen keinen syntaktischen Gehgips.

[Harald K. (kirnbichler)]

Johannes schrieb:
> uint8_t var
> enum{
>   Bit0 = 1,
>   Bit1 = 2
> }
> Bit setzen: var |= (1<<Bit0)
> Bit löschen dann var &= ~(1<<Bit0)

Hmm. Interessante Defintion für "Bit0".

Welchen Wert hätte in Deinem enum der Wert "Bit7"?

[Johannes (zuberjo)]

Harald K. schrieb:
> Welchen Wert hätte in Deinem enum der Wert "Bit7"?

War ein Beispiel und keine Stackoverflow Lösungsfunktion. Kanns du aber 
dennoch gerne per copy paste verwenden und dich danach wundern warum es 
nicht geht.

[Μαtthias W. (matthias)]

Johannes schrieb:
> Basic spielt heute im E-Technik Studium keine Rolle mehr. C, C++, Java,
> C# und geringfügig Assembler. Zusätzlich noch ein wenig VHDL und mehr
> brauchts auch nicht im Berufsleben als E-Techniker.

Stand heute würde ich da mindestens eine Scriptsprache (aktuell wohl 
Python) und evtl. noch Rust ergänzen. Bin jetzt Mitte 40, mit ASM und C 
"groß" geworden und würde mir nicht zutrauen zu sagen das das in der 
Zeit gelernte C++, Perl und Python für das verbleibende Berufsleben 
reicht. Programmiersprachen kommen und gehen. Für die reine 
Anwendungsentwicklung übernimmt die KI gerade jede Menge 
Programmiersprachengefummel. Und auch im maschinennahen Bereich wird das 
erschreckenderweise immer besser.

Matthias

[Harald K. (kirnbichler)]

Johannes schrieb:
> War ein Beispiel und keine Stackoverflow Lösungsfunktion.

War ein fehlerhaftes Beispiel.

[Johann L. (gjlayde)]

Norbert schrieb:
> Wenn man sich jetzt noch daran erinnert, dass man aus einer Union immer
> nur das ausliest, was man zuvor hinein geschrieben hat, dann ist alles
> prima.
> * uint8_t → uint8_t
> * bits → bits
>
> Nicht aber:
> * uint8_t → bits
> * bits → uint8_t

Doch, das ist kein Problem da es um GCC geht.

https://gcc.gnu.org/bugs/#nonbugs_c

> To fix the code above, you can use a union instead of a cast
> (note that this is a GCC extension which might not work with
> other compilers)

Soweit ich weiß ist es auch in neueren C/C++ Standards erlaubt; bin 
jetzt aber zu faul zum suchen.

[Alexander (alecxs)]

Rahul D. schrieb:
> Da das Ursprungsthema abgehandelt ist, kann man auch wieder etwas
> offtopic werden...

Ist denn das Problem der Endianess mit union umschifft?

[Harald K. (kirnbichler)]

Alexander schrieb:
> Ist denn das Problem der Endianess mit union umschifft?

Bei einem 8-Bit-Datentyp?

Es gibt keine unterschiedliche Bitreihenfolge, nur eine unterschiedliche 
Bytereihenfolge.

0x1234 liegt im Big-Endian-Fall als 0x12 0x34 im Speicher
und im Little-Endian-Fall als 0x34 0x12.

[Johann L. (gjlayde)]

Harald K. schrieb:
> Es gibt keine unterschiedliche Bitreihenfolge, nur eine unterschiedliche
> Bytereihenfolge.

// gcc bit.c -o bit.x && ./bit.x

#include <stdio.h>
#include <stdint.h>

typedef union
{
    struct
    {
        uint8_t b0:1, b1:1, b2:1, b3:1, b4:1, b5:1, b6:1, b7:1;
    };
    uint8_t byte;
} data_t;

data_t data;

int main (void)
{
    data.b0 = 1;
    printf ("data.byte = 0x%x\n", data.byte);
    return 0;
}

Auf IBM POWER7 8231-E2B (big-endian):

$ gcc bit.c -o bit.x && ./bit.x
data.byte = 0x80

[Johann L. (gjlayde)]

...dito auf Sun LDOM (big-endian) UltraSparc T5 (sparc64):

$ gcc bit.c -o bit.x && ./bit.x
data.byte = 0x80

[Harald K. (kirnbichler)]

Na gut. Dann sind Bitfelder für so eine Anwendung komplett sinnlos.

Danke für die Demonstration.

[Alexander (alecxs)]

Auf dem ESP32 habe ich die Structs in der richtigen Bytefolge aber mit 
absteigender Bitfolge anlegen müssen.

struct {
       uint8_t bit7  :1;
       uint8_t bit6  :1;
       uint8_t bit5  :1;
       uint8_t bit4  :1;
       uint8_t bit3  :1;
       uint8_t bit2  :1;
       uint8_t bit1  :1;
       uint8_t bit0  :1;

       uint8_t bit15 :1;
       uint8_t bit14 :1;
       uint8_t bit13 :1;
       uint8_t bit12 :1;
       uint8_t bit11 :1;
       uint8_t bit10 :1;
       uint8_t bit9  :1;
       uint8_t bit8  :1;
    } byte;

[Harald K. (kirnbichler)]

Dann kann ich das eben von mir gesagte nur nochmal wiederholen:

Bitfelder sind nutzlos.

[Nemopuk (nemopuk)]

Das wäre mir zu fehlerträchtig. Es gibt genug etablierte Alternativen, 
die sicher und verständlich sind.

[Norbert (der_norbert)]

Harald K. schrieb:
> Dann kann ich das eben von mir gesagte nur nochmal wiederholen:
>
> Bitfelder sind nutzlos.

Ich würde sie jetzt nicht als nutzlos ansehen, nur sollte man sie eben 
nicht als allgemein gültiges Konvertierungswerkzeug misshandeln.

Zumindest früher™ konnte man damit wertvollen** Platz sparen, wenn man 
nur eine größere Menge einzelner Bits speichern wollte.

**Im wahrsten Sinne des Wortes

[Arduino F. (Firma: Gast) (arduinof)]

Rahul D. schrieb:
>>        bool bit7 :1;
>>     };
>
> Bool ist doch ein int und das ist 16Bit breit.

Bool ist an der Stelle nur 1 Bit breit, dank des :1

[Alexander (alecxs)]

Für dreckige Hobbybasteleien reichts, es muss ja nicht MISRA konform 
sein.

[Bruno V. (bruno_v)]

Alexander schrieb:
> Auf dem ESP32 habe ich die Structs in der richtigen Bytefolge aber mit
> absteigender Bitfolge anlegen müssen.

i.d.R. kann man die Bit-Reihenfolge mit einem Compilerschalter ändern.

Bei einer Big-Endian-Maschine, gibt es das Problem, dass man 
unterschiedliche Anordnungen braucht, je nachdem ob man Byteweise darauf 
zugreifen möchte oder mit breiteren Werten (unsigned short, int oder 
long).

[Rahul D. (rahul)]

Μαtthias W. schrieb:
> Programmiersprachen kommen und gehen.

Außer welche mit C im Namen.

Alexander schrieb:
> Ist denn das Problem der Endianess mit union umschifft?

Das war nicht die Ursprungsfrage.

Arduino F. schrieb:
> Bool ist an der Stelle nur 1 Bit breit, dank des :1

Nach meinem Verständnis beschreibt Bool den Typ, von dem die struct 
abgeleitet ist. Bool ist eh meist nur eine Makroname, der durch einen 
anderen ersetzt wird (z.B. int).
Solange der Prozessor keine Möglichkeit der 1-Bit-Adressierung (wie 
8051) hat, wird der Compiler daraus immer Bitschubscherei machen.

[Alexander (alecxs)]

Rahul D. schrieb:
> Das war nicht die Ursprungsfrage.

Martin S. schrieb:
> Byte bitweise und als ganzes zugreifen als Datentyp in c

Die Frage sehe ich noch nicht gelöst, das geht wohl nur sicher mit 
Bitmasken.

Oder man nutzt predefined Macros (Gnu oder Posix?) sofern für Bitfolge 
etwas  derartiges vorhanden. Aus der Byte Endianess ableiten reicht in 
der Praxis vermutlich.

typedef union {
    struct bits_t {
#if __BYTE_ORDER == __LITTLE_ENDIAN
        bool bit0 : 1;
        bool bit1 : 1;
        bool bit2 : 1;
        bool bit3 : 1;
        bool bit4 : 1;
        bool bit5 : 1;
        bool bit6 : 1;
        bool bit7 : 1;
#elif __BYTE_ORDER == __BIG_ENDIAN
        bool bit7 : 1;
        bool bit6 : 1;
        bool bit5 : 1;
        bool bit4 : 1;
        bool bit3 : 1;
        bool bit2 : 1;
        bool bit1 : 1;
        bool bit0 : 1;
#endif
    } __attribute__((__packed__)) bits;
    uint8_t byte;
} bitfield_t;

[Rahul D. (rahul)]

Alexander schrieb:
> Aus der Byteendianess ableiten reicht in
> der Praxis vermutlich.

Wenn man unbedingt Endians durcheinanderschmeissen will...
Der Wunsch nach "Portabilität" findet irgendwo sein Ende.

[Joachim B. (jar)]

Rahul D. schrieb:
> Der Wunsch nach "Portabilität" findet irgendwo sein Ende.

Alles findet irgenwo ein Ende, selbst unser Leben, selbst die Sonne, 
also ist dieser Satz eine Nullinformation und überflüssig.

Bis dahin kann man (oder ich) auf zu kleine Speicher eben diesen 
sparsamer nutzen wenn es benötigt wird.

[Cyblord -. (cyblord)]

Joachim B. schrieb:
> Rahul D. schrieb:
>> Der Wunsch nach "Portabilität" findet irgendwo sein Ende.
>
> Alles findet irgenwo ein Ende, selbst unser Leben, selbst die Sonne,
> also ist dieser Satz eine Nullinformation und überflüssig.

Nein er hat recht. Sie findet ihr Ende in einer gut gemachten HAL oder 
in HW-unabhängigen Modulen.
Hat man sowas, macht es also richtig, kann man über die Methode WIE man 
letztlich einen Pin setzt nur lächeln. Es hat keine Bedeutung mehr und 
es lohnt nicht sich damit zu verkünsteln. Weil es dann nur noch an ganz 
wenigen Stellen im Programm vorkommt. Und das ist mal nicht die 
Applikationslogik.

> Bis dahin kann man (oder ich) auf zu kleine Speicher eben diesen
> sparsamer nutzen wenn es benötigt wird.

Weil man oder du einfach keine Ahnung von guter SW-Entwicklung haben und 
gute und sinnvolle Abstraktion nicht verstehen geschweige denn 
implementieren können.
Speicher ist heute sicher nicht dein Problem. Es ist wenn dann eine 
Ausrede für fehlende Skills.

[Thilo R. (harfner)]

Ich mache jetzt mal den Erbsenzähler: der C Standard legt die 
Reihenfolge der Bitfields innerhalb eines Bytes nicht fest. Theoretisch 
könnten verschiedene Compiler für die gleiche Plattform das 
unterschiedlich handhaben. Und das ist streng genommen unabhängig von 
Endianess.
In der Praxis fällt beides zusammen, man hat also nur die beiden Fälle.

Das führt dazu, dass der wichtigere der beiden Anwendungsfälle von 
Bitfields nicht sicher funktioniert.  Es bleibt nur der Aspekt "Platz 
sparen".

[M.A. S. (mse2)]

Joachim B. schrieb:
> komisch in meinem E-Technik Studium zum Diplomingenieur war Basic am
> Terminal vom Großrechner Standard.
Basic als Standard auf einem Großrechner und das an einer Uni?
Mich würde ernsthaft interessieren, wann und wo das gewesen sein soll.

1985 an der TU Berlin hat man E-Technikstudenten im ersten Semester 
Programmieren mit Pascal näherzubringen versucht. Das lief auch auf den 
Terminals eines Großrechners.

[Martin S. (mmaddin)]

Hallo,

ich nutze das in dieser Form:

typedef union
{
  struct
  {
   uint32_t btn1  :1,
            btn2  :1,
            btn3  :1,
            btn4  :1,
            btn5  :1,
            btn6  :1,
            btn7  :1,
            btn8  :1,
            btn9  :1,
            btn10 :1,
            btn11 :1,
            btn12 :1,
            btn13 :1,
            btn14 :1,
            btn15 :1,
            btn16 :1,
            btn17 :1,
            btn18 :1,
            btn19 :1,
            btn20 :1,
            btn21 :1,
            btn22 :1,
            btn23 :1,
            btn24 :1,
            btn25 :1,
            btn26 :1,
            btn27 :1,
            btn28 :1,
            btn29 :1,
            btn30 :1,
            btn31 :1,
            btn32 :1;
  };
  struct
  {
     uint32_t byte1 :8,
              byte2 :8,
              byte3 :8,
              byte4 :8;
  };
  uint8_t byte[4];
  uint32_t all;
}buttons_t;

Die Struktur benötigt wie erwartet in Summe 4 Bytes. "all" nutze ich um 
alles auf null zu setzen, die bytes meistens in den 
Verarbeitungsroutinen und die Bitzugriffe dann in den Menüs oder im 
höheren code. Passt ganz gut für meine Zwecke. Klar gibt es viele Wege 
nach Rom in C, aber das hier gefällt mir momentan ganz gut, habe eine 
Zeit lang auch vieles mit Makros gemacht...

Danke nochmals.

[Alexander (alecxs)]

Wie gesagt das ist Glück wenn es bei Dir so funktionieren sollte 
(Bitfolge getestet?) Ebenso Deine byte Zugriffe sind von Endianness 
abhängig und nicht portabel. Hinzu kommt Padding compilerabhängig fürs 
Alignment.

[Martin S. (mmaddin)]

Alexander schrieb:
> Bitfolge getestet?

Ja, da ich sie alle nutze, außer bei "all" damit setze ich ja nur auf 
null.

Alexander schrieb:
> sind von Endianness
> abhängig und nicht portabel

Ist mir bekannt das Thema.

Alexander schrieb:
> Padding

Sagt mir nichts....aber hier sind die Anteile alle doch immer 32 Bit 
groß...

[Bruno V. (bruno_v)]

Alexander schrieb:
> Wie gesagt das ist Glück wenn es bei Dir so funktionieren sollte

Manchmal muss man auch mal einen Nagel in die Wand schlagen. Sprich: 
Ausprobieren ob es klappt. Oder die Implementierungsspezifischen 
Eigenschaften des Compilers studieren und es für das eigene System zum 
Laufen bringen ohne den Anspruch, dass alles so wunderbar kompatibel 
ist.

Eine Mathe-Lib oder ein Protokoll-Konverter sollte sich nicht auf ein 
Padding verlassen, geschenkt.

Aber die Vorstellung, dass jeder HW-Zugriff auch für 9Bit-Chars, beide 
Endians und Einer-Komplement funktionieren muss, ist weltfremd.

Die meisten Entwickler haben schon Probleme mit Format-Specifiern in 
einem konkreten System. Der "richtige" Weg für alle Int-Größen macht das 
nicht zuverlässiger sondern fragiler.