Union Problem: Array mit einigen Variablen "überlagern"

PS: Man sollte speichern, dann kommen auch vom Compiler Warnungen und 
Errors beim compilieren.
Aber was will mir da jetzt

../main.c:23: error: 'union_t' undeclared (first use in this function)

sagen?

Dir fehlt ein typedef und die Syntax dafür.

Du willst einen eigenen Namen union_t für die Datenstruktur union {...} 
definieren und wie du das machst ist es falsch.

schreib doch ein union davor ( und ein = {0}) dahinter.

1

int main( void ){

2

   union union_t beides = {0};

3

   ...

4

}

Und das mit (beides.array[2]<<8) | beides.array[3] )hängt von der 
Endianess deines Systems ab.

Und dann sind da noch ein paar Kommas zuviel ( und ; zu wenig)

Woher weißt du das da zufällige Werte drin stehen? Wie gibst du das aus?

Mein C-Buch sagt mir das die einzelnen Variablen in der Struktur nicht 
mit einen Komma, sondern mit einen Punkt-Komma abgeschlossen werden

1

struct {

2

unsigned char BLA;

3

unsigned char BLUB;

4

}

Ansonsten bin ich mir gar nicht sicher ob das überhaupt geläufig ist. 
Ich habe schon Strukturen gesehen in denen es Unions gibt, aber eine 
Union mit einer Struktur habe ich bisher nocht nicht gesehen.

DirkB schrieb:
> Und dann sind da noch ein paar Kommas zuviel ( und ; zu wenig)

Hat mein Compiler auch bemängelt und ich habs still und heimlich 
verbessert... sorry

> Woher weißt du das da zufällige Werte drin stehen? Wie gibst du das aus?

AVR-Studio mit Simulator, der sich soeben verabschiedet hat. Error und 
AVR-Studio ist weg... grr



Nachtaktiver schrieb:
> Ansonsten bin ich mir gar nicht sicher ob das überhaupt geläufig ist.
> Ich habe schon Strukturen gesehen in denen es Unions gibt, aber eine
> Union mit einer Struktur habe ich bisher nocht nicht gesehen.

Naja ich bin blutiger Anfänger... Aber wie geht man das sonst an?
"Problem":
Ich möchte mit meinem AVR ein Datenpacket per UART empfangen und 
anschließend auswerten. An der UART-Schnittstelle kommt ein Byte nach 
dem Anderen rein, im Programm kann ich aber viel besser einzelne 
Variablen brauchen?!



Ich frage mich gerde ob ich für korrekte Funktion dem strukt einen namen 
geben muss?! also so:

1

typedef union {

2

    struct {

3

      uint16_t var1;

4

      uint16_t var2;

5

      uint8_t var3;

6

      uint8_t var4;

7

      uint8_t var5;

8

      uint8_t var6;

9

      uint8_t var7;

10

      uint8_t var8;

11

    } name;

12

    uint8_t array[10];

13

} union_t ;

Oder müsste das auch ohne gehen? wär mir lieber!

> Oder müsste das auch ohne gehen? wär mir lieber!

IMHO nur mit

Ohne Namen geht es auch.

Caste doch die Struktur auf ein *uint8_t;

Also

1

int DatenLesen(uint8_t *Daten);

2

3

...

4

5

DatenLesen((uint8_t *)&name);

Danke euch allen! Dieser Teil scheint zu funktionieren, mein Gesamtcode 
allerdings nicht.
Ich mach mich mal auf die suche nach dem richtigen Konzept, meins geht 
nicht auf...

DirkB schrieb:
> Caste doch die Struktur auf ein *uint8_t;
>
> Also
> int DatenLesen(uint8_t *Daten);
> ...
> DatenLesen((uint8_t *)&name);

Tut mir leid, dem kann ich nicht folgen. Auch nach einigem googeln 
nicht.
Wäre schön wenn du das nochmal genauer erläutern könntest.

Danke
Lg Michael

Syntax steht in jedem Buch,
aber was gerne vergessen wird:

Du must dem Compiler unbedingt sagen dass er Deine
Struktur "packen" soll !
(z.B. bei gcc -fpack-struct )

einige Compiler haben da ihre Eigenheiten beim alignment wenn 
unterschiedliche Datentypen in der Struktur drin sind

das big-endian/little-endian Problem wurde schon angesprochen

ansonsten viel Spass noch

Rolle schrieb:
> Du must dem Compiler unbedingt sagen dass er Deine
> Struktur "packen" soll !
> (z.B. bei gcc -fpack-struct )

Dann packt der aber alle Strukturen, was ziemlich suboptimal ist. Mit 
dem Attribut "packed" kann man das auch für einzelne structs einstellen.

Rolle schrieb:
> einige Compiler haben da ihre Eigenheiten beim alignment wenn
> unterschiedliche Datentypen in der Struktur drin sind

Normalerweise sind es weniger die eigenbrötlerischen Compiler sondern 
mehr die ABI-Standards der Prozessor-Architekturen die sie einhalten 
müssen um auch zu anderen Compilern kompatibel zu sein.

http://books.google.com/books?id=8XqqSxeih7UC&pg=PA193&lpg=PA193&dq=c%2B%2B+strukturen+packen&source=bl&ots=W-ba7nW-sZ&sig=ZMETjlch3HFLB6OGzF72jywmKlY&hl=de&ei=ImaPTeHWGo-Lswbe__mFCg&sa=X&oi=book_result&ct=result&resnum=2&ved=0CBwQ6AEwAQ#v=onepage&q=c%2B%2B%20strukturen%20packen&f=false

Also alles was ich über gepackte Stukturen so lese is im Prinzip das was 
in obigem Link steht (hoffentlich funktioniert er! ist aus dem Buch 
"Praktische C++-Programmierung" von Steve Oualline auf den Seiten 192 f 
)
Und da steht, dass durch das Packen die Bits quasi auf unterschiedliche 
Variablen verteilt werden können um Speicher zu sparen.
Aber was hat das mit meiner struct zu tun? warum soll ich die Packen?

Damit der C-Compiler nicht Lücken in die Struktur macht, um die Hände 
frei zu haben um z.B. effizienteren Zugriffscode zu erzeugen.

Ein C-Compiler darf zwischen die Elemente eines struct Füll-Bytes 
einfügen, um die Ausrichtung folgender Elemente zu steuern. Das struct 
aus der Frage könnte so mehr als 10 Bytes groß sein, je nach Architektur 
für die übersetzt wird. Das "packed"-Attribut des GCC verhindert das, 
jedes Element folgt dann direkt dem vorhergehenden.

>Also alles was ich über gepackte Stukturen so lese is im Prinzip das was
in obigem Link steht

>Und da steht, dass durch das Packen die Bits quasi auf unterschiedliche
Variablen verteilt werden können um Speicher zu sparen.

Situation:

1. Oben angegebener Link beschreibt einen Spezialfall, bei dem eine 
Variable deutlich weniger Information halten soll, als mit den 
Standardtypen gespeichert werden kann.

Schlussfolgerung:
1. Die Situation ist mit der des TO nicht unmittelbar vergleichbar.

Information:
1. Der Fall des TO passt auf das packen von Bytes/Words etc. also 
mehreren Bits zusammen.

Empfehlung:
1. Mehr als ein Buch zu dem Thema "structs packen" heranziehen.

http://sig9.com/articles/gcc-packed-structures
Dieser Fall ist wohl gemeint... Ok das ist natürlich ein Argument!
Danke!