Einzelne Bytes in Struktur aufrufen

[Dennik (Gast)]

Hallo,

in einer (beliebigen) Struktur möchte ich alle Bytes nacheinander 
aufrufen, um sie in einem EEPROM zu speichern. Mir ist es dabei 
vollkommen egal, wie die einzelnen Elemente angeordnet sind, ich möchte 
einfach nur das komplette Gebilde Byte für Byte im EEPROM speichern.

Wie kann ich in der Struktur die einzelnen Bytes (0...n, n ist bekannt) 
aufrufen?

Danke für alle Antworten, mit vielen Grüßen Dennik

[... (Gast)]

Z.B. indem Du die Struktur (genauer deren Addresse) auf uint8_t* 
castest.
Oder eine Union mit einem passenden Array drumrumbastelst.
Oder gleich die richtige Funktion zum schreiben in den EEPROM benutzt.

[klaus (Gast)]

Dennik schrieb:
> Mir ist es dabei
> vollkommen egal, wie die einzelnen Elemente angeordnet sind, ich möchte
> einfach nur das komplette Gebilde Byte für Byte im EEPROM speichern.

Byte-weiser Zugriff wäre in etwa so möglich:

struct EGAL
{
  int x;
  int y;
};
// ...

struct EGAL s;

char* ptr = (char*)&s;

int i;
for (i = 0; i < sizeof(struct EGAL); ++i)
{
  // print each byte
  printf("%d,", ptr[i]);
}

[Frank B. (f-baer)]

Wenn du die Struktur in einer union mit einer Variable passender Größe 
zusammenfasst, dann kannst du über die Einzelvariable die komplette 
Struktur auslesen. Nur das Rückschreiben ist etwas komplizierter, weil 
du dann wieder die Einzelgrößen schreiben musst.

Beispiel:

union DEINE_UNION{
  struct DEIN_STRUCT{
    u8 deine_variable1;
    u8 deine_variable2;
  };
  u16 deine_zusammenfassung;
};

[peterguy (Gast)]

Wenn ich dein Problem richtig verstanden habe, dann heisst die Lösung 
deines Problems "union".

Da sieht dann so ungefähr aus:

union{
 byte[LEN_STRUCT] rawData;
 struct {
   // hier kommen deine Structfelder rein >
   int mySignal;
 } Data;
} myUnion;

Kannst dann über myUnion.rawData[x] auf die Rohdaten zugreifen, und über 
myUnion.Data.mySignal auf einzelne Nutzdaten.

Hoffe das in obigem Code kein Fehler drinnen ist, habe die Syntax nicht 
überprüft.

Oder halt auf einen byte pointer casten, aber das finde ich persöhnlich 
nicht so sauber.

[Rufus Τ. F. (rufus)]

Die Union-Variante setzt voraus, daß der byte-Array-Teil größer sein 
muss als der struct-Teil. Das aber ist nicht garantiert, und so ist das 
eine schöne potentielle Fehlerquelle.

Sofern das Ergebnis des byteweisen Zugriffs nicht auf einer komplett 
anderen Hardwarearchitektur wiederum in einer Struktur genutzt werden 
soll, ist am typecast nichts "unsauber".

[Karl H. (kbuchegg)]

peterguy schrieb:

> Oder halt auf einen byte pointer casten, aber das finde ich persöhnlich
> nicht so sauber.


Egal wie du es machst, diese Operation wird niemals 'sauber' sein. Denn 
streng genommen ist auch die Union Variante nicht vom C-Standard 
gedeckt.
Genausogut könnte ich argumentieren, dass das umcasten des Pointers auf 
einen anderen Typ die etwas ehrlichere Variante ist, weil die Absicht 
dahinter klarer ist, als das verschleierte einschreiben in eine Union 
und auslesen über einen anderen Union-Member (und genau das ist dann 
auch der Punkt, an dem der Standard keine Zusicherung mehr macht: 
offiziell darf man eine Union nur über den Member auslesen über den die 
Daten auch in die Union gekommen sind)

Diese Lösung mit union

union{
 byte[LEN_STRUCT] rawData;
 struct {
   // hier kommen deine Structfelder rein >
   int mySignal;
 } Data;
} myUnion;

ist allerdings ganz schlecht, weil sie den Programmierer dazu zwingt die 
Strukturgröße zu kennen. Bei solchen Sachen IMMER eine Lösung suchen, 
die das Abzählen von irgendwelchen Größen dem Compiler aufbürdet. 
Sprich: sizeof benutzen!

[Frank B. (f-baer)]

Rufus Τ. Firefly schrieb:
> Die Union-Variante setzt voraus, daß der byte-Array-Teil größer sein
> muss als der struct-Teil. Das aber ist nicht garantiert, und so ist das
> eine schöne potentielle Fehlerquelle.

Mit __attribute__((_packed_)) stellt das kein Problem dar.

[Dennik (Gast)]

Vielen Dank für die schnellen Antworten.
Den Vorschlag vom klaus habe ich implementiert. Zumindest ist der 
Compiler schon mal damit zufrieden. Wenn ich morgen auch noch die 
EEPROM-Leseroutine fertig habe, werde ich testen können, ob es 
funktioniert.

Mit vielen Grüßen und nochmals Danke, Dennik

[Frank B. (f-baer)]

Das hier
>

> union{
>  byte[LEN_STRUCT] rawData;
>  struct {
>    // hier kommen deine Structfelder rein >
>    int mySignal;
>  } Data;
> } myUnion;
>

ist übrigens noch aus einem ganz anderen Grund schlecht. Die union kann 
so nur über rawData initialisiert werden, direkt in mySignal zu 
schreiben, funktioniert nicht.

[klaus (Gast)]

Rufus Τ. Firefly schrieb:
> Die Union-Variante setzt voraus, daß der byte-Array-Teil größer sein
> muss als der struct-Teil. Das aber ist nicht garantiert, und so ist das
> eine schöne potentielle Fehlerquelle.

struct DATA
{
  u8 x;
  u8 y;
};

#define LEN sizeof(struct DATA)

union DATA_ACCESS
{
  struct DATA data;
  u8 access[LEN];
};

Die union kann je nach Alignment Platz verschwenden, aber das "access" 
Array ist nie zu klein.

[Karl H. (kbuchegg)]

Dennik schrieb:
> Vielen Dank für die schnellen Antworten.
> Den Vorschlag vom klaus habe ich implementiert. Zumindest ist der
> Compiler schon mal damit zufrieden. Wenn ich morgen auch noch die
> EEPROM-Leseroutine fertig habe, werde ich testen können, ob es
> funktioniert.

?
Du brauchst 24 stunden um die Aufrufe so zu schreiben

   eeprom_read_block( (uint8_t*)&myStructVariable,
                      (uint8_t*)&eemyStructVariable,
                      sizeof( *myStructVariable ) );

bzw.

   eeprom_write_block( (uint8_t*)&myStructVariable,
                       (uint8_t*)&eemyStructVariable,
                       sizeof( *myStructVariable ) );

für die Variablen

struct irgendwas {
  ...
};

struct irgendwas eemyStructVariable EEMEM;
struct irgendwas myStructVariable;

[Dennik (Gast)]

> ?
> Du brauchst 24 stunden um die Aufrufe so zu schreiben

Nein - es wird in 24 Stunden fertig sein.

Die Daten werden übrigens dreifach im EEPROM abgelegt und sowohl nach 
dem schreiben, als auch beim Lesen miteinander verglichen. Weiterhin 
wird das interne Prozessabbild des verwendeten µCs zyklisch mit den 
gespeicherten EEPROM-Daten aktualisiert. - Incl. Test dauert das einfach 
etwas.

Mit freundlichen Grüßen, Dennik

[Dennik (Gast)]

Die ersten Test's des Programms sind positiv verlaufen. Die von klaus 
vorgeschlagene Lösung scheint gut zu funktionieren.

Nochmals herzlichen Dank (an alle), Dennik