AVR GCC 3.2.0 -> WinAVR

[Benno Müller (Gast)]

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

[Joerg Wunsch (Gast)]

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

[Benno Müller (Gast)]

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

[BAB (Kai K.) (Gast)]

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

[Benno Müller (Gast)]

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 ;))

[Benno Müller (Gast)]

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.

[BAB (Kai K.) (Gast)]

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

[BAB (Kai K.) (Gast)]

p.s:

die heisst sh.exe und nicht bash.exe

[Benno Müller (Gast)]

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.

[Benno Müller (Gast)]

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

[Benno Müller (Gast)]

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?

[Benno Müller (Gast)]

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?

[Joerg Wunsch (Gast)]

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