Hallo zusammen,
mit vielen Mühen habe ich mich mal an die structures und unions
rangemacht:
##############################################################
struct Telegram {
union {
struct //TelegrammBytes
{
uint8_t SYN;// = {0x16};
uint8_t STX;// = {0x02};
uint8_t LEN;// = {14};
union
{
struct //NutzBytes
{
uint8_t SRC;
uint8_t DST;
uint8_t Tid;
uint8_t Cmd;
uint8_t Data[5];
};
struct //Nutzstring
{
uint8_t Nstr[9];
};
};
uint16_t CRC;
}; //TB;
struct //TelegrammString
{
uint8_t str[15];
}; //TS
};
};
extern typedef struct Telegram TG[2],TXold,RXold; //Fall 1
//typedef extern struct Telegram TG[2],TXold,RXold; //Fall 2
//extern struct Telegram TG[2],TXold,RXold; //Fall 3
######################################################
Fehlermeldung Fall 1 und Fall 2:
D:\AVR(C90S)\Display3000\Training\TRG18\./Protocol.h:54: error: multiple
storage classes in declaration specifiers
Fall 3 funktioniert ! Ich stehe im Wald und weiß gar nichts mehr!
Folgendes hatte ich geglaubt zu verstehen:
1. Mit structures und unions erfolgt erst nur einmal die DEKLARATION der
Strukturen
2. Mit typedef wird auf die Struktur Speicherplatz zugewiesen, bzw.
Speicherplatz mit der Struktur reserviert
3. Mit extern teile ich dem Compiler mit, dass dieser Speicherplatz
'global' reserviert ist (d.h. auch für Programmteile ausserhalb der
Datei beschreibbar und lesbar ist)
4. Strukturen kann ich (solange sie gleich sind !!!) in jeder Datei per
Include File redefinieren (aus Schreibfaulheit) - lediglich bei der
Definition (Speicherplatzreservierung) muss ich aufpassen
Nach der obigen Fehlermeldung habe ich wohl was nicht verstanden - oder
?
Bitte um Hilfe - vielen Dank & Grüsse
Charly Grosse wrote: > Hallo zusammen, > > mit vielen Mühen habe ich mich mal an die structures und unions > rangemacht: [...] > extern typedef struct Telegram TG[2],TXold,RXold; //Fall 1 > //typedef extern struct Telegram TG[2],TXold,RXold; //Fall 2 > //extern struct Telegram TG[2],TXold,RXold; //Fall 3 > ###################################################### > Fehlermeldung Fall 1 und Fall 2: > D:\AVR(C90S)\Display3000\Training\TRG18\./Protocol.h:54: error: multiple > storage classes in declaration specifiers > > Fall 3 funktioniert ! Ich stehe im Wald und weiß gar nichts mehr! > > Folgendes hatte ich geglaubt zu verstehen: > > 1. Mit structures und unions erfolgt erst nur einmal die DEKLARATION der > Strukturen Richtig. > 2. Mit typedef wird auf die Struktur Speicherplatz zugewiesen, bzw. > Speicherplatz mit der Struktur reserviert Falsch. Mit typedef gibst du einem bestehenden Typ einen zusätzlichen Namen: typedef uint8_t mytype; definiert einen zusätzlichen Namen "mytype" für einen unsigned int. > 3. Mit extern teile ich dem Compiler mit, dass dieser Speicherplatz > 'global' reserviert ist (d.h. auch für Programmteile ausserhalb der > Datei beschreibbar und lesbar ist) Falsch. Der compiler "sieht" deinen Code Dateiweise. Hast du eine globale Variable "globalint" in main.c außerhalb von main() definiert und willst darauf in blablubb.c zugreifen wird dir der Compiler mächtig vor die Füße spucken, da er globalint in blablub.c nicht finden kann. Mit "extern int globalint" in der Datei blablubb.c sagst du dem Compiler: Hey Kamerad, da gibt es einen int namens globalint, der ist aber nicht hier sondern woanders definiert. > 4. Strukturen kann ich (solange sie gleich sind !!!) in jeder Datei per > Include File redefinieren (aus Schreibfaulheit) - lediglich bei der > Definition (Speicherplatzreservierung) muss ich aufpassen Das habe ich jetzt nicht verstanden. > Nach der obigen Fehlermeldung habe ich wohl was nicht verstanden - oder > ? > > Bitte um Hilfe - vielen Dank & Grüsse
> 1. Mit structures und unions erfolgt erst nur einmal die DEKLARATION > der Strukturen Meinst du die Typen oder deren Instanzen? Und meinst du wirklich die Deklaration oder doch eher die Definition? Die Definition einer globalen Variablen erfolgt nur einmal. Eine Deklaration ist dagegen in jeder Übersetzungseinheit, die die Variable verwendet, nötig. > 2. Mit typedef wird auf die Struktur Speicherplatz zugewiesen, bzw. > Speicherplatz mit der Struktur reserviert Nein. Mit typedef gibst du dem Strukturtypen einen alternativen Namen. Ein typedef kann man nicht extern machen. > 3. Mit extern teile ich dem Compiler mit, dass dieser Speicherplatz > 'global' reserviert ist (d.h. auch für Programmteile ausserhalb der > Datei beschreibbar und lesbar ist) Mit extern gibst du an, daß irgendwo anders eine globale Variable mit diesem Namen existiert. > 4. Strukturen kann ich (solange sie gleich sind !!!) in jeder Datei per > Include File redefinieren (aus Schreibfaulheit) Was meinst du hier mit "Strukturen"? Die Typen oder die Variablen? Wenn du die Typen meinst, so ist das korrekt. > - lediglich bei der Definition (Speicherplatzreservierung) muss ich > aufpassen Das gilt dann nur für die Variablen. Die dürfen wie gesagt nur einmal definiert werden. > Nach der obigen Fehlermeldung habe ich wohl was nicht verstanden - oder Es scheint, daß du noch etwas Probleme damit hast, Datentypen und deren Instanzen richtig auseinanderzuhalten. > ? Du plenkst
Charly Grosse wrote: > 1. Mit structures und unions erfolgt erst nur einmal die DEKLARATION der > Strukturen Jein. Es kann eine reine Deklaration sein, man kann aber auch gleich eine Variable entsprechenden Typs mit anlegen, je nach der genauen Schreibweise. struct name {...}; -> reine Struktur-Deklaration struct name {...} var; -> Struktur-Deklaration + Variablen-Definition > 2. Mit typedef wird auf die Struktur Speicherplatz zugewiesen, bzw. > Speicherplatz mit der Struktur reserviert Nein! typedef definiert nur einen neuen Typ, gibt der Sache also quasi nur einen neuen Namen. Nach einem "typedef struct Telegram TG_t;" sind folgende beide Zeilen äquivalent: struct Telegram TG[2]; TG_t TG[2]; Speicherplatz wird erst reserviert, wenn konkret eine Variable des entsprechenden Typs angelegt wird (was z.B. die beiden Zeilen machen). > 3. Mit extern teile ich dem Compiler mit, dass dieser Speicherplatz > 'global' reserviert ist (d.h. auch für Programmteile ausserhalb der > Datei beschreibbar und lesbar ist) Jein. Mit "extern" sagst du dem Compiler, dass die Variable nicht in diesem c-File neu angelegt werden soll, sondern dass sie irgendwo anders angelegt wurde. > 4. Strukturen kann ich (solange sie gleich sind !!!) in jeder Datei per > Include File redefinieren (aus Schreibfaulheit) - lediglich bei der > Definition (Speicherplatzreservierung) muss ich aufpassen Du kannst nicht nur, du musst sogar die Struktur-Deklaration überall dort einbinden, wo du mit der entsprechenden Struktur arbeiten willst. "redefinieren" ist allerdings eine etwas unglückliche Wortwahl dafür.
Frank Lorenzen wrote: > Charly Grosse wrote: >> Hallo zusammen, >> >> mit vielen Mühen habe ich mich mal an die structures und unions >> rangemacht: > [...] > >> 4. Strukturen kann ich (solange sie gleich sind !!!) in jeder Datei per >> Include File redefinieren (aus Schreibfaulheit) - lediglich bei der >> Definition (Speicherplatzreservierung) muss ich aufpassen > > Das habe ich jetzt nicht verstanden. > >> Nach der obigen Fehlermeldung habe ich wohl was nicht verstanden - oder >> ? >> >> Bitte um Hilfe - vielen Dank & Grüsse ... Soll heissen: Wenn ich die Deklaration in ein Include file.h packe und dieses Include File in alle anderen Source Files reinpacke (aufrufe), dann steht ja in jedem file.c diese Deklaration. In meinem Verständns würde es logischer sein, die Struktur einmal EXTERN vollständig zu deklarieren und der Compiler weiss nun, dass die Struktur an anderer Stelle deklariert wurde und schaut dort nach ...! Oder muss ich in jeder Datei die (aus anderen files.c bekannte Struktur wieder neu deklarieren (wenn in dieser Datei an irgeneiner Stelle die Datenstruktur für eine Speicheroperation gebraucht wird)? Würde heissen: vor einer Struturdeklaration steht also nie das wort EXTERN !? Das wäre dann auch noch ein Irrtum meinerseits! Grüsse
Toooolllll - vielen dank erst einmal. Da fallen ja ganz viele Dominosteine -jetzt wird mir einiges klarer. >Falsch. Mit typedef gibst du einem bestehenden Typ einen zusätzlichen >Namen: typedef uint8_t mytype; definiert einen zusätzlichen Namen >"mytype" für einen unsigned int. Aha! Ich dachte das macht man mit dem PreProcessor Befehl #define uint8_t mytype Ist beides vollkommen synonym (in den Auswirkungen!) ? Also verbessere ich mit typedef letzendlich nur die Lesbarkeit meines Programmes ???
> In meinem Verständns > würde es logischer sein, die Struktur einmal EXTERN vollständig > zu deklarieren und der Compiler weiss nun, dass die Struktur > an anderer Stelle deklariert wurde und schaut dort nach ...! Ich denke, du musst dir noch über zwei Dinge klar werden: 1) Der Compiler übersetzt jede c-Datei für sich alleine, ohne in irgendwelche anderen c-Dateien zu schauen. Daher muss in jeder c-Datei, in der du irgendwie mit der Struktur arbeiten willst, die vollständige Deklaration enthalten sein (im Normalfall halt per include einer h-Datei). 2) "extern" sagt dem Compiler, dass eine Variable irgendwo anders definiert wurde. > Aha! Ich dachte das macht man mit dem PreProcessor Befehl > #define uint8_t mytype Wenn schon, dann umgekehrt: #define mytype uint8_t > Ist beides vollkommen synonym (in den Auswirkungen!) ? Nicht ganz. #define ist eine reine Textersetzung. Und ob du (fast) überall im Sourcecode "mytype" durch "uint8_t" ersetzt haben willst, ist halt die Frage.
.... > Du kannst nicht nur, du musst sogar die Struktur-Deklaration überall > dort einbinden, wo du mit der entsprechenden Struktur arbeiten willst. > "redefinieren" ist allerdings eine etwas unglückliche Wortwahl dafür. Okay - das macht dann (jetzt) Sinn für mich - bedeutet also, extern in Verbindung mit structure ist völlig unsinnig !? Noch 'ne Frage zu: //extern struct Telegram TG[2],TXold,RXold; //Fall 3 Eigentlich müsste (nach der vorhergehenden structure Deklaration) das "struct" überflüssig sein: //extern Telegram TG[2],TXold,RXold; //Fall 3 - müsste also auch so funzen Schliesslich ist 'Telegram' ja in der structure Deklaration ja als solche schon bekant gemacht worden - oder ?
Charly Grosse wrote: > //extern Telegram TG[2],TXold,RXold; //Fall 3 - müsste also auch > so funzen > Schliesslich ist 'Telegram' ja in der structure Deklaration ja als > solche schon bekant gemacht worden - oder ? Nein (jedenfalls für C, in C++ geht das). Du kannst es dir aber etwas einfacher machen, indem du Struktur-Deklaration und typedef kombinierst: typedef struct { ... } Telegram; Danach kannst du dann direkt "Telegram" verwenden.
> Okay - das macht dann (jetzt) Sinn für mich - bedeutet also, extern in > Verbindung mit structure ist völlig unsinnig !? Jein. Lese dazu meinen Text weiter oben: > Es kann eine reine Deklaration sein, man kann aber auch gleich eine > Variable entsprechenden Typs mit anlegen, je nach der genauen > Schreibweise. > struct name {...}; -> reine Struktur-Deklaration > struct name {...} var; -> Struktur-Deklaration + Variablen-Definition Unsinnig in Verbindung mit Variante 1: Ja. Unsinnig in Verbindung mit Variante 2: Nein. Außerdem denke ich, dass du extern noch nicht wirklich verstanden hast. Ich denke, du glaubst extern sagt dem Compiler folgendes: "Sorge bitte dafür, dass man auf diese Variable auch in anderen c-Dateien zugreifen kann". Das ist falsch. Es sagt dem Compiler folgendes: "Diese Variable wird irgendwo anders definiert (Speicher für reserviert), also lege diese Variable hier nicht neu an, sondern verwende die "andere" (also die "externe") Variable."
Stefan Ernst wrote: >> Okay - das macht dann (jetzt) Sinn für mich - bedeutet also, extern in >> Verbindung mit structure ist völlig unsinnig !? > > Jein. Lese dazu meinen Text weiter oben: >> Es kann eine reine Deklaration sein, man kann aber auch gleich eine >> Variable entsprechenden Typs mit anlegen, je nach der genauen >> Schreibweise. >> struct name {...}; -> reine Struktur-Deklaration >> struct name {...} var; -> Struktur-Deklaration + Variablen-Definition > > Unsinnig in Verbindung mit Variante 1: Ja. > Unsinnig in Verbindung mit Variante 2: Nein. > Habe ich jetzt verstanden! > Außerdem denke ich, dass du extern noch nicht wirklich verstanden hast. > Ich denke, du glaubst extern sagt dem Compiler folgendes: > "Sorge bitte dafür, dass man auf diese Variable auch in anderen > c-Dateien zugreifen kann". > Das ist falsch. Es sagt dem Compiler folgendes: > "Diese Variable wird irgendwo anders definiert (Speicher für > reserviert), also lege diese Variable hier nicht neu an, sondern > verwende die "andere" (also die "externe") Variable." ??? ... verwende die "andere" ... Variable ... und damit deren Speicherbereich - oder ? Exakt so habe ich es gemeint - leider nicht gesagt.
Stefan Ernst wrote: >> In meinem Verständns ... > Nicht ganz. #define ist eine reine Textersetzung. Und ob du (fast) > überall im Sourcecode "mytype" durch "uint8_t" ersetzt haben willst, ist > halt die Frage. Textersetzung ? Würde bedeuten, nach der Präprozessordirektive ist mytype nicht mehr in dem Code' vorhanden, der vom Compiler nachfolgend geparst wird ?
> ??? ... verwende die "andere" ... Variable ... und damit deren > Speicherbereich - oder ? Ja. > Exakt so habe ich es gemeint - leider nicht gesagt. Sorry, dann hatte ich einen falschen Eindruck. ;-) > Textersetzung ? Würde bedeuten, nach der Präprozessordirektive ist > mytype nicht mehr in dem Code' vorhanden, der vom Compiler nachfolgend > geparst wird ? Genau, außer in String-Literalen.
So - mit obigen Deklarationen und Definitionen mache ich nun folgendes:
TG[0].SYN = ASYN;
TG[0].STX = ASTX;
TG[0].Len = TLEN;
TG[0].SRC = 1;
TG[0].DST = 2;
TG[0].Tid = Hundertstel;
TG[0].Cmd = 128;
TG[0].rx = Rx;
TG[0].ry = Ry;
for (i=0; i < TLEN; i++)
{
TG[0].CRC = _crc_xmodem_update (TG[0].CRC, TG[0].str[i]);
}
TG[0].str[TLEN] = '\0';
uart1_puts(TG[0].str[0]); // <-
Und hier warnt mich der Compiler:
../TxRailMsg.c:83: warning: pointer targets in passing argument 1 of
'uart1_puts' differ in signedness
Hingegen hat das immer einwandfrei (ohne warning und auch runtime)
tadellos gefunzt ...:
char TXNutzdaten[41];
...
uart1_puts(TXNutzdaten);
Diese blöden Pointer (so gut und genial ich sie finde) regen mich in der
Notation aber riesig auf. Wie heisst es denn nun richtig ? Muss ich
zuvor einen Pointer definieren und auf den Speicherbereich
initialisieren ?
extern struct Telegram *ptrstr;
...
ptstr = TG[0].str[0]
und dann
uart1_puts(ptstr);
oder was ???
Charly Grosse wrote: > uart1_puts(TG[0].str[0]); // <- > > Hingegen hat das immer einwandfrei (ohne warning und auch runtime) > tadellos gefunzt ...: > > char TXNutzdaten[41]; > ... > uart1_puts(TXNutzdaten); Das ist doch kein adäquater Vergleich. Oben übergibst du einen einzelnen uint8_t, und hier einen Pointer auf char. > Diese blöden Pointer (so gut und genial ich sie finde) regen mich in der > Notation aber riesig auf. Wie heisst es denn nun richtig ? Muss ich > zuvor einen Pointer definieren und auf den Speicherbereich > initialisieren ? > > extern struct Telegram *ptrstr; > ... > ptstr = TG[0].str[0] > > und dann > > uart1_puts(ptstr); > > oder was ??? Nein, du müsstest nur "TG[0].str" benutzen, aber auch das wird eine Warnung liefern, denn ein Pointer auf char ist nicht gleich einem Pointer auf uint8_t. Siehe dazu auch hier: Beitrag "GCC: Compiler-Fehlermeldung bei Übergabe an Pointer"
Stefan Ernst wrote: > Charly Grosse wrote: > >> uart1_puts(TG[0].str[0]); // <- >> >> Hingegen hat das immer einwandfrei (ohne warning und auch runtime) >> tadellos gefunzt ...: >> >> char TXNutzdaten[41]; >> ... >> uart1_puts(TXNutzdaten); > > Das ist doch kein adäquater Vergleich. Oben übergibst du einen einzelnen > uint8_t, und hier einen Pointer auf char. > Nee - jetzt stehe ich aber gleich wieder im Wald. In meinem Verständnis nicht: Ich übergebe die Adresse auf ein Array, und zwar auf das erste Element im Array. Das ist in der Notation meinetwegen synonym mit Tg[0].str . (Aber auch hier meckert der Compiler). Die UART Routine arbeitet doch solange das Array ab, bis sie das '\0' Zeichen findet ! Oder ?? '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' By the way - mittlerweile habe ich noch ein anderes Problem: Ich möchte einen CRC-Wert (im Telegramm) mit übergeben (als int16). Was passiert denn, wenn der CRC Wert Null ist ? Dann wird doch dieser Wert im Array von der UART Routine als das '\0' zeichen interpretiert und bricht ab - oder etwa nicht ?
Charly Grosse wrote: > Nee - jetzt stehe ich aber gleich wieder im Wald. In meinem Verständnis > nicht: Ich übergebe die Adresse auf ein Array, und zwar auf das erste > Element im Array. Das ist in der Notation meinetwegen synonym mit > Tg[0].str . (Aber auch hier meckert der Compiler). "TG[0].str[0]" ist das erste Element, nicht ein Pointer darauf, das wäre "&TG[0].str[0]". Oder nimm halt TG[0].str als Pointer auf das Array, was praktisch das selbe ist. Dass der Compiler meckern würde, habe ich ja gesagt (hast du den anderen Thread nicht gelesen?). > Die UART Routine arbeitet doch solange das Array ab, bis sie das '\0' > Zeichen findet ! > > Oder ?? Wenn sie so programmiert ist, ja. > Ich möchte einen CRC-Wert (im Telegramm) mit übergeben (als int16). > Was passiert denn, wenn der CRC Wert Null ist ? Dann wird doch dieser > Wert im Array von der UART Routine als das '\0' zeichen interpretiert > und bricht ab - oder etwa nicht ? Dieses Problem hast du sowieso, schließlich enthält die ganze Struktur ja nicht wirklich Text, sondern Daten. Oder ist sichergestellt, dass nichts davon Null sein kann?
Stefan Ernst wrote: > Charly Grosse wrote: > >> Nee - jetzt stehe ich aber gleich wieder im Wald. In meinem Verständnis >> nicht: Ich übergebe die Adresse auf ein Array, und zwar auf das erste >> Element im Array. Das ist in der Notation meinetwegen synonym mit >> Tg[0].str . (Aber auch hier meckert der Compiler). > > "TG[0].str[0]" ist das erste Element, nicht ein Pointer darauf, das > wäre "&TG[0].str[0]". Oder nimm halt TG[0].str als Pointer auf das > Array, was praktisch das selbe ist. Dass der Compiler meckern würde, > habe ich ja gesagt (hast du den anderen Thread nicht gelesen?). > >> Die UART Routine arbeitet doch solange das Array ab, bis sie das '\0' >> Zeichen findet ! >> >> Oder ?? > > Wenn sie so programmiert ist, ja. > >> Ich möchte einen CRC-Wert (im Telegramm) mit übergeben (als int16). >> Was passiert denn, wenn der CRC Wert Null ist ? Dann wird doch dieser >> Wert im Array von der UART Routine als das '\0' zeichen interpretiert >> und bricht ab - oder etwa nicht ? > > Dieses Problem hast du sowieso, schließlich enthält die ganze Struktur > ja nicht wirklich Text, sondern Daten. Oder ist sichergestellt, dass > nichts davon Null sein kann? Jetzt ja ...!!!! Da denkt man vorher nicht dran, fällt einem erst auf, wenn das Telegramm nur 6 anstelle 14 Zeichen Länge hat. Stefan, Frank - toll, dass Ihr so intensiv geholfen habt - vielen vielen Dank. Ich bin Autodidakt und kann es mir nicht leisten, ein 500- Seiten Manual erst 3 Mal zu lesen und dann zu starten. Learning by Doing! Aber mit Euren Antworten habe ich einiges wegräumen können, was in dieser Feinheit aus den Tutorials nur schwer zu filtern ist - oder man muss zu jedem Kapitel (der Vorlesung) die entsprechenden Übungen extra machen - wie an der Uni - und das nimmt schon Monate in Anspruch. Wenn man (wie ich) direkt mit Interrupts, asynchronen Uarts, Timern, Watchdogs, der graphischen Darstellung, der Cursorsteuerung und den ganzen anderen Quatsch gleichzeitig zu tun hat, damit im Hobbyprojekt ( Eisenbahnsteuerung über Funk - jede Lok einen Mega128) es auch weitergeht, dann geht's nur so, sonst habe ich in den nächsten 12 Monaten für das Projekt nix getan. Und ich hab ja auch noch einen Job ...! Jetzt steht sogar schon meine Kommunikation und die Lok lässt sich über das DISPLAY3000 aus einem 2 D-Blockschaltbild vom Handheld (über Cursorsteuerung) als auch vom PC (mit de Maus) parallel steuern. Damit ist der Proof of Concept erbracht. Jetzt geht es an das bidirektionale Protokoll (Channel Access und Congestion Control), damit man mit mehreren Steuerungen 20 Loks gleichzeitig fahren lassen kann, Weichen, Signale schalten und und und. Und dann geht's an den Comfort und die Feinheiten: Z.B. Zwei und mehr gekoppelte Loks in einen logischen Master-Slave Verbund koppeln und die Lastverteilung automatisch regeln lassen (über die Messung des Stroms / des Spannungsabfalls) ... Ihr seid super ! Grüsse Aus den gesamten Antworten
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.