AVR GCC 3.2.0 -> WinAVR

> 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

p.s:

die heisst sh.exe und nicht bash.exe

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