struct größer als erwartet

[Robert Zelder (Gast)]

Hallo,

ich versuche die Konfigurationsparameter für einen externen Baustein, 
der über eine serielle Schnittstele an meinen Controller angeschlossen 
ist, in eine struct zu packen. Das mache ich, weil das Protokoll die 
Daten in einer bestimmten Reihenfolge verlangt. Vor der struct wird ein 
Header gesendet, dahinter eine Checksumme.

struct
{
  uint8_t  flags;
  uint32_t baudrate;
  uint8_t  mode;
} com_config_t;

Leider funktioniert das nicht. Komischerweise liefert 
sizeof(com_config_t) auch mehr als die erwarteten 6 Bytes zurück.

Was macht der Compiler da? Könnte das damit zusammenhängen, dass ich auf 
einem 32bit-System bin und er alles in 32 bit Schritten zusammenbaut?

Wenn ja, wie kriege ich dann meine struct implementiert, so dass ich sie 
direkt über die Schnittstelle senden kann?

Grüße und frohe Weihnachten,
der Rob

[Sebastian Hepp (Gast)]

Versuch es mit

struct xyz {

} __attribute__((packed));

[Roland H. (batchman)]

Robert Zelder schrieb:
> Was macht der Compiler da?

Er "alignt"

Robert Zelder schrieb:
> Wenn ja, wie kriege ich dann meine struct implementiert, so dass ich sie
> direkt über die Schnittstelle senden kann?

Du bist auf einem 32-Bitter mit vermutlich vielen MHz und Flash 
unterwegs. Unabhängig davon würde ich die Felder einzeln rausschreiben.

"packed" löst das Problem, aber wenn das mal aus Versehen gelöscht wird 
... anders formuliert hängt die logische Korrektheit Deiner Applikation 
von einer relativ technischen Einstellung ab, die man eher aus 
RAM-Mangel wählt.

Beim Portieren von 8-Bit-Code auf 32-Bit habe ich damit viel "Spass" 
gehabt.

[chinesenüberwacher (Gast)]

Robert Zelder schrieb:
> Was macht der Compiler da? Könnte das damit zusammenhängen, dass ich auf
> einem 32bit-System bin und er alles in 32 bit Schritten zusammenbaut?
Genau, Stichwort padding. Lösung steht oben.

[Rolf M. (rmagnus)]

Roland H. schrieb:
> "packed" löst das Problem, aber wenn das mal aus Versehen gelöscht wird
> ... anders formuliert hängt die logische Korrektheit Deiner Applikation
> von einer relativ technischen Einstellung ab, die man eher aus
> RAM-Mangel wählt.

Davon abgesehen gibt es durchaus Architekturen, die den Zugriff auf 
solche Strukturen gar nicht unterstützen. Andere können es, aber 
brauchen dann mehr Zeit für den Zugriff.

[Roland H. (batchman)]

Rolf Magnus schrieb:
> Davon abgesehen gibt es durchaus Architekturen, die den Zugriff auf
> solche Strukturen gar nicht unterstützen.

Welche Architekturen sind das?

[DirkB (Gast)]

Kannst du die Reihenfolge der Elemente ändern?
Dann mach erst die  uint32_t, dann die  uint8_t.
Dann brauchst du das packed nicht.

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

Rolf Magnus schrieb:

> Davon abgesehen gibt es durchaus Architekturen, die den Zugriff auf
> solche Strukturen gar nicht unterstützen. Andere können es, aber
> brauchen dann mehr Zeit für den Zugriff.

Das ist eher eine Frage des Compilers. Denn ein Compiler kann - wenn er 
will - auch bei Architekturen, die keinen unaligned access unterstützen, 
einen Code erzeugen, der mit gepackten Strukturen umgehen kann. Die 
Effizienz ist dabei natürlich nicht berauschend.

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

Roland H. schrieb:

> Welche Architekturen sind das?

Hardwareseitig können beispielsweise diverse ARMs keinen unaligned 
access, jedenfalls nicht so wie man ihn sich vorstellt. Das sind u.A. 
die klassischen ARM7/9 und Cortex M0. GCC unterstützt allerdings 
trotzdem gepackte Strukturen und wählte den erzeugten Code entsprechend 
des Zielsystems aus.

[Karl H. (kbuchegg)]

Gabs nicht auch bei den 68000 derartige Restriktionen? Ich meine mich zu 
erinnern, dass A0 da gar nicht am Adressbus verfügbar war.

[Simon K. (simon)]

"packed" ist keine Lösung.

Die Lösung ist es für Binäre Protokolle keine Structs zu verwenden, 
sondern alles per Hand zusammenzubauen. Das steht hier vielfach im Forum 
und wird durch Profis wie Karl-Heinz Buchegger (hoffe keinen Unsinn zu 
erzählen ;-)) u.Ä. auch so unterstützt.

Genau so bei Bitfelder im Ürbrigen. Die Anordnung der Bits ist von 
mehreren Parameter abhängig (Endianess z.B.).

[Karl H. (kbuchegg)]

Simon K. schrieb:
> "packed" ist keine Lösung.

Vor allen Dingen auch, weil das ja nicht das einzige Problem sein kann. 
Byte-Order bei mehrbytigen Dingen ist das andere.

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

Karl Heinz Buchegger schrieb:

> Gabs nicht auch bei den 68000 derartige Restriktionen? Ich meine mich zu
> erinnern, dass A0 da gar nicht am Adressbus verfügbar war.

Ob man die Leitungen für die Byteselektion nun LDS/UDS (68000) oder 
A0/HBE (8086) nennt ist dafür irrelevant. Krass war nur TI 9900, denn 
der hatte überhaupt keine, d.h. konnte nicht einmal byteweise schreiben, 
musst bei Byteoperationen vorher lesen.

Es ist aber richtig, dass 68000 Code und 16/32-Bit Daten an ungeraden 
Adressen nicht zuliess.