Ach, ein DSP. Bei denen ist es durchaus üblich, dass ein char größer
als 8 Bit ist. Aber auch wenn es nur 8 Bit groß wäre: Damit das
darauffolgende int n der Struktur nicht über eine 16-Bit-Wortgrenze
ragt, fügt der Compiler nach dem char ein (ungenutztes) Füllbyte in
ein, was die Struktur insgesamt vergrößert.
Wie Datentypen intern dargestellt werden, ist stark prozessor- und
compilerabhängig. In deinem Fall würde ich folgendermaßen vorgehen:
1 | struct daten_t {
|
2 | ...
|
3 | } daten;
|
4 |
|
5 | unsigned char *sptr;
|
6 | int i;
|
7 |
|
8 | // Struktur in EEPROM speichern
|
9 | sptr = (unsigned char *)&daten;
|
10 | for(i = 0; i < sizeof daten; i++) {
|
11 | write_eeprom(*sptr, i); // Datenbyte an Adresse i schreiben
|
12 | sptr++;
|
13 | }
|
Das sollte unabhängig von der internen Darstellung funktionieren.
Möchtest du die Anzahl der Füllbytes und damit den belegten
Speicherplatz im EEPROM minimieren, kannst du in der
Strukturdeklaration die einzelnen Elemente nach Typgröße in
absteigender Reihenfolge sortieren, also in der Reihenfolge double,
float, int, short und char. In deinem Fall:
1 | struct dummy {
|
2 | float something;
|
3 | int baa;
|
4 | unsigned char foo;
|
5 | char many[9];
|
6 | } head;
|
Nochmal zurück zu den DSPs: Ich hatte mal einen, da war
sizeof (double) == 1
Das hat mich zunächst arg gewundert, denn die berechneten Ergebnisse
waren etwa 7 Stellen genau =8-O, bis es mir dann wie Schuppen von den
Augen fiel (s. o.).