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
...bin jetzt kein gast mehr g niemand der sich meiner frage annehmen möchte und etwas dazu sagen kann? lg 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.
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.