Hallo allerseits,
ich habe gestern die AVR_Toolchain_3.0_149 mit avr-gcc 4.4.3 bei Atmel
runtegeladen. Habe sie einmal auf einem Windows XP Rechner installiert,
und einmal auf mein Notebook wo Windows 7 installiert ist.
Ich arbeite an einem Projekt mit ATMega644, mit dem WinAVR 20100110 ließ
sich das Project ohne Probleme comiplieren, durch entsprechendes
makefile.
Und das auf Windows XP, wie auch auf Win7.
Gestern nun habe ich WinAVR auf beiden Rechnern deinstalliert und dafür
die AVR Toolchain intalliert. Auf den Windows XP rechner funktioniert
alles wunderbar, aber unter Win7 erhalte nach aufruf von make folgende
Fehlermeldung:
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
ECHO ist ausgeschaltet (OFF).
-------- begin --------
avr-gcc (AVR_Toolchain_3.0_149) 4.4.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
"-f" kann syntaktisch an dieser Stelle nicht verarbeitet werden.
make: *** [sizebefore] Fehler 255
Ich habe die Umgebungsvariabelen bereits geprüft, dort ist auf beiden
Rechnern der richtige Pfad zur AVR Toolchain eingetragen, sonnst könnte
er make ja auch nicht finden....
Ich vermute das es irgendein Berechtigungsproblem ist, aber wo kann ich
eingreifen, damit make auch unter win7 richtig funktioniert?
Wie gesagt das gleiche Projekt, das gleiche makefile, unter windows Xp
ist alles gut, und unter win7 taucht das Problem auf.
Habe im Netz bereits gesucht, bin aber nicht fündig geworden...bin wohl
der einzige der dieses Problem hat. Oder habe mit falschen Begriffen
gegoogelt:-(
Vielen Dank für eure Hilfe!
Gruß
Stephan
Was unter einem deutschen Windows XP "c:\programme" ist, ist unter
Windows 7 immer "c:\program files".
Die Lokalisierung erfolgt im Explorer, der einem dafür wieder
"Programme" vorgaukelt.
Bei Aufrufen über Batchdateien oder auch Makefiles musst Du also auf
zwei Dinge achten:
a) auf den korrekten Pfad
b) der Pfad kann Leerzeichen enthalten
Wirklich portabel werden Batch- oder Makefiles, wenn darinnen nicht
hartcodiert "c:\programme" oder "c:\program files" steht, sondern
stattdessen die Environmentvariable ProgramFiles ausgewertet wird.
In einer Batchdatei geht das mit %ProgramFiles%, auch Make sollte auf
Environmentvariablen zugreifen können.
Achja nur als Hinweis, unter Win7 64-Bit will sich WinAVR in C:\Progam
Files (x86)" installieren, aber scheinbar mag GCC nicht die Klammern von
"(x86)".
Darum würde ich neben dem Tipp von Rufus auch daran denken (sofern x64
installiert)
Hallo Rufus,
danke für deinen Hinweis.
Ich installiere tools immer im Ordner "c:\USR\",
in meinem Fall also "c:\USR\proggen\avrtoolchain\bin"
dieser Pfad ist auch in den Umgebungsvariablen hardcodiert worden, vom
Installationsprogramm.
Aber vielleicht muss man die toolchain unter Windows 7 in den Ordner
"c:\program files" intallieren damit es funktioniert.
Das werde ich auch noch mal ausprobieren.
Gruß
Stephan
Stephan_II schrieb:> Aber vielleicht muss man die toolchain unter Windows 7 in den Ordner> "c:\program files" intallieren damit es funktioniert.
Nein, das kann das Problem nicht sein. Da geht dann was anderes schief.
Mir wäre übrigens der Gebrauch von "proggen" peinlich, aber auch das
kann hier nicht das Problem sein.
ach ja, ich habe windows 7 Starter, also ein 32 bit windows 7...
Damals hatte ich auch WinAVR unter "c:\USR\proggen\" intalliert.
Das funktionierte ja auch unter Windows 7 Starter...
Vielen Dank, bin für weitere hinweise dankbar..
Gruß
Stephan
Hallo,
ich habe die AVR_Toolchain_3.0_149 auf einem zweiten Windows 7 Rechner
installiert. Diesmal mit Windows 7 Professional 32 bit.
Bekomme dort genau die gleiche Fehlermeldung:
avr-gcc (AVR_Toolchain_3.0_149) 4.4.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
"-f" kann syntaktisch an dieser Stelle nicht verarbeitet werden.
make: *** [sizebefore] Fehler 255
Habe schon mit den Administratorrechten und Kompatibilitätsmodus
gespielt, hilft jedoch nichts?
Gruß
Stephan
Hallo,
noch ein paar feststellungen, ich bin aber kein makefile experte.
Das makefile das ich als Grundlage für alle meine Projekte nehme
wurde mit mfile generiert. Ich mache Anpassungen an andere Projekte
immer händisch(MCU, F_CPU, TARGET,SRC, u.s.w).
Wenn ich die folgenden Zeilen weiter unten im makefile rausnehme, dann
kann ich ersteinmal kompilieren.
sizebefore:
@if test -f $(TARGET).elf; then echo; echo $(MSG_SIZE_BEFORE);
$(ELFSIZE); \
2>/dev/null; echo; fi
sizeafter:
@if test -f $(TARGET).elf; then echo; echo $(MSG_SIZE_AFTER);
$(ELFSIZE); \
2>/dev/null; echo; fi
Es wird halt die Codegröße nicht mehr angezeigt.
Wenn ich allerdings einmal "make clean" ausführe, fängt er an zu
kompilieren und beschwert sich anschließend das er die object files
nicht mehr findet?
Kommt das irgendjemand bekannt vor?
Gruß
Stephan
Da das Problem weder mit Administratorrechten oder Kompatibilitätsmodi
zu tun hat, wird das Herumspielen damit auch nichts bringen. Man kann
make auch so konfigurieren, daß es ausgibt, was es macht.
Das sollte mit -d bzw. --debugging=a möglich sein.
Zu klären wäre natürlich noch, ob überhaupt das richtige make
verwendet wird; wenn auf dem Rechner noch irgendein anderer Compiler
installiert ist, der ebenfalls ein make mit sich bringt, und der sein
bin-Verzeichnis in %PATH% einträgt, dann kann es sein, daß dessen make
verwendet wird.
Versuch mal ein "which make.exe" aus einem Kommandofenster, dann weisst
du, ob es das richtige make ist.
Das Problem scheint aber mit dem Befehl "test" aufzutreten. Was sagt
denn ein "which test.exe"?
Oliver
Also ein make -v ergibt folgende Rückmeldung:
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i386-pc-mingw32
Die Version entspricht genau der im AVRtoolchain.
Also wenn ich make Ausführe, werden keine .o files oder irgendetwas
geschrieben. Deshalb findet er später auch nicht die .o files
Vieleicht ein Problem mit den Schreibrechten?
Bei WinAVR 20100110 funktionierte das noch....
ein kleiner Ausschnitt aus make -p
# GNU Make 3.81
# Copyright (C) 2006 Free Software Foundation, Inc.
# This is free software; see the source for copying conditions.
# There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
# This program built for i386-pc-mingw32
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
ECHO ist ausgeschaltet (OFF).
-------- begin --------
avr-gcc (AVR_Toolchain_3.0_149) 4.4.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
ECHO ist ausgeschaltet (OFF).
Compiling C: main.c
avr-gcc -c -mmcu=atmega644 -I. -gdwarf-2 -DF_CPU=20000000UL -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=/main.lst -std=gnu99
-ffunction-sections -fdata-sections -Wundef -MMD -MP -MF .dep/main.o.d
main.c -o /main.o
main.c: In function 'main':
main.c:78: warning: passing argument 2 of 'read_string_flash' discards
qualifiers from pointer target type
include/project_func.h:101: note: expected 'char *' but argument is of
type 'volatile char *'
main.c:175: warning: passing argument 1 of 'execute' discards qualifiers
from pointer target type
include/comando_routines.h:26: note: expected 'u8 *' but argument is of
type 'volatile char *'
main.c:180: warning: passing argument 2 of 'read_string_flash' discards
qualifiers from pointer target type
include/project_func.h:101: note: expected 'char *' but argument is of
type 'volatile char *'
main.c:183: warning: passing argument 2 of 'read_string_flash' discards
qualifiers from pointer target type
include/project_func.h:101: note: expected 'char *' but argument is of
type 'volatile char *'
main.c:186: warning: passing argument 2 of 'read_string_flash' discards
qualifiers from pointer target type
include/project_func.h:101: note: expected 'char *' but argument is of
type 'volatile char *'
main.c:189: warning: passing argument 2 of 'read_string_flash' discards
qualifiers from pointer target type
include/project_func.h:101: note: expected 'char *' but argument is of
type 'volatile char *'
main.c:201: warning: passing argument 2 of 'read_string_flash' discards
qualifiers from pointer target type
include/project_func.h:101: note: expected 'char *' but argument is of
type 'volatile char *'
main.c: At top level:
main.c:295: fatal error: opening dependency file .dep/main.o.d: No such
file or directory
compilation terminated.
make: *** [/main.o] Fehler 1
Unter Windows XP funktioniert alles, und ich bekomme auch nicht die
Ausgabe: ECHO ist ausgeschaltet (OFF).
Gruß
Stephan
Gruß
Stephan
Stephan_II schrieb:> main.c:295: fatal error: opening dependency file .dep/main.o.d: No such> file or directory> compilation terminated.
Doch ein Rechte-Problem? Wenn make das Verzeichnis dep nicht anlegen
darf, dann gehts nicht.
Oliver
Hallo,
habe nun ein Ordner Namens "dep" per Hand angelegt, und das makefile
entsprechend angepasst. und nun geht es..
Es ist also ein Problem mit den Schreibrechten unter Win 7.
In den Ordner werden dann wie gehabt ganzen dependency files angelegt,
den Ordner selbst kann make nicht aber anlegen???
Wenn ich make als Administrator ausführe ändert das aber auch nichts.
Jedesmal wenn wenn ich make clean ausgeführe, löscht er ja den ganzen
Ordner
und das Problem fängt von vorne an. ;-)
Worauf ich noch Verzichten muss ist die Ausgabe der Codegröße, da
bekomme
ich erst zwei warnings:
makefile:449: Warnung: Die Befehle f³r das Ziel ╗sizeafter½ werden
³berschrieben
makefile:445: Warnung: Alte Befehle f³r das Ziel ╗sizeafter½ werden
ignoriert
und dann einen Fehler:
"main.elf" kann syntaktisch an dieser Stelle nicht verarbeitet werden.
make: *** [sizebefore] Fehler 255
Aber ich habe notfalls noch Windows XP, da klappt alles wie mit WinAVR.
Vielen Dank für die Hilfe, sehr gutes Forum!
Gruß
Stephan
> Das System kann den angegebenen Pfad nicht finden.> Das System kann den angegebenen Pfad nicht finden.> ECHO ist ausgeschaltet (OFF).
Das sieht aus wie Ausgaben einer aufgerufenen Batchdatei, die
irgendwelche Dinge tun soll.
Und was geschieht, wenn make -d bzw. make --debugging=a aufgerufen wird?
An der Stelle im makefile wo Codegröße berechnet wird, also
sizebefore:
@if test -f $(TARGET).elf; then echo; echo $(MSG_SIZE_BEFORE);
$(ELFSIZE); \
2>/dev/null; echo; fi
sizeafter:
@if test -f $(TARGET).elf; then echo; echo $(MSG_SIZE_AFTER);
$(ELFSIZE); \
2>/dev/null; echo; fi
hat er offenbar ein Problem mit test???
Muss wohl auch irgendwo erzeugt werden?
Gruß
Stephan
Das System kann den angegebenen Pfad nicht finden.
4
Main thread handle = 0x000000d8
Interessant ist, was in dieser Batchdatei drinsteht und warum der Aufruf
dieser Batchdatei fehlschlägt.
Du könntest Deine %TEMP%-Variable mal auf ein definiertes Verzeichnis
zeigen lassen (beispielsweise c:\temp), dann ist es einfacher, die darin
befindlichen Dinge zu finden.
Hallo Rufus,
habe ich mal ausprobiert. Er erstellt die Batchdateien erst garnicht...
Immer noch die gleiche Fehlermeldung:
This program built for i386-pc-mingw32
╗make½-Steuerdateien werden gelesen...
╗make½-Steuerdatei ╗makefile½ wird gelesen...
Erstelle temporõre Stapelverarbeitungsdatei D:\temps\make6876-1.bat
CreateProcess(D:\temps\make6876-1.bat,D:\temps\make6876-1.bat,...)
Das System kann den angegebenen Pfad nicht finden.
Main thread handle = 0x000000d8
L÷sche temporõre Stapelverarbeitungsdatei D:\temps\make6876-1.bat
Erstelle temporõre Stapelverarbeitungsdatei D:\temps\make6876-1.bat
CreateProcess(D:\temps\make6876-1.bat,D:\temps\make6876-1.bat,...)
Das System kann den angegebenen Pfad nicht finden.
Gruß
Stephan
Das Ganze kann auch ein Problem mit der verwendeten Shell sein. Dazu
steht einiges in der Dokumenation von make (Auswahl der Shell, Windows
"shell" (cmd.exe/comspec), SHELL Variable). Bei WinAVR und wenn richtig
gesehen auch beim Nachfolger kommt eine "Bash für Windows" aus
msys/mingw mit, wenn diese von Make nicht gefunden und genutzt wird,
erklärt das zumindest die anfänglich beschriebenen Fehler bei Prüfung
auf vorhandene elf-Datei.
Hallo,
es gibt interressante Neuigkeiten, das Problem ist ersteinmal gelöst!
Es lag an der shell sh.exe. Auf mein Windows 7 Rechner konnte ich keine
sh.exe finden. Anders auf meinem XP Rechner, dort habe ich auch noch
WinArm installiert, und dort in "utils\bin" ist auch ein sh.exe zu
finden.
In der AVRtoolchain von Atmel hingegen nicht.
Und es zeigt eine Umgebungsvariable direkt dorthin, also zu den WinARM
bin utils....
wenn ich nun das avr make aufrufe, so ruft es das WinArm sh.exe auf, und
es funktioniert einwandfrei.
Habe nun auf meinem Windows 7 Notebook ebenfalls WinArm installiert, und
siehe da es geht. Das was bei der make -d log textdatei gefehlt hat sind
die sh.exe aufrufe. Diese sind jetzt zu sehen.
Habe nocheinmal make -d ausgeführt und das logfile hier angehängt.
deswegen hat es auf dem XP Rechner funktioniert weil dort schon WinArm
installiert war, und damit ein sh.exe vorhanden war....
Bin ich der einzige der Atmels AVRtoolchain auf eien Win7 Rechner
installiert hat??? (Es ist ja praktisch die Fortsetzung von WinAVR)
Ach ja, da ich auf Win7 Rechner, WinArm später installiert habe, musste
ich das make von WinArm umbenennen da sonst dieses aufgerufenb würde.
Das hat andere Fehler verursacht, und es hat die Version 3.80.
Habe es arm-make umbennant, damit das richtige make von AVRtoolchain
aufgerufen wird....
Hoffe damit ist auch anderen geholfen!
Viele Grüße
Stephan
Hallo Martin,
das erklärt das fehlen von sh.exe. Muss ich mich ersteinmal einlesen,
danke für den Hinweis. Hoffe ich muss das makefile dadurch nicht völlig
umbauen, davon hab ich keine große Ahnung. Meine makevorlagen kommen
ursprünglich von mfile...
im makefile hatte ich auch schonmal versucht SHELL = sh durch
SHELL = cmd zu ersetzen
ging natürlich nicht..
Gruß
Stephan
Hallo,
also die sh.exe ist doch die "bash for windows"?
Es fehlen in Atmels AVR Toolchain einfach die utils\bin.
In WinAVR sind sie vorhanden.
Wenn ich das richtig sehe....so nutzte ich halt die von WinArm.
Ich hatte aber heute noch das bekannte Problem, wie in
Beitrag "Installation AVR Studio"
beschrieben und gelöst.
Die sh.exe von WinArm ist ja von 2006....
Gruß
Stephan
Im WinARM habe ich allermeist eine uralte ZSH für Windows beigelegt, die
ich irgendwo im Netz gefunden habe. Aktuelle Version habe ich länger
gesucht aber nie gefunden. Vorteil dieser ZSH/sh.exe ist, dass sie keine
zusätzliche DLL benötigt (etwas weniger Glut für die "DLL-Hell"). Bei
WinAVR ist/war die Shell aus dem msys/mingw-Projekt dabei. Die ist
meines Wissens im Grunde die BASH aus Cygwin, die minimal angepasst
wurde und auch eine DLL-Abhängigkeit mitbringt.
Inzwischen habe ich in meiner Makefile-Vorlage eine Fallunterscheidung,
die versucht, MS-Win zu erkennen. Falls MS Win erkannt: shell aus
comspec und entsprechende Parameter/Optionen, falls nicht die
default-shell. Habe ich unter WinXP relativ häufig im Einsatz und
getestet, unter Linux wenig und unter Win7 noch nicht getestet. Ein
solches Makefile findet sich unter anderem im zip-Archiv zu dieser
Beispielanwendung:
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html#chanfat_lpc_cm3
. Ist zwar für arm-eabi GNU-Cross-Toolchain, sollte sich aber ohne viel
Aufwand für avr-gcc/binutils anpassen lassen.
Nur mal so am Rande gefragt: Warum ist da überhaupt eine andere Shell
als die windows-eigene Standardshell erforderlich? Wofür wird da von
make überhaupt eine Shell benötigt?
Rufus Τ. Firefly schrieb:> Wofür wird da von make überhaupt eine Shell benötigt?
Die im Makefile angegebenen auszuführenden Kommandos werden von make per
Shell ausgeführt.
Dadurch sind dann auch solche Sachen möglich:
1
clean:
2
for file in *.bak; do echo "Removing $file"; rm $file; done
Ah. Das aber könnte man auch mit den unter dem Wirtsbetriebssystem
üblichen Mechanismen tun, statt eine Shell eines anderen
Betriebssystemes verwenden zu müssen.
Stefan Ernst schrieb:> clean:> for file in *.bak; do echo "Removing $file"; rm $file; done
Mein OS Abstraction Layer definiert Funktionen für die entsprechende
Plattform. In diesem Fall würde das etwa so aussehen:
Hallo,
mit dem Hinweis von Martin Thomas gestern, habe ich mein makefile
nun so modifiziert das es nun mit der cmd funktioniert.
Brauche das sh.exe nicht mehr.
Es kompiliert komplett durch...habe das makefile einmal hier angehängt
Ein Problem habe ich aber noch, das er bei sizebefore,sizeafter die
folgende Fehlermeldung ausgibt:
"-f" kann syntaktisch an dieser Stelle nicht verarbeitet werden.
make: *** [sizebefore] Fehler 255
mit der sh.exe funktioniert das aber einwandfrei. Ich kann mit in
der cmd also die Codegröße nicht anzeigen lassen, mit sh.exe
funktioniert sizebefore,sizeafter aber einwnadfrei.
Vielleicht weiß jemand von euch Rat?
Gruß
Stephan
Ersatz für "if test -f dateiname" dürfte "if exist dateiname" sein. Man
könnte aber auch einfach sizebefore entfernen (so nützlich ist das m.M.
nach nicht), bei sizeafter auf den "Existenztest" verzichten und direkt
avr-size nebst Parametern aufrufen. Falls die elf-Datei nicht vorhanden
ist, ist ohnehin vorher schon etwas schief gelaufen. Damit bliebe das
Makefile auch mit "cmd.exe" und "sh.exe" ohne Fallunterscheidung
anwendbar.
Hallo,
es muß auch hier mit der shell zu tun haben...wenn ich schreibe:
.
.
HEXSIZE = $(SIZE) -A --target=$(FORMAT) $(TARGET).hex
ELFSIZE = $(SIZE) -A --mcu=$(MCU) --format=avr $(TARGET).elf
sizeafter:
@echo $(MSG_SIZE_BEFORE); $(shell $(ELFSIZE)
.
.
dan bekomme ich schlecht formatiert folgende Ausgabe:
Size before: AVR Memory Usage ---------------- Device: atmega644
Program: 2994 bytes (4.6 185 bytes (4.5 18 bytes (0.9
Full) (.eeprom)
Jede if Abfage in deisem bereich fällt immer negativ aus und trozdem
für er den Code nach dem then aus?!?? Beispiel:
sizebefore:
@if exist [$(TARGET).elf] then echo; echo $(MSG_SIZE_BEFORE); $(shell
$(ELFSIZE))
führt zu folgender Fehlermeldung:
avr-size: 'main.elf': No such file
Naja, so kann man wenigstens die resultierende Codgröße sehen.
Ach ja,
Es ist natürlch:
SIZE = avr-size
Gebe per Hand in die cmd- shell "avr-size --mcu=atmega644 --format=avr
main.elf" ein ist das wie gewohnt formatiert:
AVR Memory Usage
----------------
Device: atmega644
Program: 2994 bytes (4.6% Full)
(.text + .data + .bootloader)
Data: 185 bytes (4.5% Full)
(.data + .bss + .noinit)
EEPROM: 18 bytes (0.9% Full)
(.eeprom)
Die Eingabe entspricht ja genau der Zeile im makefile:
ELFSIZE = $(SIZE) --mcu=$(MCU) --format=avr $(TARGET).elf
Gruß
Stephan
Hallo,
ich habe das gleiche Problem nur mit der aktuellen avr gnu toochain
3.2.3
Aber es liegt nicht an Windows XP oder Windows 7.
Ich habe bei beiden System die Probleme.
Kennt jemand mitlerweile eine Lösung.
Ich bin nämlich umgestiegen vin WinAVR zu Toolchain 3.2.3.
Leider kann man beide nicht parallel auf dem System haben.