Struct Hilfe

Sorry,

sollte unsigned char sein

> Nun suche ich eine Möglichkeit, dem Compiler mitzuteilen, das mein
> Struct auch da reinpasst.

Das brauchst Du ihm nicht zu sagen, das weiss der auch so. Ich vermute 
Du suchst was anderes: Wenns standardwidrig sein darf man union, sonst 
man 3 memcpy.

Möchtest du die Daten über eine Kommunikations Schnittstelle abschicken 
oder abspeichern? Dann geht das nicht direkt, da C(++) das Layout von 
Bitfeldern nicht definiert. Unter Serialisierung ist das mit Lösung 
erläutert.

Kommunikations Schnittstelle ist korrekt. Es geht um SPI. Wie würde 
sowas denn mit dem Union aussehen?

Gruß Sascha

sascha_focus schrieb:
> Nun suche ich eine
> Möglichkeit, dem Compiler mitzuteilen, das mein Struct auch da
> reinpasst.

__attribute__((packed))

wär' zu erwähnen.

Die Union Lösung ist halt in C Implementation defined d.h. unportabel, 
und in C++ komplett verboten. Daher ist die 2. Lösung mit den 
Bit-Operationen deutlich besser. Da ist nur ein Tippfehler  - es sollte 
wohl "x" statt uint16_t heißen

g457 schrieb:
>> Nun suche ich eine Möglichkeit, dem Compiler mitzuteilen, das
> mein
>> Struct auch da reinpasst.
>
> Das brauchst Du ihm nicht zu sagen, das weiss der auch so. Ich vermute
> Du suchst was anderes: Wenns standardwidrig sein darf man union, sonst
> man 3 memcpy.

Union geht nicht. Wenn doch, dann zuvall

WENN es für eine konkrete Plattform ist,
UND du deinen Compiler kennst
UND konfigurierst
UND Du entsprechende asserts einbaust,
DANN kannst Du Unions verwenden.

Unions sind halt im Zugriff ausdrucksstärker als die portablen Aufsätze. 
Ja, in 10 Jahren wird man dir das vorwerfen, ... hättest Mal sofort 
richtig gemacht, .... Die Pharisäer, die alles richtig machen und bei 
deren Software keiner Änderung braucht.

Schwachsinn, nicht in 100 Jahren, sondern heute. Code sollte soweit wie 
möglich portablen gehalten werden. Für die Aufgabe gibt es einfache 
Alternativen. Warum dann so einen sch.. machen?

Mach es gleich richtig, kostet nichts und tut nicht weh. ?

Schon 100 mal schrieb:
> Code sollte soweit wie möglich portablen gehalten werden.

Portabler Code, ja. Bei HW- oder plattformspezifischem Code nein. Ein 
Registerlayout mit structs (statt diesem 1<<PIN1) ist besser les- und 
statisch analysierbar.


Schon 100 mal schrieb:
> Mach es gleich richtig, kostet nichts und tut nicht weh.
Dann zeig doch Mal eine Lösung, die nicht viel kostet und wartbar ist 
(wartbar im Sinne von an einer Stelle)

Oh, sorry, meinte eigentlich kann structs verwenden, aber das Fass ist 
ähnlich. Ob der TO Unions braucht, wissen wir ja nicht.

Achim S. schrieb:
> Dann zeig doch Mal eine Lösung, die nicht viel kostet und wartbar ist
> (wartbar im Sinne von an einer Stelle)

https://erlkoenig90.github.io/uSer-doc/html/tutorial.html#ConWidth

Die vorgeschlagene Union Variante ist natürlich Groten–schlecht. Auch 
wenn sie auf den ersten Blick funktioniert, hat es nichts - aber auch 
gar nichts - mit C Programmierung zu tun.
Es wäre nur eine zufällige, vom Compiler geduldete, Ausfuehrung.

S. R. schrieb:
> Hab ich doch schon gemacht, Fipptehler inklusive?

Ja, aber da muss ich zum enum noch 2 konvertierungsroutinen schreiben. 
Statt einmal den Compiler zu konfigurieren. Bei 5 structs vielleicht 
noch OK. Oder für einen Plattformunabhangigen Treiber.

> Oder wie würdest du das anderweitig machen?
Ja. Structs + asserts.

Zudem ist es überhaupt nicht klar, ob der TO die Struktur überhaupt zu 
anderen kommuniziert oder nur in einem seriellen eeprom speichert oder 
dessen Bits manipuliert.

Schon 100 mal schrieb:
> Es wäre nur eine zufällige, vom Compiler geduldete, Ausfuehrung

Naja, den Zufall kann man hier auch sicherstellen.

Die vorgeschlagenen Lösungen sind halt alle schwer wartbar, also write 
only. Für portable Treiber OK, z.b.ein TCP/IP Stack. Für Systeme, die 
sich laufend weiter entwickeln, sind die Kosten enorm und müssen mit 
einkalkuliert werden. Und allignment und endianess kommen ja nochmal 
oben drauf, und n Bits im Byte, ....