C - struct inklusive CRC - Padding-Bytes

[Simon G. (sigro)]

Guten Morgen,
wie würdet ihr folgendes Problem sauber in c lösen?
Ich habe eine Konfigurationsstruktur die im FLASH gespeichert werden 
soll; sowohl beim Programmieren als auch im Betrieb.
Ich möchte zur Sicherheit noch eine CRC hinzufügen.
Das Problem ist, dass die Berechnung der CRC ohne den Speicherbereich 
für die CRC durchführen will/muss.
Der erste Ansatz mit

typedef struct
{
  uint8_t param_1;
  uint16_t param_2;
  uint8_t param_3[9];
  uint16_t crc;
} conf_t
conf_t config;
get_default_config(&config);
uint8_t crc_size = sizeof(config) - sizeof(config.crc);
config.crc = calc_crc(&config, crc_size);

scheiterte, da auch am Ende Padding-Bytes eingefügt wurden.
Die zweite Lösung empfinde ich als unsauber, funktioniert aber erstmal.

uint8_t crc_size = (uint8_t)(&(config.crc)) - (uint8_t)&config;

aktuell habe ich die Idee, die Struktur so aufzubauen:

typedef struct
{
  uint8_t param_1;
  uint16_t param_2;
  uint8_t param_3[9];
} conf_t;
typedef struct
{
  config_t conf;
  uint16_t crc;
} conf_rcr_t;

Habt ihr eine bessere und vor allem sauberere Lösung?

Simon

[N. M. (mani)]

typedef struct
{
  uint8_t param_1;
  uint16_t param_2;
  uint8_t param_3[9];
  uint16_t crc;
} conf_t;

printf("%d\n", sizeof(conf_t)); //16

Etwas nachdenken beim anordnen der Parameter:

typedef struct
{
  uint16_t param_2;
  uint8_t param_3[9];
  uint8_t param_1;
  uint16_t crc;
} conf_t;

printf("%d\n", sizeof(conf_t)); //14

Alternativ:

typedef struct __attribute__((packed))
{
  uint8_t param_1;
  uint16_t param_2;
  uint8_t param_3[9];
  uint16_t crc;
} conf_t;
printf("%d\n", sizeof(conf_t)); //14

Simon G. schrieb:
> Das Problem ist, dass die Berechnung der CRC ohne den Speicherbereich
> für die CRC durchführen will/muss.

Wieso das? Rechne doch über die komplette struct (mit CRC) und 
vergleiche mit 0x0000/0xFFFF (je nach final)

Simon G. schrieb:
> aktuell habe ich die Idee, die Struktur so aufzubauen:

Und was macht das besser?

printf("%d\n", sizeof(conf_rcr_t)); //16

Dann kannst du auch gleich mit offsetof(CRC) arbeiten.

[Christopher B. (chrimbo)]

Simon G. schrieb:
> uint8_t crc_size = (uint8_t)(&(config.crc)) - (uint8_t)&config;

 uint8_t crc_size = offsetof(conf_t, crc);

Edit: da war mani schneller :-)

[Simon G. (sigro)]

N. M. schrieb:
> Etwas nachdenken beim anordnen der Parameter:
>

> typedef struct __attribute__((packed))
>

Moin und vielen Dank,
stimmt, packed wäre auch noch eine gute alternative.
> Wieso das? Rechne doch über die komplette struct (mit CRC) und
> vergleiche mit 0x0000/0xFFFF (je nach final)
Das verstehe ich leider noch nicht ganz. Ich möchte ja die gespeicherte 
Konfiguration mit der gespeicherten CRC überprüfen, um Fehler beim 
Speichern oder Lesen zu erkennen.

N. M. schrieb:
> Und was macht das besser?printf("%d\n", sizeof(conf_rcr_t)); //16
>
> Dann kannst du auch gleich mit offsetof(CRC) arbeiten.

Perfekt, das gefällt mir und war irgendwie nicht auf meinem Schirm.

[Simon G. (sigro)]

N. M. schrieb:
> Simon G. schrieb:
>> aktuell habe ich die Idee, die Struktur so aufzubauen:
>
> Und was macht das besser?

da hätte ich dann

conf_crc_t conf;
uint_t crc_size = sizeof(conf.conf);

genommen.

[N. M. (mani)]

Christopher B. schrieb:
> Edit: da war mani schneller :-)

Ja, ich hab noch editiert und offsetof hinzugefügt.

Simon G. schrieb:
> Das verstehe ich leider noch nicht ganz. Ich möchte ja die gespeicherte
> Konfiguration mit der gespeicherten CRC überprüfen, um Fehler beim
> Speichern oder Lesen zu erkennen.

Na du hast doch irgendwann Daten die du speichern möchtest. Zu den Daten 
berechnest du die CRC und speicherst diese konsistent mit den Daten im 
Flash.
Irgendwann liest du die Daten wieder aus und willst sie validieren. Wenn 
du nun über die komplette struct (mit CRC) die CRC rechnest muss doch 0 
rauskommen.

[N. M. (mani)]

Simon G. schrieb:
> da hätte ich dann
>
> conf_crc_t conf;
>
> uint_t crc_size = sizeof(conf.conf);
>
> genommen.

conf_t ist doch das Problem. Genauer gesagt weil du auf das erste 
uint8_t versuchst ein uin16_t zu platzieren. Aufgrund der ungeraden 
Adresse macht der Compiler das aber nicht und fügt ein padding Byte ein. 
Später beim Übergang vom Array auf uint16_t das gleiche nochmal.
Also musst du doch das Vermeiden.
Das bekommst du mit der gezeigten Variante ja aber nicht hin.
Also hast du wieder 2 Byte zu viel...

[Simon G. (sigro)]

N. M. schrieb:
> Also musst du doch das Vermeiden.
> Das bekommst du mit der gezeigten Variante ja aber nicht hin.
> Also hast du wieder 2 Byte zu viel...

Die Padding-Bytes sind nicht unbedingt das Problem, da sie ja bei der 
CRC Berechnung berücksichtigt werden.
Nur die Padding-Bytes am Ende der Struktur zusammen mit meiner 
fehlerhaften Berechnung des Offsets führten dazu, dass die CRC in die 
CRC Berechnung einfloss und damit eine andere CRC berechnet wurde als 
abgespeichert.

[Simon G. (sigro)]

N. M. schrieb:
> Christopher B. schrieb:
> Irgendwann liest du die Daten wieder aus und willst sie validieren. Wenn
> du nun über die komplette struct (mit CRC) die CRC rechnest muss doch 0
> rauskommen.
Wie ich das am Besten nutzen kann, muss ich mir noch überlegen.

[Bauform B. (bauformb)]

Kann man sich auf Padding-Bytes verlassen? Die Anzahl ist wohl immerhin 
implementation defined, aber der Inhalt könnte random sein. _

__attribute__((packed)) finde ich auch unsauber. Und ich fände es 
übersichtlicher, wenn crc ganz am Anfang stände.