Eclipse: Problem mit Auswahl des Target-Typs

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.

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.

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...

Ich vermute, daß ein Fehler im AVR-Plugin für Eclipse die Ursache für 
dieses komische Verhalten ist.

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.

Stefan Ernst schrieb:
> und cached sie.

Jetzt fragt sich nur noch, wie man den alten Mist wieder losbekommt.

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.

Uhu Uhuhu schrieb:
> Merkwürdig ist auch, daß ich die Symbole mit
>

1

  #undef __AVR_ATmega16__

2

>   #undef __AVR_ATmega8__

3

>

> wegbekomme. Vordefinierte Symbole sollten sich mit #undef nicht
> beseitigen lassen.

Sowas wie "persistente Makros" gibt's nicht.
#undef funktioniert wie dokumentiert.

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.