Hallo Zusammen,
also ich steh vor einem seltsamen Problem, ich nutze Linux u die
entsprechende AVR Toolchain!
Habe auch schon einige kleinere Projekte mit Hilfe der unheimlich guten
u ausführlichen Anleitungen hier im Forum - auf die Beine gestellt.
ABER:
ich hab ein simples Programm dass USART/RS232 implementiert hat und
einfach nur ein dummes "Hello World" ausgibt...dass funktioniert solange
ich den ATMEGA8 im ihex format flashe - sobald ich das gleichzeitig
compilierte .elf verwende bekomm ich in der terminalconsole nur noch
Schrott.
getestet sind verschieden atmega typen, verschieden
baudraten/quarze...und wie gesagt, am code selbst kann es nicht wirklich
liegen, da es ja der gleiche source code ist.
der grund warum ich eigentlich .elf verwenden will ist weil ich armer
den usbprog in verwendung hab und ihn aufgrund des bekannten
hex-bugs(bei manchen hexfiles will er einfach nicht) das ding bald aber
sicher auf ein eisenbahngleis lege...naja - der originale avr mkII ist
ja schon unterwegs = o)
aber eigentlich müsste es doch vollkommen egal sein ob hex oder elf,
oder?
lg aus Wien
Mario
Hallo Mario,
ich kenne den Programmer nicht, aber einen Unterschied gibt es schon,
den manch ein Programmer nicht handhaben kann.
Im ELF-File stehen die Adressen von allen Symbolen aus Sicht der CPU, im
HEX-File werden sie meist aus Sicht des Programmers generiert.
Beispiel zur Veranschaulichung: man verbinde ein Flash mit dem TriCore.
Aus TriCore-Sicht liegt das Flash dann im Adressbereich 0x8080 0000 -
0x809F FFFF (2MB).
Würdest du das Flash in einen Standalone-PRogrammer stecken, müßtest du
die 2MB von 0x0 - 0x1F FFFF programmieren.
Aus Linker-Sicht spricth man da von LMA und VMA, also Logical und
Virtual memory address (oder so ähnlich).
Und genau das KÖNNTE der Grund sein, warum dein IHEX funktioniert und
das ELF nicht, da der Programmer in der Regel nicht wissen kann, welcher
Adressbereich im ELF-File dem deines Flashes entspricht. Ist natürlich
eine Frage der Tool-Implementierung ...
Nur mal so eine Mutmaßung ...
Gruß
also, die gängigen aufrufe und "tricks" für avrdude hatte ich mir schon
aus einigen threads und anderen foren zusammengesucht - Optionen wie -B
8 oder auch -B64 um die Schreibgeschwindigkeit zu reduzieren sind
aufjeden fall dabei
...und wie gesagt hex kann ich ja wenns nicht gerade buggy ist auch
"brennen" - den deailierten aufruf kann ich hoffentlich am abend liefern
@Klaus B.
ja dass ist mir klar - aaaber das wäre ja dann prinzipiell eine sache
des Compilers/Linkers - weil wenn ich dem avr-gcc sag ich will ein hex
oder binary für den Controller Type XYZ dann sollte dem µC doch nachher
schnurz piep sein und der Compiler die Files entsprechend erstellen,
nicht?
Ich hätte jetzt folgenden Plan, ich warte auf den original ATMEL AVR
mkII der dafür gedacht ist und versuch dass ganze nochmal....und ich
trau mich fast wetten dass ich mit dem neuen programmer keine probleme
haben werde - werde natürlich berichten(kommt vielleicht noch heute)
der Vollständigkeit halber es handelt sich um den usbprog v3 von
Benedikt S. (embedded-projects.net) ...und sowohl in dessem forum als
auch hier sind die entsprechenden Probleme mit manchen Hexfiles
bekannt..
Nachdem allerdings die AVR wie ich das Gefühl habe zunehmend von ARM
"abgelöst" werden denk ich dass ich hier wohl länger auf einen
"Programmer-Fix" warten müsste!
vielen dank auf jedenfall für eure Reaktionen = o) und lg aus wien
Mario
> Im ELF-File stehen die Adressen von allen Symbolen aus Sicht der CPU, im> HEX-File werden sie meist aus Sicht des Programmers generiert.>
sorry dass wollt ich noch fragen - bist du dir sicher? also ich hab vor
einigen jahren ziemlich intensiv auf 8051ern in assembler programmiert -
da war noch nix mit flash on board...
und ich würde sagen, dass das hex file IMMER der "native" code für die
cpu ist...weil wenn du dir die hexfiles ansiehst hast du entsprechend
deinem code auch die startadressen, sprich wenn ich in meinem code sag
der code startet auf 0x8000...dann kann ich dass auch im hexfile so
"lesen"...
ausserdem müsst ich dann nicht dem compiler/linker, der ja den hexcode
generiert auch mitteilen welche art von programmer ich hab?
lg mario
Mario A. schrieb:> niemand der sich meiner frage annehmen möchte und etwas dazu sagen kann?
Vermutlich letzteres.
Ich wußte bisher nichtmal, daß man Elf überhaupt brennen kann. Sicher,
daß Dein Brenner das unterstützt?
Ich benutze schon immer Intel-Hex und bisher hat das noch jeder
Programmer gekonnt.
Mir ist auch nicht bekannt, daß es mit STK500 oder AVRISP mkII Probleme
geben soll.
Peter
Peter Dannegger schrieb:> Ich wußte bisher nichtmal, daß man Elf überhaupt brennen kann.
Ich kenne Elf als "Brenndatei für die Werkstatt bzw. Produktion" und
nutze dieses Format auch gelegentlich. Dabei erstelle ich die Elf-Datei
im Programmier-Dialog des AVR-Studios (4.16), indem ich Flash und EEP
auswähle und brenne, dann Fuses und Lockbits einstelle und danach die
Elf-Datei abspeichere. Muss ich später weitere AVRs mit diesem Programm
und diesen Einstellungen brennen, so genügt das Laden und Brennen der
Elf-Datei, denn da sind Flash, EEP und die Einstellungen für Fuses und
Lockbits in einer Datei vorhanden.
Ob dieses Elf-Format mit dem von GCC erzeugten Elf-Dateien identisch
ist, weiß ich nicht, ich mach' nix mit C, habe es gar nicht installiert.
Zumindest nicht bewusst, falls es bei AVR-Studio 4.16 bereits mit
installiert wurde, habe ich das übersehen, da ich nie versucht habe, ein
C-Projekt anzulegen.
...
Hi
>Ich wußte bisher nichtmal, daß man Elf überhaupt brennen kann. Sicher,>daß Dein Brenner das unterstützt?
Ich möchte mal behaupten, das das weniger eine Frage des Brenners als
des verwendeten Programms ist. Der Brenner bekommt ja auch nicht die
Hex-Datei, sondern nur die daraus aufbereiteten Daten zu sehen. Genau so
ist es mit den Elf-Dateien. Alle originalen Atmel-Programmer können über
das AVR-Studio die damit erzeugten Elf-Dateien brennen.
MfG Spess
spess53 schrieb:> Ich möchte mal behaupten, das das weniger eine Frage des Brenners als> des verwendeten Programms ist.
Genau, und AVRDUDE kann bislang mit einer ELF-Datei nichts anfangen.
Sie wird einfach als Binärdatei (v)erkannt. Logisch, dass das dann
nicht läuft.
Eigentlich sollte/wollte das mal jemand da einbauen ... aber wie das
so ist, der verfügbare Zeitrahmen der einzelnen Leute, die aktiv Code
beisteuern, ist nur endlich. Man müsste dann ggf. auch an der
Bedienung noch ein wenig feilen, denn beispielsweise willst du bei
einem ELF-File, das auch eine section .eeprom enthält, nicht unbedingt
jedesmal auch alle sections programmieren.
Außerdem kommt hier wieder die Abhängigkeit von auf dem Zielsystem
vorhandener Software ins Spiel. Schnell und einfach wäre das auf
allen Systemen zu implementieren, die bereits eine libelf im System
haben, aber da kenne ich zumindest eins, bei dem das wohl eher nicht
der Fall wäre. Alternativ kann man sicher die libbfd der GNU binutils
nutzen (die ihrerseits wieder die libiberty der binutils braucht), aber
die muss man dann separat compiliert bereithalten. Oder man schreibt
die paar Funktionen innerhalb von AVRDUDE nochmal selbst.
Naja, es macht halt Arbeit, und ist nicht "mal schnell an einem Abend"
gemacht.
Guten Morgen zusammen,
vielen Dank für die vielen Antworten,
Zum letzten Beitrag, ich dachte eigentlich .elf IST die Binärdatei wie
sie von AVRDUDE ansich genommen werden sollte??
wie auch immer, ich hab nun endlich einen fix für meinen "usbprog"
gefunden der den Fehler mit ihex behebt. Zum anderen hab ich meinen
original ATMEL AVR mkII endlich da und der ist sowieso brav und
zuverlässig.
Aus Spass an der Freude werd ich noch ein wenig experimentieren, bis
jetzt sieht es tatsächlich so aus dass ein elf (egal mit welchem
"Brenner") hauptsächlich Schrott erzeugt im Betrieb. Vielleicht find ich
ja in den Dokumentationen konkreteres (bis jetzt leider nicht) zu elf
und binary.
Nachdem ich mich dann familiären Feierlichkeiten widmen muss - wünsche
ich euch allen ein schönes "Happy-Bastel oder Happy-Entwickler"
Wochenende g
lg aus Wien
Mario
Mario A. schrieb:> dass ein elf (egal mit welchem> "Brenner") hauptsächlich Schrott erzeugt im Betrieb.
Das kann ich nicht bestätigen. Mit Atmel-Equipment (STK500) und
Atmel-Software (AVR-Studio4.16) funktioniert es.
...
Hannes Lux schrieb:> Mario A. schrieb:>> dass ein elf (egal mit welchem>> "Brenner") hauptsächlich Schrott erzeugt im Betrieb.>> Das kann ich nicht bestätigen. Mit Atmel-Equipment (STK500) und> Atmel-Software (AVR-Studio4.16) funktioniert es.
Das dürfte derzeit auch die einzige Ausnahme sein. Alle anderen
werden die ELF-Datei entweder gar nicht erst nehmen (weil sie Ihex
erwarten) oder als reinen Binärklumpen fehlerkennen. Solange es
keinen Controller gibt, der ELF dann direkt booten kann ;), hat man
damit schlechte Karten.
Wie geschrieben, AVRDUDE sollte das eigentlich auch mal können,
ist aber eins der Dinge, die aus Zeitmangel bislang hinten runter
gerutscht sind.
