Hi, da hab ich nun endlich mal Zeit mich mit dem AVR-GCC zu beschäftigen und nun das: Ich habe, wie auf dieser Seite beschrieben, alle notwendigen Daten heruntergeladen und entpackt. Selbstverständlich habe ich in der Autoexec.bat (Windoof 98) die notwendigen Einträge gemacht und gebootet. Beim Compilieren der vorgestellten Testprogramme bekomme ich immer folgende Fehlermeldung: *** C:\avrgcc\gcctest\gcctest1>make avr-gcc -c -g -Os -Wall -Wstrict-prototypes -Wa,-ahlms=gcctest1.lst -mmcu=at90s4433 -I. gcctest1.c -o gcctest1.o avr-gcc gcctest1.o -Wl,-Map=gcctest1.map,--cref -mmcu=at90s4433 -o gcctest1.elf avr-objcopy -O avrobj -R .eeprom gcctest1.elf gcctest1.obj avr-objcopy -O ihex -R .eeprom gcctest1.elf gcctest1.hex elfcoff gcctest1.elf coff gcctest1.cof gcctest1.sym Ended cp coff/gcctest1.cof . cp coff/* ./AVRGCC/BIN/cp: `coff/gcctest1.c' and `./gcctest1.c' are the same file C:\AVRGCC\BIN\MAKE.EXE: *** [gcctest1.cof] Error 256 C:\avrgcc\gcctest\gcctest1> *** Es werden folgende Dateien erzeugt: *** C:\avrgcc\gcctest\gcctest1>dir Volume in drive C is HARDDISK Volume Serial Number is 3891-601B Directory of C:\avrgcc\gcctest\gcctest1 . <DIR> 28.06.02 0:53 . .. <DIR> 28.06.02 0:53 .. GCCTEST1 C 1.193 26.01.00 18:20 gcctest1.c GCCTEST1 O 2.872 04.08.02 17:48 gcctest1.o MAKEFILE 958 04.08.02 17:31 makefile GCCTEST1 LST 8.749 04.08.02 17:48 gcctest1.lst GCCTEST1 MAP 10.198 04.08.02 17:48 gcctest1.map GCCTEST1 ELF 4.942 04.08.02 17:48 gcctest1.elf GCCTEST1 OBJ 660 04.08.02 17:48 gcctest1.obj GCCTEST1 HEX 373 04.08.02 17:48 gcctest1.hex COFF <DIR> 04.08.02 17:48 coff GCCTEST1 COF 2.101 04.08.02 17:48 gcctest1.cof GCCTEST1 SYM 51.059 04.08.02 17:48 gcctest1.sym 10 file(s) 83.105 bytes 3 dir(s) 4.793.89 MB free *** Wo ist das beschriebene ROM-File? und wo ist die ASM-Datei ? Frage: Ist das nun OK so ? Ist die .hex-Datei nun mein "Programm" ? Ich bin im Moment etwas ratlos... Also: Kann jemand bitte Licht in das Dunkel bringen ... Gruß UBoot-Stocki
> Wo ist das beschriebene ROM-File? und wo ist die ASM-Datei ? Ein ROM-File wird nicht produziert. Eine ASM-Datei gibt es eigentlich auch nicht, aber wenn Du mal einen Blick in die gcctest1.lst wirfst, siehst Du den C Code zusammen mit den daraus erzeugten Assemblerbefehlen. Dort findest Du sozusagen die Information, wie der Compiler den C-Code umsetzt. Frage: Ist das nun OK so ? Ist die .hex-Datei nun mein "Programm" ? Nun ja, wieso cp diesen Fehler bringt, weiss ich nicht genau. Scheinbar hast Du mehrfach die selbe Source compiliert und daher sind die beiden Dateien gleich und cp meckert das an. Ist aber kein Problem. Das Ergebnis ist die .hex Datei, die kann nun direkt in den AVR geladen werden (z.B. mit PonyProg o.ä.). Gruss, Peter
Hallo Peter, .hex und .lst sind nun klar. Der Fehler kommt nach wie vor noch. Selbstredend habe ich alle Dateien in den Test-Verzeichnissen vor dem (Re-)Compilieren gelöscht. Wenn man das vergisst, merkt MAKE das und compiliert NICHT neu. Frage: Was soll den cp eigenlich machen? Aus dem was cp --help ausspuckt werde ich nicht schlau ... Kann es sein, daß in meinem (Lieferumfang-)Makefile zweimal "cp" ausgeführt wird (siehe output von make im ersten Posting) ? Kan das der Grund sein ? Wozu ´braucht man das ? Gruß UBoot-Stocki
Also um das cp brauchst Du dich eigentlich garnicht zu kümmern. Bekanntlich kommt der gcc aus der Linux-Welt und um ihn bequem auf die Windows-Welt zu portieren, hat man einige Unix Kommandos mit hinübergenommen. cp ist nur der copy-Befehl des Linux, mehr nicht. Und der merkt wohl, dass man eine Datei sozusagen mit sich selbst oder mit einer identischen Kopie überschreiben will und meckert herum. Wie schon gesagt, wenn ein .hex-file erscheint hat die Kompilation geklappt. Bei allen weiteren Problemen liegt die Ursache dann ca. 70cm vor dem Bildschirm ;-) mit :-) Gruss, Peter
Hi, das mir gcc und Linux ist schon klar - das mit den 70cm auch ;-) Da ich aber nichts anderes gemacht habe, als "installiert", müßte dieses Problem bei anderen ja auch schon aufgetreten sein ? Ist halt unschön ... Wie kann man es den abstellen ? Zu welchem Zweck wird denn da kopiert ? Gruß UBoot-Stocki
Also zunächst mal, das mit der Kopiererei ist schon notwendig. Was kopiert wird, siehst Du ja in der Ausgabe. Es wird z.B. die .cof Datei, die die Debugging-Info entält, vom Arbeitsverzeichnis ./coff in Dein Arbeitsverzeichnis kopiert und noch ein paar andere Dinge. Ich nehme mal stark an, das Problem bei dir liegt am Makefile. Welche Version des avrgcc verwendest Du denn und woher stammt das Makefile? Hast Du eventuell eine neue Version des avrgcc und alte Versionen der gcctest-Dateien? Im Unterverzeichnis avrgcc/bin findest Du eine Windows-Hilfedatei zu make, schau dir die mal genau an und überprüfe mal das Makefile, vielleicht klärt sich dann ja einiges. Es gibt übrigens eine recht neue und verbesserte Version des avrgcc 3.02 bei www.avrfreaks.net zum download. Hast du diese schon? Gruss, Peter
> Selbstredend habe ich alle Dateien in den Test-Verzeichnissen vor dem
(Re-)Compilieren gelöscht.
Also das brauchst Du nicht zu tun! Wenn die Dinge richtig laufen, stellt
avrgcc das selbst fest wenn sich etwas geändert hat und er macht
automatisch nur die Teile neu, bei denen das notwendig ist. Vielleicht
liegt ja darin dein Problem begraben!
Gruss,
Peter
Hallo,
vielen Dank für Euere Tipps. Ich habe die Version 3.02 installiert. Es
trat ebenfalls die oben beschriebene Problematik auf. Danach habe ich
ein wenig rumgestöbert und final die folgenden Zeilen in der Datei
..\avrfreaks\avr_make
%.cof: %.elf
$(ELFCOF) $< $(OUT) $@ $*.sym
$(CP) $(OUT)/$@ .
$(CP) $(OUT)/* .
# $(CP) $(OUT)/*.sym .
# $(CP) $(OUT)/*.S .
auf folgende Zeilen abgeändert
%.cof: %.elf
$(ELFCOF) $< $(OUT) $@ $*.sym
# $(CP) $(OUT)/$@ .
# $(CP) $(OUT)/* .
$(CP) $(OUT)\\*sym .
$(CP) $(OUT)\\*cof .
Es werden somit nur die .cof und .sym-Dateien aus dem coff-Verzeichnis
wieder in das darunterliegende Kopiert.
Wie folgender Output zeigt, ist der Fehler nun weg:
C:\avrgcc\gcctest\gcctest1>make
avr-gcc -c -g -Os -Wall -Wstrict-prototypes -Wa,-ahlms=gcctest1.lst
-mmcu=at90s4433 -I. gcctest1.c -o gcctest1.o
avr-gcc gcctest1.o -Wl,-Map=gcctest1.map,--cref -mmcu=at90s4433 -o
gcctest1.elf
avr-objcopy -O avrobj -R .eeprom gcctest1.elf gcctest1.obj
avr-objcopy -O ihex -R .eeprom gcctest1.elf gcctest1.hex
elfcoff gcctest1.elf coff gcctest1.cof gcctest1.sym
Ended
cp coff\\*sym .
cp coff\\*cof .
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load"
--change-section
-lma .eeprom=0 -O ihex gcctest1.elf gcctest1.eep
avr-size gcctest1.elf
text data bss dec hex filename
128 0 0 128 80 gcctest1.elf
Errors: none
Im Moment funktioniert das ...
Frage: Sieht jemand Probleme, wenn ich das so lasse ???
Gruß und nochmals Danke
UBoot-Stocki
Wie ich sehe, bist Du extrem lernfähig! Also ich habe diese Macke nun bei mir auch festgestellt, besser gesagt, sie ist mir nun aufgefallen. Wie ich vermutet hatte, lag das Problem in Makefile, besser gesagt in der Datei avr_make, die ja praktisch ein include des normalen Makefile darstellt. Ich wüsste allerdings mal gerne, was folgende Zeile macht, die Du ja auch auskommentiert hast. # $(CP) $(OUT)/$@ . Meiner Meinung nach lag das Problem nämlich nur in der Zeile $(CP) $(OUT)/* . die kopiert nämlich alles aus dem coff-Verzeichnis ins Arbeitsverzeichnis. Aber ich denke mal, wenn Du mit dieser Änderung keine Nachteile feststellst, wird das schon so ok sein. Ich sehe soweit kein Problem. Gruss, Peter
Ach ja, folgendes fällt mir noch ein. Wenn Du schon die neueste Version des avrgcc installiert hast, da haben sie endlich mal die Reihenfolge der Parameter bei outp korrigiert. Es gibt nun nämlich zwei neue Befehle, und zwar: outb(PORT,byte_val) outw(PORT,short_int_val) um endlich mal Kompatibilität mit den übrigen Befehlen zu schaffen. Finde ich gut so! Gruss, Peter
Ich kann nur empfehlen: vergesst das Makefile von Volker Oth und schreibt euch euer eigenes. Das ist im Idealfall nur ein paar Zeilen lang.
@Andreas Ich glaube, die Empfehlung ist garnicht mal so verkehrt. Wenn man nur nicht so faul wäre ... ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.