Hi! Ich habe eine Funktionsroutine geschrieben, die ich zukünfig in versch. "Projekten" wieder benötigen werde. Um nun nicht immer den Code kopieren zu müssen und das ganze etwas eleganter zu machen, will ich die Funktion als 2. C-File einbinden. Da die Funktion später mittels 10ms-Interrupt vom Targetfile aus aufgerufen wird und durch die Funktion 2 globale Chars geändert werden, hatte ich die Variablen als "volatile unsigned char x,y;" definiert. Nun habe ich meine Funktion in ein 2. C-File ausgelagert und kann vom Targetfile aus die Variablen nicht mehr sehen... :-( WinAVR bringt auch keinen Fehler.. Das ganze hört sich jetzt etwas durcheinander an.. Sorry... :o) Aber ich hoffe ich könnt mir folgen, was ich meine... WIE muß ich nun WO die Variablen definieren, dass ich Sie ÜBERALL und JEDERZEIT bearbeiten kann? :-) Schonmal im Vorraus danke für jeden Tipp!
Verstehe ich auch nicht richtig. Du kannst sie nicht sehen, aber WinAVR bringt kein Fehler? Schreib sonst mal in die Datei, in der Du die Variablen nicht sehen kannst, "extern variablenTyp variablenName;" oben hin. Oder erkläre das Problem besser, vielleicht mit einem Beispiel.
Hi das Zauberwort heißt extern. Du mußt deine globalen Variablen in einem C-File definieren und in einem globalen Headerfile mittels extern bekannt machen. Matthias
Hallo! Danke für eure Tipps! :-) Hab das Problem gelöst! War aber ganz was anderes! Hab mit #ifndef in der Serviceroutine abgefragt, ob die Variablen schon initialisiert wurden. Da die darauffolgende #define nur bis zum Dateiende gilt wurde jedesmal, wenn die Routine aufgerufen wurde, die Variabeln neu initialisiert! ;) Trotzdem danke!
??? Präprozessor-Anweisungen (#ifndef, #define, ...) werden aber während des compilierens ausgewertet, und nicht während der Laufzeit...
Das weiß ich auch! :-) Aber irgendwie wollte WinAVR den Code nicht!?!? Er lautete so: void MATRIX (void) { #ifndef INIT_MATRIX #define INIT_MATRIX COUNT_MATRIX = 0xAA; SELECT_MATRIX = 0x00; #endif ..Weiterer_Code.. } Laut dem Buch "C für Microcontroller" gilt die #define-Anweisung nur bis zum Dateiende. Daher nehme ich mal an, dass hier "der Hund begraben liegt" ;-) Jedenfalls hab ich jetzt für die Initialisierung eine eigene Funktion erstellt, die ich hald beim Programmstart einmal aufrufe und nun funktionierts! Hab zum Debugging den Wert von COUNT_MATRIX auf die LEDs ausgegeben und dabei festgestellt, dass sich der Wert nie geändert hat.. :-/ Ist trotzdem komisch.. 8-)
> Laut dem Buch "C für Microcontroller" gilt die #define-Anweisung nur > bis zum Dateiende. Daher nehme ich mal an, dass hier "der Hund > begraben liegt" ;-) Das ist Mumpitz, denn dann dürfte ja kein Include mehr funktionieren. Ein #define gilt immer bis zum Ende des zu compilierenden Objects, wenn es nicht vorher aufgehoben wurde (#undef). Es lebt also immer über das Ende einer Include-Datei hinaus. Und globale Variablen kannst Du natürlich initialisieren, eine extra Funktion dazu ist nur Codeverschwendung. Du darfst es eben nur in einem Object tun ! Nimm mal die anderen Tips ernst und schau Dir das Schlüsselwort "extern" genauer an. Oder schaue einfach mal in andere h-Files. Es wurde ja schon an anderer Stelle bemängelt, daß der GCC durch Tolerieren des fehlenden "extern" mehr Verwirrung stiftet, als nützt. Peter
Also bitte ! Präprozessor-Direktiven leben definitiv nur bis zum Dateiende ! "#define" und Konsorten gehören dazu. Jetzt zum Einbinden von Headern : Diese besitzen meist das folgende Konstrukt um ihren Rumpf: #ifndef HEADER_H #define HEADER_H HEADER_H ... #endif Das dient dazu, Fehler zu vermeiden, wenn mehrere Header zu einer Implementierungsdatei hinzugefügt werden. Dann kann es nämlich passieren, dass Header-Datei 1 und Header-Datei 2 beide die Header-Datei 3 "#include"en. Sichert man sich nicht ab, so führt dies zu einem Fehler, wenn Header 1 und Header 2 zu einer Implementierungsdatei hinzugefügt werden. Die Lebenszeit der Konstanten HEADER_H aus obigem Beispiel geht genau bis zum Dateiende (JETZT kommt's !) der Datei, in die der Header eingebunden wird. Dieses Verhalten ist sher wichtig, wenn ein Projekt nämlich mehrere Implementierungsdateien enthält, soll ein Header, der beim Kompilieren dieser jeweils eingebunden wird auch jedes mal eingebdunden werden ! Wenn das noch nicht klar ist, dann kann ich noch ein Bildchen malen. Ich möchte Peter nicht komplett widersprechen - einem Anfänger, der z.B. extern nicht kennt, ist aber unter Umständen der Begriff "zu kompilierendes Object" nicht unbedingt klar und schon garnicht abgegrenzt. MfG, Daniel.
> Die Lebenszeit der Konstanten HEADER_H aus obigem Beispiel geht genau > bis zum Dateiende (JETZT kommt's !) der Datei, in die der Header > eingebunden wird. Ebern nicht ! Wenn diese Datei wieder irgendwo includiert wird, dann ist sie auch in dieser Datei gültig. Die Gültigkeit kann sich also über beliebig viele Includes erstrecken, völlig unabhängig von deren Ende. Sie besteht also bis zum Ende des zu compilierenden Objects. Dieses ist natürlich in der Regel identisch mit dem Ende derjenigen Datei, die dem Compiler als Source angegeben wird. Es ist also das Ende nur einer ganz bestimmten Datei und nicht das Ende von Dateien allgemein. Ich denke, man sollte schon sprachlich präzise sein. Peter
Hallo Peter, ich denke, ich weiß genau was Du meinst - wir scheinen eh aneinander vorbei. Weder Du (so meine ich) noch ich (da bin ich mir sicher) müssen was die Konstantendefinition angeht noch etwas lernen - das habe wir schon drauf. Meine Absicht war es die Sache zu erläutern - sprachliche Spitzen sind mir egal. MfG, Daniel. P.S.: Wenn sich noch jemand zu Thema Präprozessordirektiven unterhalten mag, dann schlage ich im Sinne der Verbunheit mit dem eigentlichen Thema einen neuen Thread vor.
Korrekturen : " wir scheinen aneinander vorbei zu reden" ;-) Übrigens : Ich habe recht, wenn man's genau überdenkt - Du auch, wenn man's ebenfalls überdenkt. MfG, Daniel.
> Laut dem Buch "C für Microcontroller" gilt die #define-Anweisung > nur bis zum Dateiende. Das ist natürlich in der Tat quatsch. Pre-Prozessor-Anweisungen gelten für die Übersetzungseinheit, nicht für einzelne Dateien. > Daher nehme ich mal an, dass hier "der Hund begraben liegt" ;-) In der Tat. Allerdings beim Buch. Leider keine Ausnahme. Scheint ein typisch deutsches Problem zu sein, dass jeder Huge-Dubel meint über ein Thema schreiben zu müssen, obwohl er keinen Plan davon hat. Also, ab in die Tonne damit.
Ihr benutzt nur unterschiedliche Terminologien ("die Datei" vs. "das
zu compilierende Objekt") für das, was offiziell Übersetzungseinheit
(translation unit) heißt. Ansonsten meint ihr das gleiche.
> Scheint ein typisch deutsches Problem zu sein, dass jeder
> Huge-Dubel meint über ein Thema schreiben zu müssen, obwohl er
> keinen Plan davon hat
Ob's daran liegt, weiß ich nicht. Ich habe jedenfalls schon lange kein
deutschsprachiges Programmierbuch mehr gekauft.
@Rolf Magnus: > Ich habe jedenfalls schon lange kein > deutschsprachiges Programmierbuch mehr gekauft. Da hast Du nix verpasst. Was an deutscher "Fach"literatur erhältlich ist, ist ein Trauerspiel (bis auf sehr wenige Ausnahmen einiger handvoll Autoren). Entweder sind die Bücher auf unterstem Niveau: "Klicken sie hier, klicken sie dort, drücken sie nacheinander die Tasten 'v', 'o', 'i', 'd' gefolgt von der Leertaste", oder der Autor versucht durch Beamtendeutsch möglichst inetelligent zu klingen. Vor allem im Informatikbereich ist es schlimm, aber auch in den vielen anderen Fachgebieten, wie z.B. auch Elektronik.
....Was an deutscher "Fach"literatur erhältlich ist, ist ein Trauerspiel (bis auf sehr wenige Ausnahmen einiger handvoll Autoren).... von diesen o.g. nichtsnutzen(autoren) trollen sich bestimmt auch einige hier im forum rum, um für die bücher zu ........ mfg pebisoft
Das Problem sind die Überstzungen! Teilweise SACHLICH falsch = einfach nur falsch übersetzt. Die Übersetzer nd die Lektoren haben vom "speziellen"-Fachlichen üblicherweise keine Ahnung.
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.