Forum: Mikrocontroller und Digitale Elektronik AVR eclipse error message problem!!


von tantal.lpt (Gast)


Lesenswert?

Hi,

Ich habe ein Problem mit eclipce und dem AVR-Plugin. Eingerichtet habe 
ich alles und es funktioniert soweit auch alles. Nur bekomm ich jede 
menge Fehlermeldungen eingeblendet. z.B. wenn ich einen Port beschreiben 
will oder direction register für einen Port. Es ist keine Nachricht von 
compiler sondern vom eclipse Editor selbst.

hier mein code:
1
#include <avr/io.h>
2
3
int main(void)
4
{
5
  DDRC = 0xff;  //error 1
6
  PORTC = 0xff; //error 2
7
  while(1);
8
9
  return 0;
10
}

der code läuft zwar wunderbar, doch bekomme ich hier schon zwei 
Fehlermeldungen mit dem Text:
"Symbol 'DDRC' could not be resolved"
bzw.
"Symbol 'PORTC' could not be resolved"

habe schon danach gegoogelt nur leider nichts gefunden.

von Läubi .. (laeubi) Benutzerseite


Lesenswert?

Includepfade in den Projektsettings anpassen sodass er avr/io.h finden 
kann.

von Lutz (Gast)


Lesenswert?


von tantal.lpt (Gast)


Lesenswert?

Danke erstmal für die schnelle Antwort.

Die Include Pfade sollten eigentlich stimmen. Sonst könnt ich ja auch 
nicht kompilieren. Wie gesagt der Kompiler mecker ja auch gar nicht. Es 
ist irgendwie der Editor.

von tantal.lpt (Gast)


Lesenswert?

Hi,

Ich glaube ich habe das Problem jetzt selbst gelöst. Ich habe noch 
zusätzlich die iom8.h (für ATMeag8) includiert. Brauchte ich zwar sonst 
nie machen aber jetzt sind die Meldungen weg.

gruß Mathias

von Läubi .. (laeubi) Benutzerseite


Lesenswert?

Die includepfade des Compiler sind aber möglicherweise andere als die 
der Entwicklungsumgebung (= Eclipse)!

Wenn alles richtig konfiguriert ist, mußt du z.B. mit F3 (Cursor auf dem 
include) zur Headerdatei springen können.

von RC Funker (Gast)


Lesenswert?

Hallo!

Ich habe derzeit dasselbe Problem. Das Projekt wird kompiliert und 
funktioniert auch, aber die Errors treten dennoch auf.
Meines erachtens stimmen die Pfade, da das Springen zur Include-File mit 
F3 problemlos funktioniert.
Dennoch: Wo müsste ich die Include-Pfade für die IDE angeben?

Gibt es  noch andere Gründe dafür? Ist eben ein bisschen nervig, wenn 
man nicht die richtigen Fehler angezeigt bekommt...

Das manuelle Einbinden der iom8.h z.B. ist auch nicht das Gelbe vom Ei, 
da genau das ja vermieden werden soll.

Danke schonmal!

von Mike J. (emjey)


Lesenswert?

Ich hatte den Fehler auch nachdem ich Eclipse_cpp_indigo mit dem 
AVR_Plugin installiert habe.

Mit Eclipse_java_indigo + AVR_Plugin geht es aber.

von RC Funker (Gast)


Lesenswert?

Dann wird es das vermutlich sein...
Ich habe ebenfalls die C-Developer Variante installiert. Vielen Dank. 
Ich werde das ausprobieren!

von Läubi .. (laeubi) Benutzerseite


Lesenswert?

RC Funker schrieb:
> Gibt es  noch andere Gründe dafür?

Ja, z.B. das nicht der korrkete MCU Typ (bzw. das define) dazu fehlt. 
Also einfach mal das fragliche Define per Hand VOR den Headerinclude 
setzen und schauen ob es hilft. Wenn ja Prozessortyp korrekt definieren.

von RC Funker (Gast)


Lesenswert?

Das entsprechende define davor zu schreiben habe ich natürlich auch 
schon gemacht.
Die Lösung war so einfach wie Mike sagte.

Einfach die Eclipse Classic Version benutzen und das AVR-Plugin 
installieren. Die Abhängigkeiten kann er selbst auflösen.

von Jonas S. (jonas_s84)


Lesenswert?

Hallo zusammen,

Bei mir scheint auch die Eclipse Classic Version mit AVR-Plugin nicht zu 
funktionieren...

Habe zusätzlich das CDT C/C++ Plugin installiert.

von Jonas S. (jonas_s84)


Lesenswert?

Habe nun die Eclipse Helios Version verwendet. Die Fehler sind 
verschwunden.
Sieht so aus, als ob Indigo und das AVR-Plugin noch nicht ganz 
kompatibel sind.

von Marc S. (marcnesium)


Lesenswert?

Hallo!

Was ist jetzt die abschließende Lösung? Ich habe es noch nicht gelöst 
bekommen...
Meine aktuelle Vermutung ist, dass CDT und das avr plugin nicht 
miteinander können.
Zunächst hatte ich auf ein naktes eclipse (indigo) das avr plugin 
installiert und es funktionierte (Symbole konnte aufgelöst werden). Nun 
hatte ich zusätzlich CDT installiert, weil ich mit gdb debuggen wollte. 
Zwar funktioniert in meinem alten Projekt noch alles, aber in neu 
angelegten Projekten ist die Auflösung der Symbole wieder kaputt. Ich 
habe jetzt echt lange gesucht, habe aber nicht herausgefunden warum.

Hat das jemand bereits ergründet?

Ciao, Marc.

von Thomas H. (innot)


Lesenswert?

Hi,

erstmal was Grundsätzliches: das AVR Eclipse Plugin läuft (bei mir) 
problemlos auch mit Eclipse Indigo. Wenn es mal nicht funktioniert liegt 
es wahrscheinlich nicht an der Kombination der beiden sondern an irgend 
etwas anderem.

zweitens: Bitte installiert immer erst CDT (am besten in dem ihr das 
"Eclipse for C/C++ Developers" runterladet), bevor ihr das AVR Eclipse 
Plugin installiert. Das AVR Eclipse Plugin benutzt viele Funktionen von 
CDT und ich kann habe keine Ahnung was passiert wenn das AVR Eclipse 
Plugin ohne CDT gestartet wird. Möglicherweise werden inkonsistente 
Konfigurationsdaten erstellt, die später nicht mehr funktionieren.

drittens: was der Compiler an Symbolen sieht hat grundsätzlich erst mal 
nichts mit dem zu tun was Eclipse an Symbolen sieht. Zwar versucht 
Eclipse/CDT mit diversen Methoden rauszufinden, was der Compiler kennt, 
aber diese Methoden sind nicht wasserdicht und manchmal fehlerhaft.

Mit der nächsten Version des AVR Plugins (ja, ich arbeite noch daran -- 
habe aber nicht mehr so viel Zeit wie früher dafür) wird sich das ganze 
"Discovery" Zeug etwas verbessern und mit der nächten Version von CDT 
(9.0, evtl. nächstes Jahr) wird sich hoffentlich auch der Unterbau von 
CDT deutlich verbessern.
Bis dahin macht bitte ausgiebig von der Funktion zum Löschen des Symbol 
Caches gebrauch: Project -> Properties -> Discovery Options -> "Clear 
discovered entries now". Danach das Projekt noch mal "builden" und 
Eclipse sollte hoffentlich alle Pfade und Symbole richtig erkennen.

Bei der Gelegenheit auch mal checken, dass das "Discovery profile" auf 
"AVRGCCManagedMakePerProjectProfileC" (oder so ähnlich) steht.

LG

Thomas

von Marc S. (marcnesium)


Lesenswert?

Thomas Holland schrieb:

> Mit der nächsten Version des AVR Plugins (ja, ich arbeite noch daran --
> habe aber nicht mehr so viel Zeit wie früher dafür) wird sich das ganze
> "Discovery" Zeug etwas verbessern und mit der nächten Version von CDT
> (9.0, evtl. nächstes Jahr) wird sich hoffentlich auch der Unterbau von
> CDT deutlich verbessern.

Toll, es ist immer gut zu hören, dass an so nützlicher Software, wie 
diesem Plugin, noch weitergearbeitet wird! Keep on rocking!

> Bis dahin macht bitte ausgiebig von der Funktion zum Löschen des Symbol
> Caches gebrauch: Project -> Properties -> Discovery Options -> "Clear
> discovered entries now". Danach das Projekt noch mal "builden" und
> Eclipse sollte hoffentlich alle Pfade und Symbole richtig erkennen.

Ja, das war's! Hat mir geholfen (+ index refresh). DANKE!
Vlt solltest du diesen Hinweis auch auf der Plugin-website noch 
veröffentlichen. Bei Tipps&Tricks oder in der FAQ... Ich (als 
eclipse-Anfänger) habe mir einen Wolf gesucht und bin leider nicht 
selbstständig zu einer Lösung gekommen.

Also, an dieser Stelle nochmal Danke und alle Ermutigung, die man hier 
schriftlich hinterlassen kann, zur Ermutigung, das Plugin 
weiterzuentwickeln!

Ciao, Marc.

von Davor S. (da__x)


Angehängte Dateien:

Lesenswert?

Hey!

Habe genau das selbe Problem, jedoch lässt es sich nicht mit Clear
> discovered entries now - löschen, auch der index refresh hat nicht geholfen.

ich verwende als MCU den ATUSB162.
hab aber auch nen anderen MCU gewählt, erhalte die selben Fehler.

merkwürdig ist auch, dass ich wenn ich den ATUSB162 im "AVR Device 
Explorer" auswählen möchte, ich eine Fehlermeldung bekomme (im Anhang). 
jedoch, funktioniert die auswahl jedes anderen µC's   .... :/

da ich schon lange eclipse für andere programmierarbeiten verwende und 
mir das tool sehr sympathisch ist würde ich es auch gerne 
weiterverwenden!

von Läubi .. (laeubi) Benutzerseite


Lesenswert?

Davor Stosic schrieb:
> da ich schon lange eclipse für andere programmierarbeiten verwende und
> mir das tool sehr sympathisch ist würde ich es auch gerne
> weiterverwenden!

Hast du den schon geschaut ob die Pfade stimmen so wie es die 
Fehlermeldung vorschlägt?

von Davor S. (da__x)


Lesenswert?

ja, habe ich.

außerdem sollte er dann bei den anderen MCU's ja auch mecker, oder?

anyway. die pfade hab ich überprüft, ändert nichts.

es ist auch so, dass wenn ich die avr/iousbxx2.h include, er mir dann 
keinen fehler anzeigt. aber das ist ja nicht schön :/

von 900ss (900ss)


Lesenswert?

Thomas Holland schrieb:
> erstmal was Grundsätzliches: das AVR Eclipse Plugin läuft (bei mir)
> problemlos auch mit Eclipse Indigo.

Kann ich so bestätigen. Allerdings nur, wenn das GNU ARM-Plugin nicht 
installiert ist. Das zickt noch rum für "Indigo". Ob der letzte Submit 
vom ARM Plugin in Sourceforge besser ist, hab ich nicht geprüft.

900ss

von Davor S. (da__x)


Lesenswert?

hab nun eclipse classic runtergeladen, CDT nachinstalliert, danach das 
AVR plugin. bekomme jetzt ne andere fehlermeldung beim builden....

"**** Build of configuration Debug for project test ****

make all
Building file: ../test.c
Invoking: AVR Compiler
avr-gcc -Wall -g2 -gstabs -O0 -fpack-struct -fshort-enums -std=gnu99 
-funsigned-char -funsigned-bitfields -mmcu=at90usb162 -DF_CPU=8000000UL 
-MMD -MP -MF"test.d" -MT"test.d" -c -o "test.o" "../test.c"
/usr/bin/sh: /c/WinAVR-20100110/bin/avr-gcc: Bad address
make: *** [test.o] Error 126

**** Build Finished ****
"

hat jmd. ne idee  :/  ?  (die pfade sind korrekt eingestellt)

von Michael S. (kraeml)


Lesenswert?

Hab hier das gleiche Problem. Die Pfade stimmen, das Projekt wird 
erstellt und kann geflasht werden. Nur die Fehlermeldungen sind nervig, 
da dies def. keine sind.
Ein Clear führt leider auch zu keinem Ergebnis. Wäre schön, wenn jemand 
dazu noch eine Lösung finden würde. Werde selber noch mal auf helios 
downgraden. Da lief es noch alles.

Gruß Kräml

von Michael S. (kraeml)


Lesenswert?

So hab mir helios gezogen. Hier sind keine Fehlermeldungen. Weiß leider 
nicht, wo her die Fehler kommen.
Anmerkung: Verwende Ubuntu 64Bit.

von Thomas H. (innot)


Lesenswert?

Davor Stosic schrieb:

> /usr/bin/sh: /c/WinAVR-20100110/bin/avr-gcc: Bad address
> make: *** [test.o] Error 126

Davor, wie ich an Deinem Screenshot weiter oben gesehen habe arbeitest 
Du mit Windows. Die Fehlermeldung sieht aber mehr nach Unix bzw. CygWin 
aus.

Möglicherweise wird das falsche "make" gestartet, nämlich das von CygWin 
und nicht das von WinAVR.

Check doch bitte mal ob der Pfad zum "make" korrekt gesetzt ist 
(Preferences->AVR->Paths->GNU make)

von Davor S. (da__x)


Lesenswert?

ok habs hinbekommen. Vielen Dank!!!

hättest du vllt. nen tipp wie ich das weiter oben geschilderte problem 
mit dem öffnen des header-files iousb162.h löst. das lässt mich nämlich 
nicht in ruhe.

hab auch schon nen eigenen thread gestartet, aber wies aussieht bin ich 
mit dem problem alleine.

Beitrag "AVR Eclipse Plugin - Problem mit AT90USB162"

von Johannes E. (cpt_nemo)


Lesenswert?

Ich habe ein ähnliches Problem mit Eclipse Indigo SR1 64bit unter 
Windows 7 64bit:

Ich kann mein Projekt (Makefile-Projekt, also nicht automatisch 
erstellt) ganz normal kompilieren, Eclipse zeigt aber viele 
Fehlermeldungen an.


Ich habe folgendes festgestellt:

1. Wenn ich mir in Projekt Properties bei "discovered paths" die 
"Include Paths" ansehe, dann steht dort "C:\Programme\winavr\..."; mein 
Winavr liegt aber in einem ganz anderen Verzeichnis auf einem anderen 
Laufwerk.

Wenn ich die korrekten Pfade von Hand eintrage, werden zumindest die 
Include-Dateien erkannt.

2. Weiterhin kommen Fehlermeldungen bei den Datentypen aus stdint.h, 
z.B. "uint16_t". Bisher habe ich die stdint.h nie explizit eingebunden 
und es hat immer funktionert (mit anderen Eclipse-Versionen). Mit 
#include <stdint.h> gehen auch diese Fehlermeldungen weg.

3. Jetzt habe ich noch Fehlermeldungen bei den AVR-Registern (z.B. 
"PORTA"), dafür habe ich keine Lösung gefunden.


Thomas Holland schrieb:
> Bis dahin macht bitte ausgiebig von der Funktion zum Löschen des Symbol
> Caches gebrauch: Project -> Properties -> Discovery Options -> "Clear
> discovered entries now".

Diese Funktion gibt es bei mir gar nicht bzw. ich habe sie nicht 
gefunden. Kannst du bitte beschreiben, wo genau diese Funktion ist. Gibt 
es Unterschiede zwischen der Linux- und Windows-Version bzw. bei 64 bit?

von Thomas H. (innot)


Angehängte Dateien:

Lesenswert?

Johannes E. schrieb:
>> Bis dahin macht bitte ausgiebig von der Funktion zum Löschen des Symbol
>> Caches gebrauch: Project -> Properties -> Discovery Options -> "Clear
>> discovered entries now".
>
> Diese Funktion gibt es bei mir gar nicht bzw. ich habe sie nicht
> gefunden. Kannst du bitte beschreiben, wo genau diese Funktion ist. Gibt
> es Unterschiede zwischen der Linux- und Windows-Version bzw. bei 64 bit?

Siehe Screenshot.

Ich habe ürigens gerade gesehen, dass es besser ist die Einstellung 
"Discovery profiles scope" auf "Configuration-wide" zu stellen.
Wenn es auf "Per Language" steht, dann muss man in der Tools Liste 
darunter "Unknown" anstatt "C Source Files" auswählen, sonst 
funktioniert "Clear" nicht.

Nachdem man "Clear" gedrückt hat kann man gleich unter "C/C++ General -> 
Paths and Symbols" nachschauen, ob man erfolgreich war: Sowohl die 
"Includes" als auch "Symbols" Liste sollte leer sein.

Ich habe jetzt gerade auch mal ein Makefile Projekt ausprobiert. Aber 
dabei gibt es in der Tat Probleme, weil die in Eclipse/CDT eingebauten 
Discovery-Mechanismen nicht erkennen können, welche MCU benutzt werden 
soll (die Einstellung unter "AVR-> Target Hardware" wird bei makefile 
Projekten ignoriert)

Um das Problem zu lösen habe ich zwei Methoden ausprobiert, die bei mir 
zu funktionieren scheinen.

Methode A
1. Ein neues AVR-Project mit der gewünschten MCU erstellen (kein 
Makefileproject).
2. Alle Dateien Deines bisherigen Projektes in das neue Projekt 
kopieren.
3. Das Projekt builden und anschliessend noch den Index "rebuilden".
4. Dann in den Properties des neuen Projektes die automatische 
Erstellung des Makefiles abstellen und die "Build Location" auf das 
Verzeichnis stellen, in dem das makefile liegt. Beide Einstellungen sind 
unter "C/C++ Build" in "Builder Settings" Tab zu finden.

Methode B
In Dein makefile noch ein Compiler-Flag mit "-D__AVR_ATmegaXYZ__" 
einbauen. Bei den üblichen MFile makefiles durch einfügen der Zeile
1
CFLAGS += -D__AVR_ATmega169__
Anschliessed das Projekt bulden und den Index "rebuilden"


Alles übrigens mit einem jungfräulichen Eclipse Indigo for C/C++ 
Developers 64bit auf Win7 64bit ausprobiert.

von zaphod_beeblebrox (Gast)


Lesenswert?

Hi,
also bei mir geht es nicht ohne die explizite Nennung der passenden 
io-header-Datei.
1
int main( void )
2
{
3
  uint8_t i;
4
5
  i = 0;
6
  DDRB=0x01;
7
8
  while (1)
9
    sei();
10
}

Zu Anfang war uint8_t im Editor als Fehler. Nach dem ersten Build gehts. 
DDRB war immer noch Fehlerhaft. Erst nach dem Einfügen von
#include <avr/iom128.h> zusätzlich zu #include <avr/io.h> verschwindet 
der Fehler.
Nicht so toll, aber es geht nun (scheinbar) alles mit Indigo Service 
Release 1 Build id: 20110916-0149 Windows 7 64 Bit.

Viele Grüße,
Matthias

von Yogi (Gast)


Lesenswert?

Hallo zusammen,

hier noch ein weiterer Lösungsvorschlag. Die zuvor genannten Dinge haben 
bei mir immer nur teilweisen Erfolg gehabt und auch ich finde die 
händische includierung der MCU-typischen io.h nicht besonders hübsch. 
Wichtig: Der Compiler lief bei mir immer, nur der eClipse-Indigo Editor 
hat gemosert:

Anscheinend weiß Indigo nichts mehr über die Dateitypen und 
Sprachzuordnungen, denn diese waren bei mir leer. Diese müssen erneut 
für .c-Sourcefiles und .h-Headerfiles händisch vorgenommen werden. Dies 
erfolgt unter
- Windows->Preferences->C/C++->Language Mappings
- dort einmal C-header für GNU-C ...
- .. und einmal C-source für GNU-C zuweisen


Ich hab jetzt ein lauffähiges Indigo und meine ganzen alten Projekte 
compilieren UND der Editor mosert nicht mehr.

von zaphod_beeblebrox (Gast)


Lesenswert?

Yogi schrieb:
> Diese müssen erneut
> für .c-Sourcefiles und .h-Headerfiles händisch vorgenommen werden. Dies
> erfolgt unter
> - Windows->Preferences->C/C++->Language Mappings
> - dort einmal C-header für GNU-C ...
> - .. und einmal C-source für GNU-C zuweisen



Affengeil! Funktioniert!!!

von peter (Gast)


Lesenswert?

Bei mir leider nicht!

:-((((

von Johannes D. (joed84)


Lesenswert?

Ich habe auch alle oben beschriebenen Lösungsvorschläge abgearbeitet.
Keiner brachte die gewünschte Lösung.

Der Header für meinen Controller wird nicht eingebunden.

Gentoo mit Indigo
CDT über Update
Eclipse Plugin über Update

von SP (Gast)


Lesenswert?

Yogi schrieb:
> Anscheinend weiß Indigo nichts mehr über die Dateitypen und
> Sprachzuordnungen, denn diese waren bei mir leer. Diese müssen erneut
> für .c-Sourcefiles und .h-Headerfiles händisch vorgenommen werden. Dies
> erfolgt unter
> - Windows->Preferences->C/C++->Language Mappings
> - dort einmal C-header für GNU-C ...
> - .. und einmal C-source für GNU-C zuweisen

Hallo,

vielen Dank an Yogi für sein
Workaround. Bei mir funktioniert es.
Vorher hab ich exakt die Modifikationen, vorgeschlagen
von Thomas Holland (s.o. Artikel vom 11.09.2011 22:31),
vorgenommen, dann die Ergänzungen von yogi
eingetragen.

VG
SP

von Thomas H. (innot)


Lesenswert?

Hi, anstatt ewig an neuen Features rumzubasteln habe ich mal eine 
aktualisierte Version des AVR Eclipse Plugins gebaut.

Für diesen Thread relevant is vor allem das verbesserte "Discovery" 
handling. Beim Ändern des MCU Typs für ein Projekt wird automatisch der 
gesamte Symbols & Path Cache gelöscht und neu generiert, inkl. des 
Index.

Ich hoffe, das damit eure Probleme behoben werden.

Da ich die neue Version nicht ausgiebig testen konnte, gibt es erst mal 
nur eine Beta zum manuellen Download:

https://sourceforge.net/projects/avr-eclipse/files/avr-eclipse%20beta%20versions/

Ich denke das es keine Probleme mit einem Update auf die Beta geben 
sollte, da keine internen Strukturen verändert wurden, mit einer 
Ausname: Bei den Fuses / Lockbits hat sich intern etwas geändert und 
wenn ihr in Euren Projekten mit Fuse-Files und Fuse-Settings arbeitet 
solltet ihr ein Backup der Projekte in Erwägung ziehen.

Zum Installieren die Datei 'avreclipse.2.4.0.beta.p2repository.zip' 
herunterladen und entpacken.
Anschliessend bei Eclipse über 'Help -> Install new Software -> Add... 
-> Local...' den entpackten Ordner auswählen und OK klicken.

Ich habe das Plugin übrigens kurz mit Eclipse 3.7 getestet, sowohl unter 
Window 7 als auch Ubuntu 11.10, jeweils in den 64 Bit Versionen.
Eclipse 3.6 habe ich nicht ausprobiert, aber da das Plugin mit 3.6 
compiliert wird sollte es auch damit keine Schwierigkeiten geben (famous 
last words :-))

Feedback ist erwünscht :-)

Thomas

von patrick (Gast)


Lesenswert?

Hi!


Ich habe das gleiche Problem unter MacOSX 10.6.8.

Es funktionieren als Lösungswege weder das Löschen, noch das manuelle 
include der MCU-Spezifischen io*.h Datei.

Gerade wollte ich auf die Beta-Version des AVR-Plugins updaten, bekomme 
das aber nicht hin:

Installiert habe ich das AVR-Plugin über das "Install New Software ..." 
unter Eclipse Indigo für CPP.

Die Beta lässt sich darüber ja nicht installieren, laut 
installationsanleitung müssen ja die Dateien einfach nur in das 
Eclipseverzeichnis kopiert werden.

Zunächst wollte ich jedoch das stable Release erst deinstallieren, und 
zwar über den internen Plugin-Manager ("Was ist bereits 
installiert-Knopf").

Und siehe da: Es geht nicht! Das Plugin ist nicht deinstallierbar! Auch 
die Sources kann ich nicht deinstallieren (because of other installed 
software).

Mach ich da was falsch? Gibts da nen Trick?

Ehrlich gesagt habe ich jetzt nicht unbedingt die Lust, Indigo komplett 
neu zu installieren und die anderen Plugins (Latex etc. ) neu zu 
installieren, vor allem weil ich noch laufende Projekte habe und keine 
Lust wieder einen ganzen Nachmittag zu konfigurieren bis der andere 
Krempel anstandslos läuft ;)

Wie bekomme ich jetzt die beta in mein vorhandenes Indigo?


Vielen Dank für das AVR-Plugin übrigens :) Geniales Projekt!


Beste Grüße,

Patrick

von patrick (Gast)


Lesenswert?

Ok ich habs jetzt auf Folgende Art und Weise hinbekommen:

1.: Eclipse Classic 3.7.1. für MacOSX 64bit geladen.
    (Ich benutze MacOSX 10.6.8 Snow Leopard)

2.: Unter HELP -> Install New Software ... -> Als Source
    "Indigo - http://download.eclipse.org/releases/indigo"; verwenden und
    das Paket "C/C++ Development Tools" unter "Programming Languages"
    installiert.

3.: Die AVR-Plugin aktuelle beta heruntergeladen und entpackt.

4.: Wieder bei "Install New Software" in der ersten Zeile rechts unter 
"Add"
    dann "Local" den Pfad zum entpackten Plugin angegeben.
    Weiter und installationsroutine folgen.

5.: Eclipse neu starten, wie gewohnt neues C Projekt anlegen etc.

Bei NEU angelegten Projekten wurden nach dem #include <avr/io.h> die 
Register problemlos erkannt.
Bei alten Projekten muss man unter "Project - Properties - C/C++ Build - 
Discovery Options" rechts auf "Clear discovered entries now: " klicken 
und dann das Projekt neu "builden", dann hatte es sich bei mir wie im 
Thread schon mehrfach beschrieben erledigt. (Der Weg funktionierte bei 
mir NICHT mit dem direkt installierten Indigo für C/Cpp programmers" 
oder wie das heißt, und er funktioniert auch NICHT in Kombination 
Eclipse-Classic und AVR-Plugin Stable Release!)


So - das ganze hat mich jetzt fast drei lange Abende gekostet, aber 
vielleicht hilft das "feedback" ja irgendjemandem weiter.

Beste Grüße,


Patrick

von Thomas H. (innot)


Lesenswert?

Patrick,

sorry das die Installationsanleitung auf der Homepage veraltet war. Ich 
habe sie jetzt aktualisiert. 
http://avr-eclipse.sourceforge.net/wiki/index.php/Plugin_Download

Thomas

von Sven W. (Firma: basement industries) (dj8nw)


Lesenswert?

Yogi schrieb:
...
> - Windows->Preferences->C/C++->Language Mappings
> - dort einmal C-header für GNU-C ...
> - .. und einmal C-source für GNU-C zuweisen
...

Danke Yogi, durch deinen Workaround funktionierts bei mir endlich auch 
anstandslos!

Schade dass du keinen Flattr-Button hast!;)

von Johannes E. (cpt_nemo)


Lesenswert?

Hallo Thomas,

bei mir funktioniert das Plugin inter Eclipse Indigo jetzt sehr gut, 
wenn im Projekt das Makefile automatisch erzeugt wird.

Wenn ich aber ein eigenes Makefile benutzen möchte, also den Punkt 
"Generate Makefiles automatically" ausschalte, dann werden anscheinend 
alle Defines nicht erkannt, die sich unterhalb von "avr/io.h" befinden, 
also z.B. die aus "avr/iom128.h".

Mein System:
Windows 7, 64 Bit
Eclipse IDE for C/C++ Developers - 1.4.1.20110909-1818
AVR Eclipse Plugin - 2.4.0.20111202-1142-beta

Ich hab ein Zip-File von einem Test-Projekt angehängt, vielleicht kannst 
du bei Gelegenheit testen, ob der Fehler bei dir auch auftritt.

von Johannes E. (cpt_nemo)


Angehängte Dateien:

Lesenswert?

Hier ist der Anhang.

von Thomas H. (innot)


Lesenswert?

Bei mir funktioniert das Projekt problemlos. Projekt importiert, einmal 
ge'buildet', main.c geöffnet, Maus über PORTA gehalten und die Macro 
Expansion wird angezeigt. Keine Warnungen o.Ä.

Eclipse 3.7 (Indigo)
AVR Eclipse Plugin 2.4.0 Beta

von CSpecker (Gast)


Lesenswert?

Mein Erfahrungsbericht:
Das Plugin in V2.4.0 funktioniert bei mir seit dem Update nicht mehr 
fehlerfrei mit Eclipse Helios.
V2.3.4 funktionierte über Monate fehlerfrei mit Helios, bis ich heute 
Morgen den Update gemacht habe.
Beim Versuch das Projekt zu übersetzen sturzte der make ab (make: write 
error: No such file or directory). Abhängigkeiten (F3) wurden im 
gesamten nicht mehr aufgelöst.

Der einfachste Weg das Ding ans Rennen zu bringen war, den Workspace von 
Eclipse zu löschen, ein neues Projekt mit neuem Eclipse und frischer 
Plugin Installation zu verwenden. Zu gebrauchen waren nur die .c und .h 
Dateien.

Erwähnenswert auch ToDo's von Beiträgen weiter oben:
Windows->Preferences->C/C++->Language Mappings C-Header und C-File für 
GNU-C zuweisen, sowie Project->Properties->Discovery Options-> 'Clear 
discovered entries now'. Dann etwas warten, der Parser wirds schon 
richten.

Leider werden die Abhängigkeiten bei projekt internen Dateien immer noch 
nicht komplett aufgelöst ("Symbol ... could not be resolved), das liegt 
aber hoffentlich an meinen fehlerhaften Projekteinstellungen.

von CSpecker (Gast)


Lesenswert?

Vergessen: Mit Indigo SR2 und Plugin V2.4.0 neu aufgesetzt.

von Stefan (Gast)


Lesenswert?

> Diese müssen erneut
> für .c-Sourcefiles und .h-Headerfiles händisch vorgenommen werden. Dies
> erfolgt unter
> - Windows->Preferences->C/C++->Language Mappings
> - dort einmal C-header für GNU-C ...
> - .. und einmal C-source für GNU-C zuweisen

hat bei mir auch funktioniert; Includes werden nun erkannt und beim 
Drücken von F3 springt er zum file

von Alex (Gast)


Lesenswert?

Hi, ich hab heute ein Update von avr eclipse plugin 2.3.4 auf die 
Version 2.4 gemacht.
Leider kriegte ich damit auch die Fehlermeldung:
"make: write error: No such file or directory".
Ich hab alle Tipps die hier gegeben wurden ausprobiert. Von einfachen 
Umstellungen bis zur Kompletten neuen Installation von Eclipse, dem 
Plugin und den empfohlenen Einstellungen.
Alles ohne Erfolg :(

Ich hab noch folgende Fehler die zusätzlich auftauchen.
Wenn ich im Menü Projekt ->Properties->c/c++ build->
|Build Variabels|,
|Discovery Options|
oder andere Unterpunkte von (Projekt ->Properties->c/c++ build) 
auswählen will bekomme ich folgende Meldung.

„An error has occurred. See error log for more details.
Argument cannot be null“

Die include Befehle sind gelb unterstrichen und das Testprojekt das hier 
zum Test angeboten wird funktioniert auch nicht.

Gibt es mittlerweile eine Lösung für das Problem mit dem Avr Eclipse 
plugin 2.4?
Denn Ver. 2.3.4 steht ja nicht mehr zur Auswahl da die Ver. 2.4 
anscheinend die finale Version ist.

Zu meinem Sys.:
Ich benutze Win7 64bit mit wascana 1.0 (Eclipse Helios)
Ich hoffe ihr

von Alex (Gast)


Lesenswert?

Da fehlt wohl etwas am Ende^^
Ich hoffe ihr könnt mir helfen da ich keine Ahnung habe wie ich weiter 
vorgehen kann.

von Thomas H. (innot)


Lesenswert?

Hi Alex,

probier doch bitte mal das AVR Plugin in eine separates, frisches 
Eclpise Indigo (for C/C++ Developers) zu installieren und berichte ob 
das Problem weiter existiert.

Leider funktioniert AVR Eclipse 2.4 bei mir einfach nur, so dass ich die 
diversen berichteten Fehlermeldungen nicht nachvollziehen kann.

von Alex (Gast)


Lesenswert?

Danke für die Hilfe.
Für den Test hab ich das |Eclipse IDE for C/C++ Developers (includes 
Incubating components)| benutzt.
Wenn man ein neue entpacktes Eclipse Indigo verwendet. Das Avr Plugin 
v2.4 installiert. Arbeitet es ohne Probleme.

Leider hat das neue Eclipse Indigo c/c++ Packet irgendein Fehler und 
findet die C/C++ Bibliotheken nicht mehr richtig. Die paar Lösungen, die 
ich auf die Schnelle dafür gefunden habe hatten nicht funktioniert. Wer 
eine ordentliche Lösung dafür hat …

Da ich das Helios (Wascana) mit dem Avr Plugin 2.3.4 wieder zum Laufen 
gebracht habe, bleie ich aber vorerst dabei.
Soviel zu „Never change a running system“.

von Michael W. (mictronics) Benutzerseite


Lesenswert?

Das Problem mit der Semantic Fehlermeldung bei Eclipse Indigo läst sich 
auch folgendermaßen lösen:

Project -> Properties -> C/C++ General -> Path and Symbols -> Tab 
Symbols -> Language auswählen z.B. GNU C -> Add

Im "Add symbol" Dialog gibt man bei "Name" den AVR Typ an so wie er in 
der <avr/io.h> steht. z.B. für ATmega32 = "__AVR_ATmega32__" (ohne "")

Das Feld "Value" bleibt frei.

Vorraussetzung ist aber, das bei "Includes" der Pfad richtig angegeben 
ist, also z.B. "C:\WinAVR\avr\include"

Ich nutze nicht das AVR Plugin.

von mh555 (Gast)


Lesenswert?

Michael Wolf schrieb:
> Das Problem mit der Semantic Fehlermeldung bei Eclipse Indigo läst sich
> auch folgendermaßen lösen:

Cool. Kann ich unter Linux bestätigen.
Project -> Properties -> C/C++ General -> Paths and Symbols -> Tab 
Includes -> GNU C -> Add... -> /usr/liv/avr/include -> OK
Tab Symbols -> Add... -> Name:__AVR_ATmega16__ -> OK

von Feanor (Gast)


Lesenswert?

Vielleicht noch als Info:
Bei mir war das Symbol _AVR_ATtiny13_ bereits mit Wert 1 gesetzt. Wenn 
ich den Wert lösche und nur das Symbol definiere, ist das Problem mit 
den Fehlermeldungen behoben.

von Daniel D. (duesi)


Lesenswert?

Hallo,
das AVR-Plugin installieren hat geholfen !

System:
SUSE Linux 12.2, (64Bit)
Eclipse JUNO SDK4.2.1
Jetziges AVR Plugin: 2.4.0.201203041437

Bei mir lag der Fehler darin, dass fälschlicherweise mit "F3" in die 
iomx8.h, statt die iom1284p.h gesprungen wurde, obwohl die Defines 
korrekt standen !

Als Ergebnis war das Symbol PRR0 und PRR1 nicht auffindbar.
Kopf Hoch, die Programmiertools möchte auch gefplegt werden ;) !

Gruß Düsi

von Frank (Gast)


Lesenswert?

Hallo,
hatte auch das selbe Problem.
Geholfen hat, eclipse IDE for Java Developers von eclipse.org zu laden,
anstatt die ubuntu Paketverwaltung zu benutzen.
Also Version ist Juno service release.
Danach CDT 8.1.1 über eclipse installieren und anschließend das eclipse 
plugin.

von Raluca (Gast)


Lesenswert?

Hallo,
Ich hatte das selbe Problem. Meine Lösung war, dass ich das Projekt 
gespeichert und dan Build gedrückt habe und die
"Symbol 'X' could not be resolved" Fehlermeldung ist verschwunden.

Gruß
Raluca

von Heinz (Gast)


Lesenswert?

Ich habe hier ein paar der genannten Lösungsansätze probiert, wie das 
hinzufügen der _AVR_ATmega8_ Variable oder das ergänzen der 
C-Header/C-Source Verknüpfung. Beide haben zunächst das Problem gelöst, 
allerding musste ich feststellen, dass dies nur einmalig war. Sobald 
neue Änderungen vorgenommen werden, die eine Aktualisierung der 
Symbolverknüpfungen benötigen, erscheint das Problem wieder. Die 
Lösungsansätze lösen also nicht direkt das Problem, sondern sie stoßen 
Ecplipse nur an die Verknüpfungen neu zu prüfen.
Folglich funktioniert es auch unter
Project -> Properties -> C/C++ General -> Path and Symbols -> Tab
Symbols -> Language auswählen z.B. GNU C -> Add
Irgendetwas hinzuzufügen. beispielsweise abcdef. Danach auf apply und 
Rebild-bestätigen.

Letztendlich genau das, was bei dem clear-Lösungsvorschlag passieren 
sollte.
Allerdings funktioniert der bei mir gar nicht.

von Lars H. (hufnala)


Lesenswert?

Hi,

auch wenn ich den alten Thread hiermit aufwärme, aber ich hatte heute 
das selbe Problem unter Kepler und neuestem AVR-Plugin 2.4.1.

Bei mir war unter den Project Properties der ATMega 16 eingetragen. 
Dieser ist im Wizard bei mir auch als StartDevice angewählt. Eine 
Änderung beim Anlegen des Projekts wird anscheinend nicht übernommen. 
Nach Löschen der _AVR_ATmega16__ und einpflegen der __AVR_ATmega8_ und 
neu indexieren ist das ganze weg. Alles andere hat nichts gebracht.

Anm. Ich habe es auch über die Suche gefunden, bei einem einfachen 
Search auf PORTB wurde die mega16.io aus den Includes angezeigt. Das ist 
jetzt auch nicht mehr so.

Jetzt geht's aber feiern. Vielen Dank für das Super - Plugin und alles 
Gute für 2014

//hufnala

Opensuse 12.3  Eclipse Kepler  AVR Plug In 2.4.1

: Bearbeitet durch User
von sssss (Gast)


Lesenswert?

Wie umgeht Ihr das Problem mit neueren Versionen von AVRDUDE bzw der 
AVRlibC ?

von Achim K. (aks)


Lesenswert?

sssss schrieb:
> Wie umgeht Ihr das Problem mit neueren Versionen von AVRDUDE bzw der
> AVRlibC ?

Ich verstehe die Frage nicht. "Problem mit neueren Versionen von AVRDUDE 
und AVRLibC" ist einfach zu unspezifisch. Hast Du konkretere Probleme?

Ich benutze unter Ubuntu 12.04, 32bit:
Eclipse Kepler
AVR Plugin 2.4.1
avr8-gnu-toolchain-3.4.3.1072-linux.any.x86.tar.gz (avr-gcc 4.81, 
avr-libc 1.8.0, avr8-header 6.2.0.142)
avrdude 6.0.1
avarice 2.13
avr-gdb 7.6

Klar gibt es kleinere Unstimmigkeiten. DebugWire ist nicht "super 
stabil" aber tut bei mir doch besser als mit dem AStudio. Beim avrdude 
muss man manche MikroController (z.B. die A Versionen wie ATtiny261A) 
noch ins config eintragen, sonst meinen die AVR Plugins, dass avrdude 
diese nicht unterstützt. Aber im Großen und Ganzen sehe ich eher ein "es 
tut" wie es gibt "Probleme".

Bitte 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
Noch kein Account? Hier anmelden.