Hallo,
ich möchte meinen uC (Atmega8) unter Linux programmieren
(Programmiersprache C) und flashen.
Dazu habe ich avr-gcc und avrdude (+Dependencies) installiert.
Das Kompilieren des Quellcodes funktioniert einwandfrei, das Übertragen
einer Hexfile zum uC ebenfalls (mit einer Testfile ausprobiert).
Ich habe aber keine Ahnung, wie ich vom Ergebnis des Compilers zu einer
Hexfile komme?
Es gibt zig Anleitungen, Forenbeiträge etc., die auf einen Thread von
AVRfreaks verweisen. Damit wird aber die komplette
Entwicklungsumgebung erzeugt, meine steht ja soweit.
Dadurch bin ich mir nicht sicher, was ich tun muss um eine Hexfile zu
bekommen?
Besten Dank für Euer Bemühen.
Grüße
K.
Hallo,
also für's konvertieren von a.out nach .hex wird eigentlich immer
objcopy (bzw. avr-objcopy) eingesetzt. Oder habe ich Deine Frage nicht
richtig verstanden?
ciao
Marcus
Fuer das Compilieren in Unix-Umgebungen bemueht man normalerweise ein
Makefile. Diese enthaelt die notwendigen Compiler-Optionen.
Als Vorlage koenntest du Joergs Makefile-Generator nehmen..
http://www.sax.de/~joerg/mfile/
..oder falls du Zugriff auf eine WinAVR-Installation hast, nimm das
Template von dort.
Vielen Dank für die Hinweise.
Das avr-objcopy-Tool hatte ich ganz übersehen, das avr-objdump hatte ich
mir angesehen :/
Mit folgendem Befehl habe ich nun versucht eine Hexfile zu erstellen.
Fnktioniert auch fehlerfrei.
1
avr-objcopy -O ihex -I binary main.out main.hex
Beim flashen bekomme ich allerdings einen Fehler:
>avrdude: verification error, first mismatch at byte 0x0000> 0x7f != 0x12>avrdude: verification error; content mismatch
Zudem ist die Hexfile stolze 11kB groß geworden!
Den Makefile-Generator werde ich mir mal näher anschauen. Trotzdem
müsste es doch eine Möglichkeit geben, über die o.g. Befehle einen
Quellcode in den uC zu bekommen?!
olibert schrieb:
> Fuer das Compilieren in Unix-Umgebungen bemueht man normalerweise ein> Makefile. Diese enthaelt die notwendigen Compiler-Optionen.
Jepp. Makefiles fallen ja bekanntlich vom Himmel...
Klaus schrieb:
>
1
avr-gcc -o2 -mmcu=atmega8 main.c -o main.out
Diese Ausgabe ist nicht in binary (bin), sondern die Standard avr-ld
Ausgabe, also elf (elf32-avr). Von daher nennt man die Ausgabe weniger
missverständlich besser main.elf. Zudem wird optimiert mit -O, nicht mit
-o.
> Mit folgendem Befehl habe ich nun versucht eine Hexfile zu erstellen.> Fnktioniert auch fehlerfrei.>
1
avr-objcopy -O ihex -I binary main.out main.hex
Naja, nicht wirklich. Du schiebst das ganze ELF, binär und Bit für Bit
auf den µC. Womit er erstens nix anfangen kann, und zweitens sind da
noch Debug-Infos und allso'n Zeug drinne. Ergo:
> Zudem ist die Hexfile stolze 11kB groß geworden!>> Den Makefile-Generator werde ich mir mal näher anschauen. Trotzdem> müsste es doch eine Möglichkeit geben, über die o.g. Befehle einen> Quellcode in den uC zu bekommen?!
Du willst nicht den Quellcode im µC ;-)
Johann
Klaus schrieb:
[...]
> Beim flashen bekomme ich allerdings einen Fehler:>>avrdude: verification error, first mismatch at byte 0x0000>> 0x7f != 0x12>>avrdude: verification error; content mismatch
ich kenne avrdude nicht, aber das klingt, als würde nach dem
programmieren des Speichers der nachträgliche Vergleich (Inhalt-Soll zu
Inhalt-Ist) schiefgehen. Und das gleich an Adresse null. Seltsam. Kann
eigentlich nicht am falschen Hex-File liegen, da der Programmer die
geschriebenen mit den rückgelesenen Daten vergleicht. Mit falschem
hexfile wird evtl. Dein Programm nicht laufen. Aber der Datenvergleich
müsste trotzdem ein OK melden.
>> Zudem ist die Hexfile stolze 11kB groß geworden!
Na ja, kommt darauf an, wie groß Dein Programm ist und welche
Bibliotheken/Startup-Codes Du dazugelinkt/verwendet hast.
>> Den Makefile-Generator werde ich mir mal näher anschauen. Trotzdem> müsste es doch eine Möglichkeit geben, über die o.g. Befehle einen> Quellcode in den uC zu bekommen?!
Quellcode? Verstehe ich jetzt nicht ganz.
ciao
Marcus
Klaus schrieb:
> Beim flashen bekomme ich allerdings einen Fehler:>>avrdude: verification error, first mismatch at byte 0x0000>> 0x7f != 0x12>>avrdude: verification error; content mismatch>> Zudem ist die Hexfile stolze 11kB groß geworden!
Es gibt einen wrap-around, weil der ATmega nur 8k Flash hat. Somit wird
Byte 0x2000 an Adresse 0 geschieben usw. Beim Auslesen ergibt sich dann
ein Fehler.
Hallo,
ich möchte mir zunächst mal recht herzlich für eure Antworten bedanken.
>Du willst nicht den Quellcode im µC ;-)
Natürlich nicht, hatte mich missverständlich ausgedrückt.
Folgende (angepasste) Toolchain funktioniert leider auch nicht, beim
Übertragen werden wieder
>avrdude: verifying ...>avrdude: verification error, first mismatch at byte 0x0001> 0xc0 != 0x40>avrdude: verification error; content mismatch
Immerhin ist die Hexfile nur noch 316 Bytes groß.
Zudem habe ich mich mit mfile beschäftigt und dies eingerichtet. Aber
ich verstehe noch nicht ganz, wie ich dies anwenden soll.
Das Template habe ich nach meinen Wünschen angepasst, aber wie benutze
ich dies nun?
Die Readme ist in der Richtung etwas mager, aber vielleicht ist auch
alles so logisch und schlüssig, dass es gar nicht notwendig ist...? :)
>Das Template habe ich nach meinen Wünschen angepasst, aber wie benutze>ich dies nun?
Gar nicht...
Nimm das Original-Template, und lass das in Ruhe.
MFile starten, und in den Menus Quelldateien, Prozessor,
Optimierungsstufem etc. einstellen. MFile trägt das dann an den
richtigen Stellen ins makefile ein. makefile in den Projektordner
abspeichern, dort make aufrufen, fertig. (ok, die Sourcen und die Pfade
dazu kann man auch von Hand ins fertige makefile schreiben)
Oliver
>>avrdude: verifying ...>>avrdude: verification error, first mismatch at byte 0x0001>> 0xc0 != 0x40>>avrdude: verification error; content mismatch>> Immerhin ist die Hexfile nur noch 316 Bytes groß.
Sieht eher wie ein Problem der Progger-Hardware aus als das einer
falschen oder falsch angewandten Toolchain. Vielleicht mal die
Übertragungsrate reduzieren.
Die Größe des Programmes ist nicht die Größe des Hexfiles. Die Größe des
Programmes ist ablesbar in der Ausgabe von avr-size.
Habe meinen "Fehler" gefunden, die Verwendung sieht dann bspw. so aus:
1
make -f Makefile
Wieder etwas dazu gelernt.
Alles funktioniert einwandfrei :)
Noch kurz erwähnt, wählt man bei mfile "usb" als Schnittstelle aus, wird
auch nur "usb" in die Makefile geschrieben. Händisch kann man dies aber
auch korrigieren. Aussehen muss es so:
>AVRDUDE_PORT = /dev/ttyUSB0
Besten Dank an alle netten Helfer!
>Habe meinen "Fehler" gefunden, die Verwendung sieht dann bspw. so aus:>make -f Makefile
Nennst du das Makefile makefile, dann sieht die Verwendung so aus:
make
Oliver
Klaus schrieb:
> Noch kurz erwähnt, wählt man bei mfile "usb" als Schnittstelle aus, wird> auch nur "usb" in die Makefile geschrieben.
Das ist OK. Das ist für solche Programmiergeräte gedacht, die nicht
über eine virtuellen seriellen Treiber arbeiten (beispielsweise die
diversen Atmel-Tools oder USBasp), sondern die direkt über libusb
angesteuert werden müssen.
> Händisch kann man dies aber> auch korrigieren. Aussehen muss es so:>>AVRDUDE_PORT = /dev/ttyUSB0
Bei dir. Bei anderen ist es vielleicht /dev/ttyUSB17, auf einem
anderen System ist es /dev/cuau3 oder /dev/cuaU0, und auf wieder
anderen Systemen einfach com14. Ich kann versuchen, die ersten
zwei oder drei gängigen Namen solcher Seriell-Emulations-Schnitt-
stellen noch mit einzubauen, aber alles wird ein Mfile leider auch
nicht ohne händisches Editieren erschlagen können -- genauso, wie
es bei den "echten" USB-Tools den Fall nicht berücksichtigt, dass
man davon mehrere angeschlossen hat und diese nach Seriennummer
unterscheiden muss.
Thread beobachten
Seitenaufteilung abschalten