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
intmain(void)
4
{
5
DDRC=0xff;//error 1
6
PORTC=0xff;//error 2
7
while(1);
8
9
return0;
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.
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.
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
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.
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!
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.
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.
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.
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.
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.
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
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.
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!
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?
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 :/
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
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)
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
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)
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"
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?
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.
Hi,
also bei mir geht es nicht ohne die explizite Nennung der passenden
io-header-Datei.
1
intmain(void)
2
{
3
uint8_ti;
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
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.
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!!!
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
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
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
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
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
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!;)
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.
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
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.
> 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
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
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.
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“.
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.
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
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.
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
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.
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
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.
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
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".