Hallo Forum, vielleicht täusche ich mich, aber ich glaube gelesen zu haben, das es seit der letzten WinAVR Version eine Möglichkeit gibt die Fuses für einen AVR mit in das elf-File eincompilieren zu lassen. Leider finde ich im Moment hierzu keine Informationen. Weiß jemand was genaueres, wie das geht? Danke schon mal. MfG Wolfgang
Das ist m. W. noch nicht in trockenen Tüchern...
ach so, ... dann hab ich mich wohl getäuscht. Ich dachte eben gelesen zu haben das es schon geht. Also das soll wirklich kommen? Weißt du was genaueres Jörg?
Es ist möglich die Fuses und Lockbits in einer Sektion im ELF ablegen zu lassen. Siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__fuse.html http://www.nongnu.org/avr-libc/user-manual/group__avr__lock.html Nun bräuchte man einen Programmer welcher statt dem .hex das .elf nimmt und diese Sektionen liest und die Lockbits / Fuses dementsprechend setzt. PS: Ausprobiert hab ich das noch nicht, nur in der genannten Doku zur Kenntnis genommen. ;-)
@Jörg: Kann avrdude bereits .elf programmieren, oder ist es vielleicht angedacht diese Funktion (zusammen mit der auto. Fuse-Programmierung) einzubauen?
Wolfgang Birner wrote: > Kann avrdude bereits .elf programmieren, oder ist es vielleicht > angedacht diese Funktion ... > einzubauen? Nein, ja.
Oh, schon lange her: avrdude kann elf-Dateien lesen, seit Version 6.0.1 (2013). Also fürs Flashen und für Verify.
Leider gilt das nicht für Fuses und Sperrbits, oder zumindest habe ich nicht herausgefunden wie avrdude die elf-Datei gestaltet haben möchte. Die Include-Datei <avr/fuse.h> bzw. <avr/config.h> (für ATtiny4/5/9/10) sowie <avr/lock.h> legen gleichnamige Sections an, in der die wenigen Bytes abgelegt werden.
(Für EEPROM habe ich's noch gar nicht ausprobiert.)
Weiterhin kann avrdude /nicht/ die Section ".signature" lesen um den richtigen Chip zu selektieren. Oder die vom avr-gcc erstellte Sektion ".avr.prop", für die man gar kein #include <avr/signature.h> braucht.
Die Include-Datei <avr/fuse.h> bzw. <avr/config.h> (für ATtiny4/5/9/10) sowie <avr/lock.h> legen gleichnamige Sections an, in der die wenigen Bytes abgelegt werden.
Dann musst du sie nur noch programmieren lassen. ;-)
Jede -U Option programmiert einen Abschnitt aus dem ELF, standarmäßig (in der verkürzten Form der -U Option ohne irgendwelche Doppelpunkte) "flash". Alle anderen muss man explizit angeben.
Weiterhin kann avrdude /nicht/ die Section ".signature" lesen um den richtigen Chip zu selektieren. Oder die vom avr-gcc erstellte Sektion ".avr.prop", für die man gar kein #include <avr/signature.h> braucht.
Du könntest dafür auf github einen feature request stellen.
ABER: AVR Name => Signatur lässt sich eindeutig abbilden, anders herum geht es nicht. Ich habe aber jetzt nicht im Kopf, ob es Situationen gibt, in denen die fehlende Eineindeutigkeit kritisch werden könnte (weil die beiden so benannten Chips unterschiedliche Parameter haben).
Die Include-Datei <avr/fuse.h> bzw. <avr/config.h> (für ATtiny4/5/9/10) sowie <avr/lock.h> legen gleichnamige Sections an, in der die wenigen Bytes abgelegt werden.
Dann musst du sie nur noch programmieren lassen. ;-)
Das ist das Problem. Wie ich das sehen würde, sollte es (abgesehen von den Parametern zum Programmer/Protokoll) ausreichen, einfach nur das *.elf als Quelle anzugeben.
Alles andere sollte sich avrdude dann aus eben dieser Quelle saugen können (das muß natürlich die Informationen auch tatsächlich enthalten).
Der Ablauf wäre dann einfach so: Aus der Device-ID kann avrdude den Namen ermitteln und damit auch alles, was (leider) am Targetnamen hängt. Damit und mit den Infos zum Programmer/Protokoll kann es erstmal Kontakt zum Target aufnehmen und die ID verifizieren. Klappt das und passt die ID, kann's weiter gehen.
Es werden dann einfach alle Segmente geschrieben, die das *.elf enthält und fertig.
Die explizite Angabe von Inhalten sollte natürlich weiterhin möglich sein, aber nur dann nötig sein, wenn man was anderes programmieren will, als im *.elf steckt (oder bestimmte Segmente daraus auch gar nicht programmieren will).
Das wäre praxistauglich und benutzerfreundlich. Ja klar, gerade das Gegenteil von dem, wie diese Konsolen-"Anwenderprogramme" üblicherweise gestrickt sind. Die müssen wohl immer maximal umständlich und kryptisch sein...
Es werden dann einfach alle Segmente geschrieben, die das *.elf enthält und fertig.
Hatte ich mir damals angesehen, ließ sich aufgrund der Art und Weise, wie die Verarbeitung der Optionen und der ELF-Datei funktioniert, nicht trivial erreichen. Daher hatte ich das erstmal zu den Akten gelegt.
Außerdem will man eigentlich Fuses normalerweise nicht bei jedem Versuch neu programmieren – und oft genug auch den EEPROM nicht, wenn er bspw. interaktive Änderungen der Konfigurationsdaten enthält, die per EESAVE-Fuse erhalten bleiben sollen. Wenn, dann würde ich als "principle of least astonishment" (vor allem, weil ein einfaches "-U xxx.elf" nun schon seit Jahren nur den Flash selbst programmiert) eher sowas wie "-U all:w:xxx.elf" bevorzugen, wenn man wirklich alles aus dem ELF haben möchte.
Es steht dir natürlich frei, einen enhancement request beim Projekt einzureichen. Das ELF-Parsing ist kürzlich sowieso mal überarbeitet worden, vielleicht wäre so ein "-U all" damit jetzt einfacher erreichbar als damals.
Vergessen:
Der Ablauf wäre dann einfach so: Aus der Device-ID kann avrdude den Namen ermitteln und damit auch alles, was (leider) am Targetnamen hängt.
Wie schon geschrieben, die Abbildung von der Device-ID auf den Namen ist nicht eindeutig machbar. Der größte Teil der Doppeldeutigkeiten dürfte dabei nicht sehr schwerwiegend sein, da es sich jeweils um neuere Varianten des mehr oder weniger (aus Sicht der Programmierung) gleiche Modelle handelt (A-Varianten, PA-Varianten ...U-Varianten, Bondvarianten des gleichen Dies mit unterschiedlichen Pinanzahlen). Dagegen hilft aber natürlich auch kein anschließender Signatur-Check: wenn bspw. ein ATxmega32A4 und ein ATxmega32A4U die gleiche Signatur haben, erkennst du nur durch Lesen derselben nicht, was für ein Controller es nun tatsächlich ist. Einen wirklich ernsthaften Konflikt haben ATmega4809 und ATxmega64B3 mit der gleichen Signatur 0x1E,0x96,0x51. Bei ATxmega256A1 und ATxmega256C3 mit 0x1E,0x98,0x46 bin ich mir auf Anhieb nicht sicher, ob sie programmiertechnisch unterschiedlich zu behandeln sind oder nicht.
Außerdem will man eigentlich Fuses normalerweise nicht bei jedem Versuch neu programmieren – und oft genug auch den EEPROM nicht
Wie ich schon schrieb, die Möglichkeit, das zu verhindern oder die Inhalte zu ändern, sollte natürlich erhalten bleiben. Es geht einfach nur darum, dass der default seine sollte, einfach alles zu nehmen, was da ist und das nicht umständlich einzeln aufführen zu müssen.
eher sowas wie "-U all:w:xxx.elf" bevorzugen, wenn man wirklich alles aus dem ELF haben möchte.
Das wäre zumindest ein akzeptabler Kompromiss zwischen dem, was ist, und dem was sinnvoll wäre.
Es geht einfach nur darum, dass der default seine sollte, einfach alles zu nehmen, was da ist und das nicht umständlich einzeln aufführen zu müssen.
Naja, die -U Option hat halt vier durch Doppelpunkt getrennte Bestandteile: den Speicherbereich (flash, eeprom, …) , die Operation (lesen, schreiben, vergleichen), den Dateinamen und den Dateityp.
Da dann irgendwie dieses ständige "-U flash:w:filename" nervig war, habe ich mal irgendwann gedacht, dass der häufigste Anwendungsfall während der Entwicklung halt ist, dass man den Flash neu programmieren will, und habe den "Kurzschluss" eingebaut, dass "-U filename" behandelt wird wie "-U flash:w:filename:a". Das war lange, bevor da irgendwas mit ELF-Files reingekommen ist.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.