Forum: Compiler & IDEs AVR Fuses in .elf eincompilieren


von Wolfgang B. (logox2)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Das ist m. W. noch nicht in trockenen Tüchern...

von Wolfgang B. (logox2)


Lesenswert?

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?

von Michael L. (zvpunry)


Lesenswert?

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. ;-)

von Wolfgang B. (logox2)


Lesenswert?

@Jörg:
Kann avrdude bereits .elf programmieren, oder ist es vielleicht 
angedacht diese Funktion (zusammen mit der auto. Fuse-Programmierung) 
einzubauen?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Wolfgang Birner wrote:

> Kann avrdude bereits .elf programmieren, oder ist es vielleicht
> angedacht diese Funktion ...
> einzubauen?

Nein, ja.

von Henrik H. (Firma: TU Chemnitz) (heha)


Lesenswert?

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.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Henrik H. schrieb:
> 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).

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Jörg W. schrieb:

> Henrik H. schrieb:
>> 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...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ob S. schrieb:
> 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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Vergessen:

Ob S. schrieb:
> 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.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Jörg W. schrieb:

> 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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ob S. schrieb:
> 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.

Bitte 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
Noch kein Account? Hier anmelden.