Forum: Compiler & IDEs Problem mit make unter win7


von Stephan_II (Gast)


Lesenswert?

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

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

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.

von Timmo H. (masterfx)


Lesenswert?

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)

von Stephan_II (Gast)


Lesenswert?

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

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

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.

von Stephan_II (Gast)


Lesenswert?

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

von Stephan_II (Gast)


Lesenswert?

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

von Stephan_II (Gast)


Lesenswert?

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

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

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.

von Oliver (Gast)


Lesenswert?

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

von Stephan_II (Gast)


Angehängte Dateien:

Lesenswert?

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

von Oliver (Gast)


Lesenswert?

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

von Stephan_II (Gast)


Lesenswert?

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

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

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

von Stephan_II (Gast)


Lesenswert?

Hallo Rufus,

wenn du 3 posting höher schaust ist eine make_log.txt angehängt.
Darin findest du alle ausgaben wenn ich make -d ausführe.

Gruß
  stephan

von Stephan_II (Gast)


Angehängte Dateien:

Lesenswert?

OK,

war die falsche make option, hier nun mit make -d

von Stephan_II (Gast)


Lesenswert?

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

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

1
Erstelle temporõre Stapelverarbeitungsdatei C:\Users\Gebauer\AppData\Local\Temp\make8408-1.bat
2
CreateProcess(C:\Users\Gebauer\AppData\Local\Temp\make8408-1.bat,C:\Users\Gebauer\AppData\Local\Temp\make8408-1.bat,...)
3
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.

von Stephan_II (Gast)


Lesenswert?

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

von Martin T. (mthomas) (Moderator) Benutzerseite


Lesenswert?

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.

von Stephan_II (Gast)


Angehängte Dateien:

Lesenswert?

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

von Stephan_II (Gast)


Lesenswert?

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

von Stephan_II (Gast)


Lesenswert?

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

von Martin T. (mthomas) (Moderator) Benutzerseite


Lesenswert?

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.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

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?

von Stefan E. (sternst)


Lesenswert?

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

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

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.

von Marcus H. (mharnisch) Benutzerseite


Lesenswert?

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:
1
ifeq ($(OS),Windows_NT)
2
  RM_F    = del /q $(subst /,\,$(1))
3
  CMDSEP := &&
4
  NOP    := shift
5
else
6
  RM_F    = rm -f $(1)
7
  CMDSEP := ;
8
  NOP    :=
9
endif
10
11
.PHONY: clean
12
clean:
13
  $(foreach 1, $(wildcard *.bak), $(call RM_F) $(CMDSEP)) $(NOP)

von Stephan_II (Gast)


Angehängte Dateien:

Lesenswert?

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

von Martin T. (mthomas) (Moderator) Benutzerseite


Lesenswert?

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.

von Stephan_II (Gast)


Lesenswert?

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.

von Stephan_II (Gast)


Lesenswert?

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

von mthomas (Gast)


Lesenswert?

Ausgabe sieht dannach aus, also würde das %-Zeichen als Steuerzeichen 
interpretiert werden. Würde testweise einfach erstmal
1
sizeafter:
2
    @if exist [$(TARGET).elf] then echo; echo $(MSG_SIZE_BEFORE); $(shell $(ELFSIZE))
durch
1
sizeafter:
2
    $(SIZE) --mcu=$(MCU) --format=avr $(TARGET).elf
ersetzen.
Man kann in einem Makefile ein - (Minus) vor den Befehl schreiben, dann 
bricht Make nicht ab, falls avr-size einen Fehlercode zurückgibt:
1
sizeafter:
2
    -$(SIZE) --mcu=$(MCU) --format=avr $(TARGET).elf
Einrückungen jeweils mit TAB (nicht mit Leerzeichen).

von Jens A. (micro)


Lesenswert?

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.

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
Noch kein Account? Hier anmelden.