Die derzeit etwas ruhige Phase in unserer Firma, wollte ich mal dazu nutzen WinAVR zu nutzen und den veralteten AVR GCC über Bord zu werfen. Gesagt, getan, jedoch habe ich einige Probleme diesen ans laufen zu bekommen in meinem UltraEdit. Diese Variablen habe ich natürlich entsprechend abgeändert auf: set AVR=D:/avrgcc set CC=avr-gcc set PATH=D:\avrgcc\utils\bin;%path% Hab WinAVR in D:\avrgcc installiert. Beim Compilieren des Demo-Examples oder des TWI-Tests bekomme ich dann aber folgenden (mir nichts sagenden) Error: avr-gcc -O -g -Wall -ffreestanding -mmcu=atmega128 -c -o twitest.o twitest.c process_begin: CreateProcess((null), avr-gcc -O -g -Wall -ffreestanding -mmcu=atmega128 -c -o twitest.o twitest.c, ...) failed. make (e=2): Das System kann die angegebene Datei nicht finden. make: *** [twitest.o] Error 2 Welche Datei ist denn gemeint, die WinAVR nicht finden kann? Am Makefile scheints jedenfalls nicht zu liegen, denn ich glaube kaum das die Beispielmakefiles falsch sind ;) @Andreas Schwarz: Kannst du nichtmal ne Rubrik WinAVR machen mit ner Installationsanleitung um den mit AVR Studio und UltraEdit ans laufen zu bekommen? Probleme mit dem WinAVR scheints nämlich häufiger zu geben, aber das heißt ja nur das ich nicht der einzige Dummy hier bin ;) Gruß Ben
> Welche Datei ist denn gemeint, die WinAVR nicht finden kann? IMHO die Shell (bash, oder was immer da für eine Unix-Shell dabei sein sollte). Ich glaube mich zu erinnern, daß Eric diese in seiner ersten WinAVR-Version vergessen hatte beizufügen (man kann aber die alte von avrfreaks nehmen), sollte aber inzwischen behoben sein.
Also in der Tat ist keine bash.exe vorhanden, aber auch als ich die von avrfreaks genommen habe kommt der selbe Fehler, d.h. das kanns eigentlich nicht sein. Habe im übrigen die aktuellste WinAVR-Version (heute morgen frisch runtergeladen von Sourceforge).
lösche die umgebungsvariablen... die werden nicht benötigt.. setzte nur folgenden path: d:\avrgcc\bin d:\avrgcc\utils\bin schau auch mal in readme.txt im winavr ordner
Also hab WinAVR nocheinmal deinstalliert und im Ordner "WinAVR" auf D: neuinstalliert. Die 3 obigen Zeilen hab ich aus der autoexec.bat gelöscht und jetzt D:\WinAVR\bin und D:\WinAVR\utils\bin als Umgebungsvariable (Path) gesetzt. Die ausgeführte make.exe ist nun auf jedenfall diejenige aus dem WinAVR\utils\bin-Ordner. Leider führt das ganze nach wie vor zu diesem Fehler: avr-gcc -g -Wall -O2 -mmcu=at90s2313 -c -o demo.o demo.c process_begin: CreateProcess((null), avr-gcc -g -Wall -O2 -mmcu=at90s2313 -c -o demo.o demo.c, ...) failed. make (e=2): Das System kann die angegebene Datei nicht finden. make: *** [demo.o] Error 2 Achja: Ich verwende WinNT 4 SP6 (Falls das irgendwen interessieren sollte ;))
Achja nebenbei noch erwähnt: Der Befehl avr-gcc -g -Wall -O2 -mmcu=atmega16 -c -o logpro.o logpro.c wird anstandslos abgearbeitet, d.h. compilieren tut er ja schonmal.
folge mal dem link..dort findest du eine projektx.zip im anhang eines posts. versuch das mal bitte und sag bescheid http://www.mikrocontroller.net/forum/read-2-19534.html
Habs in den Ordner d:\WinAVR\doc\examples\projectx\ kopiert, anschließend make gemacht. Ergebnis siehe Bildanhang. Erstellt wird allerdings eine projectx.d und eine testit.d.
Kommando zurück, hatte vergessen im Makefile die DIRAVR Variable umzustellen, jetzt klappts in der Konsole.. in UltraEdit leider noch nicht (selber Fehler wie vorher).
und auch das ist jetzt erledigt, hab in meine autoexec.bat folgendes reingeschrieben: set AVR=D:/WinAVR set CC=avr-gcc set PATH=D:\WinAVR\bin;D:\WinAVR\utils\bin;%path% Vielen Dank an alle die geholfen haben für die Problemfindung :) Kleine Frage noch nebenbei: Wofür ist das CC=avr-gcc? Der Name des C-Compilers?
Noch eine Frage: Habe ein altes Projekt neu compiliert, jetzt finde ich folgende Warnings und kann damit nicht wirklich was anfangen, da keine Zuordnung zu einer Quellcodezeile erfolgt: -------- begin -------- [...] avr-objdump -h -S logpro.elf > logpro.lss objtool loadelf logpro.elf mapfile logpro.map writecof logpro.cof WARNING - symbol 'x' could not be resolved to a type - using VOID. WARNING - symbol 'x' could not be resolved to a type - using VOID. WARNING - symbol 'x' could not be resolved to a type - using VOID. WARNING - symbol 'x' could not be resolved to a type - using VOID. WARNING - symbol 'x' could not be resolved to a type - using VOID. Size after: text data bss dec hex filename 0 7450 0 7450 1d1a logpro.hex -------- end -------- Irgendwelche Hinweise?
Bezüglich Deines "Error Logs": besser als ein Bild sind allemal tausend Worte. :-) WinNT (und darüber) kann ganz prima Unix-EA-Umlenkungen in der Shell, Verzeihung, im Kommandointerpreter. Einfach make ... 2> logfile ...und die Fehlermeldungen stehen danach in "logfile". Wenn man beides umlenken will (stdout & stderr): make ... > logfile 2>&1 Ja, die Variable CC beschreibt den zu verwendenden C-Compiler. Voreinstellung ist "cc". Kann man auch im Makefile setzen (dort nennt sich das dann offiziell nicht "Variable", sondern "Macro", was auf der linken Seite des Gleichheitszeichens steht). Mit dieser Variante hier macht man Gebrauch von einer Eigenschaft von make, daß Environment-Variablen die eingebauten Makefile- Macros überschreiben können. Die Warnungen besagen, daß objtool nicht in der Lage war, das Symbol "x" einem Datentyp zuzuordnen. Kann ein Bug in objtool sein, kann auch sein, daß im Rahmen des AVR COFF Formates diese Zuordnung gar nicht möglich ist. Die Möglichkeiten, Debug- Informationen in COFF unterzubringen, sind nicht gerade rosig...
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.