Unter Project|Properties|AVR|Target Hardware habe ich ATmega88
ausgewählt.
Merkwürdigerweise ist in io.h das Symbol '__AVR_ATmega16__' definiert
und so der Header <avr/iom16.h> geladen.
Wenn ich auf dem Symbol '__AVR_ATmega16__' F3 drücke, meint Eclipse:
Could not find symbol '__AVR_ATmega16__' in index.
Was ist da los?
Uhu Uhuhu schrieb:> Merkwürdigerweise ist in io.h das Symbol '__AVR_ATmega16__' definiert> und so der Header <avr/iom16.h> geladen.
Sagt wer? Der Eclipse-Editor? Der liegt bei so etwas öfter mal falsch,
und über die Kommandozeile übergebenen Parameter (wie z.B. -mcpu=xxx)
kennt der schon gar nicht.
Einfach ignorieren.
Oliver
Danke. Daß er auf der gcc Kommandozeile definierte Symbole nicht kennt,
mag ja noch angehen, nur daß er dann irgendwas erfindet, ist schon grob
irreführend.
Ich hab jetzt mal mit #error ein wenig herumexperimentiert - für gcc ist
es tatsächlich ein mega88.
Uhu Uhuhu schrieb:> nur daß er dann irgendwas erfindet, ist schon grob> irreführend.
Erfinden erfindet er Editor nichts. Der zeigt nur an, welche defines
nach seinem Erkenntnisstand definiert sind. Vermutlich ist in den
avr-libc-Headern der Mega 16 aktiv, wenn nichts anderes definiert wird.
Oliver
Oliver schrieb:> Vermutlich ist in den> avr-libc-Headern der Mega 16 aktiv, wenn nichts anderes definiert wird.
Sieht nicht so aus. Zumindest finde ich mit grep -R '__AVR_ATmega16__' *
in /usr/local/avr/avr/include nichts; ebensowenig in meinem Projektbaum.
Stimmt. Das war nur eine Vermutung von mir. Ich hab jetzt mal
nachgeschaut, und "richtigerweise" zeigt mir der Editor an, daß gar kein
Prozessor definiert ist.
Oliver
Ich habe jetzt versucht, das Problem zu umschiffen - leider mit mäßigem
Erfolg.
Als erster Header in jedem meiner Source Files wir ein Header geladen,
der folgende Definitionen enthält:
1
#undef __AVR_ATmega16__
2
#if __AVR_ATmega88__ != 1
3
#error Current -mmcu option is not atmega88
4
#endif
5
#define __AVR_ATmega88__ 1
Jetzt wird in io.h in Eclipse nicht mehr _AVR_ATmega16_ als definiert
angenommen, sondern '__AVR_ATmega8__'.
Auch ein clean ändert daran nichts.
Nachtrag: Wenn man in den Header auch noch ein
1
#undef __AVR_ATmega8__
packt, dann zeigt Eclipse in io.h '__AVR_ATmega88__' als definiert an.
Offenbar sind da mehrere dieser Symbole definiert und das erste in der
Liste von io.h gewinnt...
Uhu Uhuhu schrieb:> Ich vermute, daß ein Fehler im AVR-Plugin für Eclipse die Ursache für> dieses komische Verhalten ist.
Das plugin hat mit der Darstellung irgendwelcher defines nichts zu tun.
Das macht alleine der Editor.
Welche Eclipse-Version benutzt du eigentlich? Das bei mit installierte
helios macht alles "richtig" (sprich, für den Editor ist gar kein
Prozessor definiert), und so wird der Code auch dargestellt.
Oliver
Oliver schrieb:> Welche Eclipse-Version benutzt du eigentlich?
Helios
> Das plugin hat mit der Darstellung irgendwelcher defines nichts zu tun.> Das macht alleine der Editor.
Der Editor wird aber kaum dafür zuständig sein, die Compiler-Option
-mmcu auszuwerten, und das datu passende '__AVR_ATmega*__'-Symbol zu
definieren.
Ohne die korrekte Definition dieses Symbols in Eclipse funktioniert das
Ausgrauen der nichtaktiven #if-Blocks nicht.
Sehr merkwürdig ist auch, daß von den '__AVR_ATmega*__' gleich mehrere
definiert sind.
Uhu Uhuhu schrieb:> Zumindest finde ich mit grep -R '__AVR_ATmega16__' *> in /usr/local/avr/avr/include nichts; ebensowenig in meinem Projektbaum.
Da ist das auch nicht drin. Es ist ein Built-in Define; siehe
1
echo | avr-gcc -x c - -E -dM -mmcu=atmega16 |sort
gcc kennt 3 Arten von Defines: built-in, per -D und per #define.
Johann L. schrieb:> Da ist das auch nicht drin.
Das wollte ich mit dem grep ja nachprüfen...
Da bei mir mindestens die Symbole '__AVR_ATmega8__' und
'__AVR_ATmega16__' zusätzlich zu dem eigentlich erwarteten
'__AVR_ATmega88__' definiert sind und es sich - wie dur richtig sagst -
um built-in-defines handelt, kann eigentlich nur das AVR-Plugin für
Eclipse dafür verantwortlich sein, denn in dessen Property-Page wird das
Target Device definiert.
Allerdings interessiert hier nicht, welchen Status diese Defines im gcc
haben - der ist noch nicht gelaufen, wenn der Eclipse-Editor falsch
anzeigt, welche #if-Blocks expandiert werden und welche nicht.
Es ist schon ein paar Jahre her, wo ich mir Eclipse mal angeschaut habe.
Alles folgende daher unter der Prämisse "wenn ich mich richtig
erinnere".
Uhu Uhuhu schrieb:> Allerdings interessiert hier nicht, welchen Status diese Defines im gcc> haben - der ist noch nicht gelaufen, wenn der Eclipse-Editor falsch> anzeigt, welche #if-Blocks expandiert werden und welche nicht.
Doch, er ist schon gelaufen. Eclipse merkt sich alles mögliche von
früheren Compiler-Läufen. Außerdem führt das C-Plugin wohl auch einen
ähnlichen Compiler-Aufruf aus, wie den von Georg-Johann gezeigten, um an
die ganzen vordefinierten Sachen zu kommen (da gibt es ja schließlich
einige, nicht nur die __AVR_*).
Kann es vielleicht sein, dass du in dem Projekt schon ein paar mal das
Device gewechselt hast? Es wäre dann nämlich denkbar, dass du dann halt
mehrere dieser Device-Defines im Cache hast. Es gibt aber einen
Menüpunkt, mit dem der komplette Cache für das aktuelle Projekt gelöscht
wird (oder neu aufgebaut wird). Den würde ich mal ausprobieren.
Stefan Ernst schrieb:> Doch, er ist schon gelaufen.
Das Ausgrauen nicht expandierter #if-Blocks funktioniert auch sofort,
nachdem man die Bedingungsdefinition im Quelltext geändert hat - zu
diesem Zeitpunkt ist gcc definitiv noch nicht gelaufen.
Daraus folgt, daß das C-Plugin von Eclipse die Preprozessor-Anweisungen
selbst auswertet und den Editor entsprechend steuert.
> Kann es vielleicht sein, dass du in dem Projekt schon ein paar mal das> Device gewechselt hast?
Ja und es waren mega8 und mega16 - die Typen, die auch jetzt noch
definiert sind. Das ist aber schon längere Zeit her.
> Es gibt aber einen> Menüpunkt, mit dem der komplette Cache für das aktuelle Projekt gelöscht> wird (oder neu aufgebaut wird). Den würde ich mal ausprobieren.
Gute Idee.
Clean ist es nicht - das behebt das Problem nicht.
Unter Project|Preferences|C/C++|Indexer gibt es zwar
Einstellmöglichkeiten für den Indexer-Cache, aber nichts um ihn zu
löschen und neu aufzubauen.
Uhu Uhuhu schrieb:> Das Ausgrauen nicht expandierter #if-Blocks funktioniert auch sofort,> nachdem man die Bedingungsdefinition im Quelltext geändert hat - zu> diesem Zeitpunkt ist gcc definitiv noch nicht gelaufen.>> Daraus folgt, daß das C-Plugin von Eclipse die Preprozessor-Anweisungen> selbst auswertet und den Editor entsprechend steuert.
Ja, die Defines, die direkt im Sourcecode stehen, werden natürlich
direkt und sofort und ohne den Compiler ausgewertet. Daraus folgt aber
nicht, dass das ausschließlich so läuft. Ansonsten würde ja der Editor
von den vordefinierten Dingen gar nichts wissen können.
Uhu Uhuhu schrieb:> clean ist es nicht - das behebt das Problem nicht.
Gab es nicht auch noch ein "Clean Project", oder so ähnlich?
Stefan Ernst schrieb:> Ansonsten würde ja der Editor> von den vordefinierten Dingen gar nichts wissen können.
Dafür sind die Plugins zuständig. Der Editor macht dann nur noch, was
die ihm einflüstern.
> Gab es nicht auch noch ein "Clean Project", oder so ähnlich?
Project | Clean - das meinte ich...
Uhu Uhuhu schrieb:> Stefan Ernst schrieb:>> Ansonsten würde ja der Editor>> von den vordefinierten Dingen gar nichts wissen können.>> Dafür sind die Plugins zuständig. Der Editor macht dann nur noch, was> die ihm einflüstern.
Das sagte ich doch. Das C-Plugin holt sich die Infos über die
Pre-Defines aus dem Compiler-Output (woher auch sonst), und cached sie.
Uhu Uhuhu schrieb:> Jetzt fragt sich nur noch, wie man den alten Mist wieder losbekommt.
Welche Eclipse Version hast Du?
Ich meine ab 3.6 (Helios) kann man den Symbol-Cache von der
Benutzeroberfläche aus löschen (Ich habe es gerade mit 3.7/Indigo
ausprobiert):
Project-> Properties -> C/C++ Build -> Discovery Options -> "Clear
discovered entries now" und das Projekt neu "builden"
Bei Eclipse-Versionen vor 3.6 konnte man diesen Cache nicht von der
Benutzeroberfläche aus löschen. Dafür gab es eine Hack:
http://avr-eclipse.sourceforge.net/wiki/index.php/Known_Issues#After_update_of_the_avr-gcc_toolchain_Include_paths_still_point_to_the_old_location
Und damit es hier keinen Streit gibt woher der Editor die aktuellen
Defines kennt:
Eclipse, genauer gesagt CDT, nutzt den sogenannten "Discovery"
Mechanismus um möglichst alle definierten Symbole zu ermitteln. Dazu
wird (unter anderem) der GCC mit ein paar speziellen Parametern
gestartet um alle im GCC eingebauten Symbole zu ermitteln. Das
AVR-Plugin hängt sich hier mit ein und übergibt auch noch den Parameter
"-mmcu=..." mit der aktuellen Projekt Target MCU (und F_CPU) damit
avr-gcc die entsprechenden MCU-abhängigen Symbole ausspuckt.
Mit der Liste der gefunden Symbole kann sich wiederum der Indexer (?)
durch alle Includes durchhangeln und die entsprechenden #defines mehr
oder weniger korrekt parsen. Wann der Indexer automatisch anspringt weiß
ich jetzt spontan nicht. Aber mit Project -> Index -> Rebuild kann man
ihn auch manuell starten.
Und zum Schluss greift der Editor auf die vom Indexer gefunden #defines
zu um #ifdefs entsprechend darzustellen und mit F3 die Definitionen
anzuspringen
Welche Symbole Eclipse aktuell für das Projekt gespeichert hat kann man
unter: Project -> Properties -> C/C++ General -> Paths and Symbols ->
#Symbols sehen wenn man "Show built-in values" aktiviert.
Thomas
Thomas Holland schrieb:> Welche Eclipse Version hast Du?
Helios
> Ich meine ab 3.6 (Helios) kann man den Symbol-Cache von der> Benutzeroberfläche aus löschen (Ich habe es gerade mit 3.7/Indigo> ausprobiert):> Project-> Properties -> C/C++ Build -> Discovery Options -> "Clear> discovered entries now" und das Projekt neu "builden"
Das hilft leider auch nichts. Der ATmega16 ist in io.h nach wie vor
definiert.
Merkwürdig ist auch, daß ich die Symbole mit
1
#undef __AVR_ATmega16__
2
#undef __AVR_ATmega8__
wegbekomme. Vordefinierte Symbole sollten sich mit #undef nicht
beseitigen lassen.
Thomas Holland schrieb:> Welche Symbole Eclipse aktuell für das Projekt gespeichert hat kann man> unter: Project -> Properties -> C/C++ General -> Paths and Symbols ->> #Symbols sehen wenn man "Show built-in values" aktiviert.
Dort sehe ich nur die Symbole, die ich selbst -D unter Project ->
Properties -> C/C++ Build -> Settings -> Tool Settings -> AVR Compiler
Symbols definiert habe.
"Show built-in values" bewirkt nichts.
Ich habe jetzt einfach mal den #include-Verteiler aus io.h herauskopiert
und in dieser Art modifiziert in einen neu angelegten Source-File in
Eclipse eingefügt:
1
#if defined (__AVR_AT94K__)
2
//# include <avr/ioat94k.h>
3
#endif
4
#if defined (__AVR_AT43USB320__)
5
//# include <avr/io43u32x.h>
6
#endif
7
...
Ich habe in den Optionen des AVR-Plugins ATmega88 eingestellt - der
zugehörige #include-Block wird korrekt hell angezeigt.
Alle anderen #include-Blocks, außer denen für ATmega8 und ATmega16 sind
korrekt grau dargestellt.
Da kein Headerfile eingelesen wird, müssen die Symbole für ATmega8 und
ATmega16 wohl aus dem AVR-Plugin kommen. (Wie schon geschrieben, hatte
ich auch diese beiden Prozessortypen früher schon einmal eingestellt.)
Du wurschtelst jetzt schon so lange daran rum und fängst jetzt sogar an
die System-Header zu modifizieren, und das alles bloß wegen der Optik.
Dir ist schon klar, dass das ein reines Anzeigen-Problem ist und nicht
die geringsten Auswirkungen auf das Compilieren hat, oder? Wenn dich die
fehlerhafte Anzeige so stört/irritiert, dann lege doch einfach ein neues
Projekt an.
Stefan Ernst schrieb:> Du wurschtelst jetzt schon so lange daran rum und fängst jetzt sogar an> die System-Header zu modifizieren, und das alles bloß wegen der Optik.
Lesen ist wohl nicht dein Ding?
> Dir ist schon klar, dass das ein reines Anzeigen-Problem ist und nicht> die geringsten Auswirkungen auf das Compilieren hat, oder?
Es soll auch Fehler geben, die die Anzeige betreffen.
Uhu Uhuhu schrieb:> Lesen ist wohl nicht dein Ding?>>> Dir ist schon klar, dass das ein reines Anzeigen-Problem ist und nicht>> die geringsten Auswirkungen auf das Compilieren hat, oder?>> Es soll auch Fehler geben, die die Anzeige betreffen.
Dein Ding ist es wohl auch nicht, was?
Habe ich etwa behauptet, dass es kein Fehler ist? Aber es ist ein
Problem, das nur die Anzeige betrifft, und keine Auswirkungen auf
den generierten Code hat. Insofern finde ich einfach nur, dass du zu
viel Zeit damit verschwendest. Aber nun gut, ist ja schließlich deine
Zeit.
Wieso regst du dich eigentlich dermaßen auf?
Stefan Ernst schrieb:> Insofern finde ich einfach nur, dass du zu viel Zeit damit verschwendest.
Das kannst du getrost meine Sorge sein lassen.
Thread beobachten
Seitenaufteilung abschalten