Hallo,
mein Thema wurde vor 10(!) Jahren z.B. schon mal in diesen Threads
behandelt:
Beitrag "Bootmanager und Mainprogramm auf einmal Flashen"Beitrag "Bootloader und App in einem ELF"
aber vielleicht gibt es inzwischen eine befriedigendere Antwort:
Ich programmiere ATmegas mit Bootloader und Hauptprogramm.
Das zusammenfügen und programmieren erledige ich wie auch im ersten
Beitrag oben beschrieben immer noch mit
- Main.hex erzeugen
- Boot.hex erzeugen
- beide .hex-files im Texteditor per Hand zusammenfügen
- neues .hex-file programmieren
- Fuse-Bytes programmieren
Schöner wäre es natürlich, wenn ich auf Tastendruck direkt beim
Kompilieren/Linken eine gemeinsame Boot+Main.elf erzeugen könnte, die
auch die Fuse-Einstellungen enthält.
Kennt jemand dafür inzwischen eine Lösung?
Oder, das wäre die halbe Lösung: kann ich aus meiner manuell erzeugten
Boot+Main.hex eine .elf erzeugen, die die Fuse-Bytes enthält?
Ich verwende übrigens das aktuelle Atmel Studio 7.0, dort habe ich die
beiden Projekte Boot/Main in einer gemeinsamen Solution, irgendwie
sollte sich das doch verbinden lassen?
PunchBoy schrieb:> Schöner wäre es natürlich, wenn ich auf Tastendruck direkt beim> Kompilieren/Linken eine gemeinsame Boot+Main.elf erzeugen könnte, die> auch die Fuse-Einstellungen enthält.>> Kennt jemand dafür inzwischen eine Lösung?
Ja.
Bootloader muss genau einmal geflasht werden.
Und dient dazu, Applikationen mehrmals zu flashen.
Aber das weisst du ja wahrscheinlich alles schon, nur weisst du
anscheinend nicht, dass es in VS weniger als eine Stunde dauert,
um entsprechendes Programm zu schreiben.
Marc V. schrieb:> Aber das weisst du ja wahrscheinlich alles schon, nur weisst du> anscheinend nicht, dass es in VS weniger als eine Stunde dauert,> um entsprechendes Programm zu schreiben.
Das wird er sicherlich wissen, aber in Atmel Studio isses natürlich
tausendmal schöner einfach beim testen kurz die "F5" zu drücken und ab
dafür anstatt erst den Flip-Loader oder what ever zu öffnen und dann
dort zu flashen. ;-)
Ich verstehe Punch-Boy da schon.
Hallo Marc,
die Antwort geht leider an meiner Frage vorbei: Ziel ist es wirklich,
ein einziges .elf mit allem Code zu erzeugen, das dann an einen
Lieferanten zum Flashen übergeben werden kann. Ich rede hier nicht von
Heim-Bastel-Lösungen.
Was Dein in einer Stunde geschriebenes Programm tun soll, habe ich
allerdings nicht verstanden.
PunchBoy schrieb:> die Antwort geht leider an meiner Frage vorbei: Ziel ist es wirklich,> ein einziges .elf mit allem Code zu erzeugen, das dann an einen> Lieferanten zum Flashen übergeben werden kann. Ich rede hier nicht von> Heim-Bastel-Lösungen.>> Was Dein in einer Stunde geschriebenes Programm tun soll, habe ich> allerdings nicht verstanden.
Und ich verstehe nicht wieso das an einen Lieferanten in einem
einzigen .elf gehen soll.
Ein Bootloader dient zum Flashen, wird irgendwann einmal benutzt
werden. Damit man sicher ist, dass es auch bei gerade geflashtem
uC auch funktioniert, wird mittels frisch geflashtem Bootloader die
eigentliche Applikation geflasht.
Nur so ergibt es einen Sinn, nur so ist es richtig und nur so wird
es in der Produktion auch gemacht.
Bootloader und Applikation auf einmal flashen ist etwas unüblich
und zumindest unseriös. Auch mit Verify ist nicht sichergestellt,
dass der Bootloader einwandfrei funktioniert.
Ihr könnt das natürlich machen, wie es euch gefällt.
Marc V. schrieb:> Damit man sicher ist, dass es auch bei gerade geflashtem> uC auch funktioniert, wird mittels frisch geflashtem Bootloader die> eigentliche Applikation geflasht.
Das kann man am Anfang testen, solange bis man sicher ist daß alle
diesbezüglichen Bugs ausgebügelt sind und das
Skript/Programm/Tool/Whatever und die Binaries mit denen man in der
Produktion zu flashen gedenkt richtig funktionieren.
Sobald das der Fall ist kann man in Zukunft alles in einem Rutsch drauf
flashen. Einfach weils weniger Aufwand ist.
> Bootloader und Applikation auf einmal flashen ist etwas unüblich und> zumindest unseriös.
Nein, das ist durchaus üblich. Unseriös? Blödsinn. Was soll daran
unseriös sein die Produktionsprozesse zu entkomplizieren und somit
mögliche Fehlerquellen zu reduzieren?
PunchBoy schrieb:> Ziel ist es wirklich,> ein einziges .elf mit allem Code zu erzeugen,
- Bootloader flashen
- Applikation mit Bootloader flashen
oder
- Bootloader flashen
- Applikation flashen und dabei den Speicher NICHT(automatisch) vorher
löschen.
dann
- Controller auslesen und in Hex speichern
- Aus diesem Hex mit den Fuse- und Lockbits EINE *.elf erstellen
Ich hatte dasselbe Problem: Ich wollte bei der Programmierung des µC
während der Produktion die Applikation und den Bootloader gleichzeitig
programmieren. Die zweistufige Variante erst Bootloader und dann die
Applikation war für die Produktion inakzeptabel, da das viel zu lange
dauert und sich schlecht automatisieren ließ. Vor allen weil der
Bootloader über einen Kommunikationkanal kommuniziert, der während der
Produktion nicht verfügbar ist.
Deshalb verwende ich die SRecord tools um die Hexfiles der Applikation
mit dem Hexfile des Bootloaders zu vereinen.
http://srecord.sourceforge.net/
Das Tool hat zusätzlich den Vorteil, das es eine CRC für die Applikation
berechnen kann und diese an einer bestimmten Stelle in das Anwendungs
Hexfile einfügen kann. Diese CRC wird zum Beispiel vom Bootloader
überprüft.
Der Aufruf der Tools funktioniert automatisch beim Erstellen der
Software sowohl unter Eclipse als auch natürlich bei normalen makefiles.
Mittels postbuild steps geht das bestimmt auch in VS oder Atmelstudio.
Man kann sich aber auch sehr schnell ein kleines Programm schreiben das
die HEX Files zusammenfügen kann. Das HEX Dateiformat ist ziemlich
einfach.
Bernd K. schrieb:>> Bootloader und Applikation auf einmal flashen ist etwas unüblich und>> zumindest unseriös.>> Nein, das ist durchaus üblich. Unseriös? Blödsinn. Was soll daran> unseriös sein die Produktionsprozesse zu entkomplizieren und somit> mögliche Fehlerquellen zu reduzieren?
Nein, das ist nicht üblich.
Erstens ist ein uC mit Bootloader dazu bestimmt, die auf ihm laufende
Applikation zu verändern oder durch eine ganz andere zu ersetzen.
Das sind keine uC die in Zehntausenden produziert werden, und selbst
wenn, es muss ganz einfach sichergestellt werden, dass es 100%-ig
funktioniert - auch wenn es 5s länger dauert.
Alles andere ist ganz einfach unseriös.
Glaubst du wir (oder irgend jemand anders, der sich ernsthaft damit
beschäftigt oder sogar davon lebt) baut so einen uC ein, ohne vorher
Bootloader geprüft zu haben ?
Nöö, sicher nicht und du sollst nicht Sachen von denen du offenbar
keine Ahnung hast, als Blödsinn bezeichnen.
Thomas E. schrieb:> - Aus diesem Hex mit den Fuse- und Lockbits EINE *.elf erstellen
Und hier war Teil 2 meiner Frage :-) : wie geht das am einfachsten?
Marc V. schrieb:> baut so einen uC ein, ohne vorher> Bootloader geprüft zu haben ?
Der Code des Bootloaders wird in der Entwicklung auf Herz und Nieren
geprüft, der funktioniert (nach bestem Wissen). In der Fertigung wird
beim Flashen geprüft, dass der Bootloader korrekt geflasht wurde, d.h.
alle Nullen und Einsen dort sind, wo sie hingehören. Welcher Fehler soll
sich dann noch von Platine zu Platine ergeben?
Marc V. schrieb:> und selbst> wenn, es muss ganz einfach sichergestellt werden, dass es 100%-ig> funktioniert - auch wenn es 5s länger dauert.
Das wird es doch.
Und nachdem das sichergestellt ist kann man die anderen 19999 Exemplare
mit dem selben Script und der selben Firmware flashen.
> baut so einen uC ein, ohne vorher Bootloader geprüft zu haben ?
Wo hab ich das behauptet? Ich habe gesagt das man das ausgiebig testen
kann (und soll) so lange bis man sich sicher ist daß alle Softwarebugs
behoben sind und der Bootloader funktioniert. Danach kann man die
anderen 19999 Exemplare mit der selben Firmware flashen.
PunchBoy schrieb:> Und hier war Teil 2 meiner Frage :-) : wie geht das am einfachsten?> Ich verwende übrigens das aktuelle Atmel Studio 7.0
Ich habe das Studio 7 gerade nicht greifbar. Aber es gibt dort eine
Funktion zum Erstellen von Production Files. Die befindet sich im
Gegensatz zum alten Studio 4 allerdings nicht im Brenner-Dialog. Da drin
kannst du das mit ein paar Häkchen in den entsprechenden Checkboxes nach
deinen Anforderungen zusammenstellen.
PunchBoy schrieb:> Hallo Marc,>> die Antwort geht leider an meiner Frage vorbei: Ziel ist es wirklich,> ein einziges .elf mit allem Code zu erzeugen, das dann an einen> Lieferanten zum Flashen übergeben werden kann.
Wenn dein Lieferant mit mehreren Dateien Probleme hat, dann solltest du
über einen Wechsel nachdenken.
Aber fangen wir vorne an. Fuses kann man mittlerweile im Code setzen.
http://www.nongnu.org/avr-libc/user-manual/group__avr__fuse.html Das ist
kein Problem des .elf, sondern ob der von deinem Lieferanten verwendete
Gang-Programmer Fuse-Settings im .elf versteht. Du solltest mit deinem
Lieferanten reden was sein Gang-Programmer kann, beziehungsweise warum
er die Fuses nicht aus dem .elf lesen kann.
Das Zusammenführen eines Bootloader .hex und eines Programm .hex muss
man selbstverständlich nicht von Hand in einem Editor machen. Das kann
man mit Tools skripten (vielleicht srec_cat?) oder sich, wie oben schon
erwähnt, ein Programm für schreiben.
Aber, der absolute Star unter den Werkzeugen zum Zusammenfügen von
Kompilaten ist, man glaubt es kaum, der Linker.
> Ich rede hier nicht von> Heim-Bastel-Lösungen.
Dann rede zuerst mal mit deinem professionellen Lieferanten, warum er
mit drei Dateien Probleme hat.
Wenn für dich alles selbstgemachte eine Heim-Bastel-Lösungen ist, dann
wird sich hier sicher jemand finden, der das Zusammenfügen der Dateien
als Dienstleistung, vielleicht über einen Webservice, anbietet. So voll
professionell. Gegen professionelle Bezahlung.
Bernd K. schrieb:> behoben sind und der Bootloader funktioniert. Danach kann man die> anderen 19999 Exemplare mit der selben Firmware flashen.PunchBoy schrieb:> geprüft, der funktioniert (nach bestem Wissen). In der Fertigung wird> beim Flashen geprüft, dass der Bootloader korrekt geflasht wurde, d.h.> alle Nullen und Einsen dort sind, wo sie hingehören. Welcher Fehler soll> sich dann noch von Platine zu Platine ergeben?
Der Fehler, der sich Zufall und Murphy's law nennt.
Nach eurer Auffasung sollte es auch keine Produktionstest geben -
alles richtig geflasht, richtig gelötet, sieht gut aus, überhaupt kein
Problem - wird in Autos, Flugzeuge usw. ohne weitere Prüfung eingebaut,
wird schon funktionieren...
Ich glaub', Ihr streitet euch um des Kaiser's Bart.
Meines Erachtens ist ein Bootloader (und die Möglichkeit, den separat zu
flashen und auch nur dann, wenn's unbedingt notwendig ist) nur dort von
Bedeutung, wo keine separate, schnelle Flashmöglichkeit besteht.
Also dort, wo ein Fehlschlag beim Flashen das bewußte Gerät zum
Türstopper macht, weil man nicht mehr an den Flash drankommt und das
Ding einschicken oder auf den Service warten muß.
Sprich: wenn bei fehlgeschlagenen Flashvorgang keine einfache und
schnelle Möglichkeit besteht, (z.B.) auf die vorherige Version
zurückzugehen.
Wenn es die gibt (z.B. weil das Flashen sowieso von einem zweiten µC aus
gemacht wird), ist m.E. der Bootloader eigentlich unnötig und man kann
genausogut jedesmal den gesamten Flash auf einmal überklatschen.
Marc V. schrieb:> Der Fehler, der sich Zufall und Murphy's law nennt.
Deswegen testest du bestimmt auch Schmelzsicherungen vor der
Auslieferung auf einwandfreie Funktion.
Marc V. schrieb:> Nach eurer Auffasung sollte es auch keine Produktionstest geben -
Was hat das eine mit dem anderen zu tun? Die Hardware kann man
unabhängig davon und zu gegebener Zeit auf korrekte Funktion prüfen.
Dem Threadersteller gehts darum das Flashen zu vereinfachen.
Thomas E. schrieb:> Marc V. schrieb:>> Der Fehler, der sich Zufall und Murphy's law nennt.>> Deswegen testest du bestimmt auch Schmelzsicherungen vor der> Auslieferung auf einwandfreie Funktion.
Hört sich eher so an als würde er Excel-Tabellen mit dem Taschenrechner
nachrechnen. Und zwar nach jeder Kopie der Datei erneut.
Bernd K. schrieb:> Hört sich eher so an als würde er Excel-Tabellen mit dem Taschenrechner> nachrechnen. Und zwar nach jeder Kopie der Datei erneut.
Aber nicht, ohne vorher den Taschenrechner zu debuggen.
Seid bitte so gut und lenkt den Thread nicht in einen Privat-Streit. Es
geht mir nicht um Sinn und Umfang Produktionstests. Natürlich muss man
zu jedem Zeitpunkt von Entwicklung/Fertigung in sinnvollem Umfang (!)
testen.
Jay schrieb:> Wenn dein Lieferant mit mehreren Dateien Probleme hat, dann solltest du> über einen Wechsel nachdenken.Jay schrieb:> Das Zusammenführen eines Bootloader .hex und eines Programm .hex muss> man selbstverständlich nicht von Hand in einem Editor machen. Das kann> man mit Tools skripten (vielleicht srec_cat?) oder sich, wie oben schon> erwähnt, ein Programm für schreiben.
Es geht mir darum, den Release-Prozess einer neuen Version zu
vereinfachen.
Idealerweise: 1. Änderung im Code, 2. Compile&Link einer .elf Datei mit
einem Tastendruck, 3. Die eine Datei zum Lieferanten.
Je mehr Schritte beim Erstellen notwendig sind, desto mehr Fehler kann
man machen.
Und man hat sonst immer ein Paket aus z.B. drei Dateien
(Main/Boot/FuseSettings), die nur zusammen eine Version definieren.
Jay schrieb:> Aber, der absolute Star unter den Werkzeugen zum Zusammenfügen von> Kompilaten ist, man glaubt es kaum, der Linker.Thomas E. schrieb:> Ich habe das Studio 7 gerade nicht greifbar. Aber es gibt dort eine> Funktion zum Erstellen von Production Files. Die befindet sich im> Gegensatz zum alten Studio 4 allerdings nicht im Brenner-Dialog. Da drin> kannst du das mit ein paar Häkchen in den entsprechenden Checkboxes nach> deinen Anforderungen zusammenstellen.
Das ist mein Thema. Wie kann ich dem Linker im Atmel Studio beibringen,
meine .elf-Datei zu erzeugen?
Also Marc, ich verstehe dein Problem hier nun auch nicht, und kann deine
Sichtweise auf Bezug: Produktion / Bootloader, auch nicht
nachvollziehen. Die Produktionsfirmen sparen alle wo sie können, Prüfung
hin oder her, hier redet auch kein Mensch davon das es sich hierbei um
Militärtechnik oder Technik für Aero oder Medizintechnik handelt.
Es ist schon ein großer Zeit und Kostenfaktor ob man den µC nun einmal
im Rutsch flasht (Und warum sollte man ihn dann nicht verifizieren
können?! Wegen des BL? Quark!) oder ob ich als Firma erstmal den
Bootloader flashe - dann eventuell warten muss (kann ja sein das die
Schnittstelle für den BL erst später kommt) um dann nochmals über den BL
den µC zu flashen.
Das ist ja so als ob man sich ne Banane kauft, die im Geschäft schält,
erst die Schale nach Hause bringt, nochmal zurück zum Laden geht und
dann erst den Rest den Banane holt - nur um sicherzustellen das beides
gut zu Hause ankommt.
Und dein Argument das der BL ja Fehlerhaft sein könnte, kann dir beim
Flashen des BL only wohl nicht passieren?! Das ist doch alles an den
Haren herbeigezogen.
Draco schrieb:> können?! Wegen des BL? Quark!) oder ob ich als Firma erstmal den> Bootloader flashe - dann eventuell warten muss (kann ja sein das die> Schnittstelle für den BL erst später kommt) um dann nochmals über den BL> den µC zu flashen.
Aha.
Und um Bootloader zu flashen hast du am uC klitzekleine Drähtchen
angelötet, mit Prommer verbunden und danach wieder ausgelötet,
oder wie ?
Das ist natürlich viel schneller als die übliche Methode, lass dich
nicht vom Gegenteil überzeugen.
> Und dein Argument das der BL ja Fehlerhaft sein könnte, kann dir beim> Flashen des BL only wohl nicht passieren?!
Natürlich.
Deswegen flasht man danach mit dem Bootloader die Applikation und hat
damit beide getestet - die Schnittstelle übrigens auch.
Und nochmal:
Ein uC mit Bootloader dessen funktionstüchtigkeit nicht geprüft wurde,
geht bei keiner normaler Firma raus - nicht nur beim Hersteller,
sondern auch bei Firmen die so etwas einbauen.
PunchBoy schrieb:> Seid bitte so gut und lenkt den Thread nicht in einen Privat-Streit. Es> geht mir nicht um Sinn und Umfang Produktionstests. Natürlich muss man> zu jedem Zeitpunkt von Entwicklung/Fertigung in sinnvollem Umfang (!)> testen.PunchBoy schrieb:> Jay schrieb:>> Aber, der absolute Star unter den Werkzeugen zum Zusammenfügen von>> Kompilaten ist, man glaubt es kaum, der Linker.>> Thomas E. schrieb:>> Ich habe das Studio 7 gerade nicht greifbar. Aber es gibt dort eine>> ...>> deinen Anforderungen zusammenstellen.>> Das ist mein Thema. Wie kann ich dem Linker im Atmel Studio beibringen,> meine .elf-Datei zu erzeugen?
oder wo auch immer du deinen code haben willst...
P.S.
Nicht ausprobiert, nur gedacht, dass es vielleicht so gehen kann,
um deinen Lieferenten zu schonen...
P.P.S.
Ist natürlich nur eine Heim-Bastel-Lösung, dein Lieferant hat
wahrscheinlich viele Fachleute die das besser können.
Marc V. schrieb:> Und nochmal:> Ein uC mit Bootloader dessen funktionstüchtigkeit nicht geprüft wurde,> geht bei keiner normaler Firma raus
Das hat auch keiner verlangt.
Der Bootloader wird bei seiner Entwicklung ausgiebig getestet, danach
funktioniert er. Und zwar bis ans Ende der Zeit. Es ist nicht zu
erwarten daß er plötzlich mutiert wenn nachts keiner hinsieht.
Die Hardware vor der Auslieferung zu testen ist ein komplett anderes
Thema.
Hier gehts aber ums effiziente Flashen, das hat damit null und nichts zu
tun.
Nach dem ich lange Zeit stiller Mitleser bin und schon lange in anderen
Foren aktiv bin.
Muss ich jetzt mal meinen Senf mit dazu geben.
Ihr denkt alle viel zu kompliziert.
Klitze kleines C-Programm,
es liest die beiden Hex-files ein, fügt sie zusammen und schraubt sie
wieder als Hex-file.
Gruß,
Jan
Jannyboy schrieb:> Klitze kleines C-Programm,> es liest die beiden Hex-files ein, fügt sie zusammen und schraubt sie> wieder als Hex-file.
Ist zwar nicht kliteklein (weil tausende Optionen), dafür aber bereits
geschrieben:
srec_cat, siehe Doku hier:
http://srecord.sourceforge.net/
Damit kannst Du Files unterschiedlichster Formate zusammenfügen. RCA
Cosmac Elf ist auch dabei, habe ich aber persönlich noch nicht verwendet
und ich weiss nicht, ob das kompatibel mit dem aktuellen gcc elf Format
ist.
Damit erzeugen wir unsere kombinierten Bootloader-und Applikationsfiles
direkt im makefile, d.h. bei jedem Compilieren fällt auch das
kombinierte File ab.
Viele Grüße, Stefan
GNU objcopy müsste das eigentlich auch können (hab's nie probiert).
objcopy bootloader.elf --add-section sectionname=application.elf
fat_binary.elf
sollte das eigentlich hinkriegen.
PunchBoy schrieb:> Ich programmiere ATmegas mit Bootloader und Hauptprogramm.> Das zusammenfügen und programmieren erledige ich wie auch im ersten> Beitrag oben beschrieben immer noch mit> - Main.hex erzeugen> - Boot.hex erzeugen> - beide .hex-files im Texteditor per Hand zusammenfügen
Meine Güte, wie steinzeitlich. GNU textutils installieren und eine
Kommandozeile aus cat und tail bauen. Alternativ sreccat oder
etwas ähnliches verwenden.
> - neues .hex-file programmieren> - Fuse-Bytes programmieren>> Schöner wäre es natürlich, wenn ich auf Tastendruck direkt beim> Kompilieren/Linken eine gemeinsame Boot+Main.elf erzeugen könnte, die> auch die Fuse-Einstellungen enthält.>> Kennt jemand dafür inzwischen eine Lösung?
Fuses im Programmcode geht seit geraumer Zeit. Verlangt aber, daß man
eine hinreichend neue Version von avrdude zum Brennen verwendet. Die
Fuses kann man dann wahlweise mit dem Bootloader oder mit der
Applikation verheiraten. Der Bootloader erscheint mir aber als die
bessere Wahl.
Was das Zusammenlinken von Bootloader und Hauptprogramm in ein
gemeinsames .elf angeht - das geht, ist aber entschieden nichtrivial.
Die Grundidee wurde oben schon skizziert: man braucht zwei Codesegmente
im Flash und muß einerseits ein angepaßtes Linkerskript verwenden und
andererseits den Code per __attribute() in das jeweilige Segment
plazieren.
Allerdings ist es entschieden nichtrivial, das hinzubekommen. Zumal man
dann einiges an Magie in die Toolchain stecken muß was nicht auf einen
anderen µC portabel ist oder nach einem Update der Toolchain vielleicht
verschwindet.
Die viel einfachere Lösung besteht darin, einfach zwei Flashvorgänge via
ISP vorzunehmen. Im ersten Durchgang macht man ein Chip-Erase und flasht
Bootloader und Fuses. In zweiten Durchgang flash man die Applikation und
darf natürlich kein Chip-Erase machen. Der IDE kann man das wahlweise
in Form eines Makefiles oder eine Skripts beibringen, der Fertiger wird
wohl auch eine Möglichkeit haben, ein Skript auszuführen (als
Alternative zu einem direkten Aufruf von avrdude).
Bernd K. schrieb:> Hier gehts aber ums effiziente Flashen, das hat damit null und nichts zu> tun.
Genauso wie deine und die Beiträge von Thomas E.
Ausser zumüllen habt ihr beide wenig bzw. nichts beigetragen.
Jannyboy schrieb:> Ihr denkt alle viel zu kompliziert.> Klitze kleines C-Programm,
Habe ich ihm schon um 10:11 vorgeschlagen, sein Lieferant war dagegen.
Danach die fruchtlose Diskussion mit beiden Experten bis 13:30.
Hat dann aber ganze 29 Minuten gedauert (13:59) bis er eine Lösung
für sein "Problem" hatte:
Beitrag "Re: AVR Bootloader + Hauptprogramm zusammenfügen"
Die Zeitspanne von 29 Minuten war natürlich unakzeptabel, bei seinem
Lieferanten darf so viel Zeit nicht unnütz vergeudet werden.
Wetten dass sich der TO, sein Lieferant und die beiden Experten nicht
wieder melden ?
Oder falls doch, wird es nur Anspuckerei mit hohlköpfigen Argumenten
sein...
Axel S. schrieb:> Die viel einfachere Lösung besteht darin, einfach zwei Flashvorgänge via> ISP vorzunehmen. Im ersten Durchgang macht man ein Chip-Erase und flasht> Bootloader und Fuses. In zweiten Durchgang flash man die Applikation und
Sein Lieferant scheint dazu nicht imstande zu sein.
Axel S. schrieb:> Allerdings ist es entschieden nichtrivial, das hinzubekommen. Zumal man> dann einiges an Magie in die Toolchain stecken muß was nicht auf einen> anderen µC portabel ist oder nach einem Update der Toolchain vielleicht> verschwindet.
Solange man sich auf relative calls und jumps beschränkt (was man ja
im Bootloaderbereich sowieso tun soll) ist es gefahrlos und 100%
portabel.
Und der Compiler wird sowieso immer relative adressierung vorziehen,
da man ja nicht aus dem Bootloaderbereich rausdarf und der Code
dementsprechend nicht grösser als 2KB ist.
Marc V. schrieb:> Oder falls doch, wird es nur Anspuckerei mit hohlköpfigen Argumenten> sein...
Bisher war ich höflich. Jetzt beginnt die "Anspuckerei":
1. Ich habe um die Lösung für eine konkrete Aufgabenstellung gebeten.
Ich habe mir vorab Gedanken gemacht, warum ich das, was ich tun will,
innerhalb meiner Arbeitsumgebung (die Du nicht kennst), so tun will.
Von Dir kommen aber hauptsächlich Meinungen, warum die Aufgabenstellung
Unsinn wäre. Zugegeben irgendwann ein Lösungsvorschlag mit
Fuse-Definition im Code, der aber für meine Firmware (die Du nicht
kennst), nicht anwendbar ist.
2. Ich habe nie etwas dazu gesagt, was mein Lieferant (den Du nicht
kennst) kann und was nicht. Mir geht es darum meinen Prozess für mich zu
vereinfachen.
3. Alle hier im Thread haben Deinen Aussagen (zu Fertigungstest z.B.)
widersprochen. Liegt das daran, dass die Masse immer so hohlköpfig ist?
Das war jetzt undankbar, ich weiß...
Zur Diskussion:
Stefan K. schrieb:> srec_cat, siehe Doku hier:>> Damit erzeugen wir unsere kombinierten Bootloader-und Applikationsfiles> direkt im makefile, d.h. bei jedem Compilieren fällt auch das> kombinierte File ab.Markus F. schrieb:> GNU objcopy müsste das eigentlich auch können (hab's nie probiert).>> objcopy bootloader.elf --add-section sectionname=application.elf> fat_binary.elf>> sollte das eigentlich hinkriegen.
Ein solcher Befehl im Makefile wäre eine Lösung. Habe dazu allerdings
ein bißchen gegooglet, weder srec_cat noch objcopy können wohl eine .elf
erzeugen, bzw. zwei .elfs kombinieren (das Thema gibt es ja nicht nur
bei AVRs).
PunchBoy schrieb:> Von Dir kommen aber hauptsächlich Meinungen, warum die Aufgabenstellung> Unsinn wäre. Zugegeben irgendwann ein Lösungsvorschlag mit> Fuse-Definition im Code, der aber für meine Firmware (die Du nicht> kennst), nicht anwendbar ist.
Waaas ?
Bist du wirklich so dumm ?
Wo siehst du Fuse-Definition ?
Warum ist das nicht anwendbar ?
Es ist genau das, wonach du (und dein Lieferant) gebeten hast.
Beitrag "Re: AVR Bootloader + Hauptprogramm zusammenfügen"
Was soll da nicht anwendbar sein ?
Oder bist du nur zu dumm, um es zu verstehen ?
Hier noch einmal, ganz langsam, da du offenbar Schwierigkeiten mit
verstehen hast:
PunchBoy schrieb:> 2. Ich habe nie etwas dazu gesagt, was mein Lieferant (den Du nicht> kennst) kann und was nicht.
Du hast verlangt, daß doch bitte alles in einem .elf File sein solle.
Für den Lieferanten. Das läßt darauf schließen daß er (aus welchen
Gründen auch immer) mit zwei .elf Files und evtl. noch einem .hex mit
den Fuses nicht klar kommt.
Ich halte das auch nicht für wahrscheinlich; deswegen mein pragmatischer
Vorschlag, einfach zwei .elf Files nacheinander per ISP zu flashen.
Das ist trivial, das erfordert keine Änderungen am Code und das geht
auch noch, wenn ihr nächstes Jahr auf einen anderen AVR wechseln
solltet.
> Mir geht es darum meinen Prozess für mich zu vereinfachen.
Dann lerne, mit deinen Tools umzugehen. Zu wissen, welchen Button du im
GUI anklicken mußt, damit dein Projekt geflasht wird, ist zu wenig. Du
solltest schon verstehen, was da im Hintergrund passiert und wie du dort
z.B. eine eigene Kommandosequenz hinterlegen kannst.
Wir "Kommandozeilenfrickler" auf die ihr GUI-Typen immer so abschätzig
herabblickt, machen das mit einem Makefile. Das ist leistungsfähig und
elegant. Und eigentlich auch nicht schwer. Man muß halt die Bereitschaft
mitbringen, auch mal was neues zu lernen.
PunchBoy schrieb:> Ein solcher Befehl im Makefile wäre eine Lösung. Habe dazu allerdings> ein bißchen gegooglet, weder srec_cat noch objcopy können wohl eine .elf> erzeugen, bzw. zwei .elfs kombinieren (das Thema gibt es ja nicht nur> bei AVRs).
Das bezweifle ich (ich hab's nämlich - statt zu Googeln - einfach
ausprobiert):
wenn ich ein bl.elf (Bootloader) und ein app.elf (Applikation) habe,
macht
arm-none-eabi-objcopy bl.elf --add-section application=app.elf fat.elf
ziemlich genau das, was ich von ihm erwartet hätte (hängt app.elf als
zusätzliche Section "application" hinten an).
Scheint objcopy ziemlich wurscht zu sein, was bei Google so steht.
Natürlich müssen deine Flash-Tools mit der zusätzlichen Section auch
zurechtkommen, aber dabei kann ich nicht helfen.
Ok, ich bin dann weg. Jetzt wird es nur noch unkonstruktiv und
beleidigend (wie leider die meisten Threads hier). Danke für die
konstruktiven Vorschläge.
Nur noch dazu:
Marc V. schrieb:> Wo siehst du Fuse-Definition ?
Sorry, habe mich vertippt. Habe schon verstanden, dass Du den Funktionen
Code-Bereiche zuweist.
PunchBoy schrieb:> Ok, ich bin dann weg. Jetzt wird es nur noch unkonstruktiv und> beleidigend
Das kann ich verstehen. Das nervt die meisten hier. Und Mark pöbelt hier
öfters so rum - > einfach ignorieren.
Aber Markus sein Beitrag war doch genau das, was Du suchst, probiers
doch einfach mal aus.
Gruß, Stefan
PunchBoy schrieb:> Nur noch dazu:> Marc V. schrieb:>> Wo siehst du Fuse-Definition ?> Sorry, habe mich vertippt. Habe schon verstanden, dass Du den Funktionen> Code-Bereiche zuweist.
Hier:
1
#include<avr/io.h>
2
3
__fuse_t__fuse__attribute__((section(".fuse")))=
4
{
5
.low=LFUSE_DEFAULT,//* Oder welcher Wert auch immer
6
.high=(FUSE_BOOTSZ0&FUSE_BOOTSZ1&FUSE_SPIEN),//* Oder wie auch immer
7
.extended=EFUSE_DEFAULT,//* Oder welcher Wert auch immer
PunchBoy schrieb:> Ich werde es ausprobieren. Danke!
Tu das.
Nichtsdestotrotz in Zukunft deinem Lieferanten .elf mit der von mir
geposteten Lösung schicken.
Pfui.
Stefan K. schrieb:> Das kann ich verstehen. Das nervt die meisten hier. Und Mark pöbelt hier> öfters so rum - > einfach ignorieren.
Fällt mir schwer, sorry...
Ganz ehrlich Marc, ich verstehe Dich nicht (aber mit verstehen habe ich
ja auch Probleme :-)).
Dein Beitrag hier
Marc V. schrieb:> _attribute_ ((section (".myboot")))> //* Das wird beim Reset angesprungen> void bootcode(void) _attribute_ ((section (".myboot")));> // Man kann auch weitere funktionen im Bootloader definieren z.B.> uint8_t testrut(uint8_t lPas) _attribute_ ((section (".myboot")));
...
>> Und dem linker wird die Adresse vorgegeben:> -Wl,--section-start=.myboot=0x0C00 oder wo auch immer du den code haben> willst...
ist ein durchaus sehr sinnvoller Lösungsvorschlag.
(Den ich übrigens nicht so gern umsetzen (und daher auch nicht testen)
möchte, weil ich meinen vorhandenen und recht umfangreichen Code nicht
mehr grundsätzlich anfassen und ändern und testen möchte, sondern nur
noch den Link-Prozess vereinfachen, wenn es EINFACH geht. Die Zeit, die
ich darein stecke, ist Budgetiert).
Deine teilweise wirklich hilfreichen Lösungsvorschläge garnierst Du mit
Beleidigungen und Unterstellungen, so dass man kaum Lust hat, die
Beiträge inhaltlich zu lesen.
Hast Du eigentlich Kunden oder Kollegen, oder, noch schlimmer
Mitarbeiter auf der Arbeit, mit denen Du auch so redest?
PunchBoy schrieb:> Ganz ehrlich Marc, ich verstehe Dich nicht
Und ich verstehe es ganz einfach nicht, wieso du nicht verstehst...
> (Den ich übrigens nicht so gern umsetzen (und daher auch nicht testen)> möchte, weil ich meinen vorhandenen und recht umfangreichen Code nicht> mehr grundsätzlich anfassen und ändern und testen möchte, sondern nur
Deinen Code brauchst du in keiner Weise anzufassen...
Wenn man es dem Linker nicht anders sagt, wird alles in der Sektion
.text (default) ab der Adresse 0x00 aufwärts gelinkt.
Damit du einen funktionierenden Bootloader schreiben kannst, muss
dem Linker mitgeteilt werden, dass die Sektion .text z.B. nach
Adresse 0x7800 verschoben werden soll.
Deswegen hast du aber bei deiner bisherigen Lösung zwei getrennte
Programme, die du jetzt gerne als ein einziges .elf File haben
möchtest, richtig ?
Bei der von mir geposteten Lösung bleibt die Sektion
1
.text// (und das ist die Applikation)
da wo sie ist, du definierst aber zusätzlich eine neue Sektion
1
.myboot// (und das ist der Bootloader)
mit
1
__attribute__((section(".myboot")))
Jetzt brauchst du nur mitzuteilen, dass sich die paar Routinen,
die sich im Bootloader befinden, alle zur Sektion .myboot
gehören.
Also, wird am Programmanfang mit dieser Definition:
dieses auch mitgeteilt.
Natürlich werden anstatt void bootcode etc. alle deine bestehenden
Routinen im Bootloader angeführt - und es können normalerweise nicht
mehr als 4-5 zusätzliche Routinen sein - wenn es mehr sind, stimmt
etwas mit deinem Bootloader nicht. Deine schon bestehenden Routinen
sowohl in der Applikationsektion als auch in der Bootloadersektion
brauchst du weder zu ändern noch überhaupt anzufassen.
Wie du die Fuses setzst, steht hier:
Beitrag "Re: AVR Bootloader + Hauptprogramm zusammenfügen"
Und damit ist schon alles beendet und deine Voraussetzung
will grundsätzlich nicht anfassen und nicht ändern und nicht testen
ist auch erfüllt.
Bleibt nur noch dem Linker mitzuteilen, dass die Sektion .myboot
nach 0x7800 verschoben werden soll und das machst du mit:
1
-Wl,--section-start=.myboot=0x7800
Und damit hast du alles in einem .elf File in einem Durchgang.
Einfacher geht es nicht.
> Die Zeit, die ich darein stecke, ist Budgetiert).
Meine leider nicht.
Marc V. schrieb:> PunchBoy schrieb:>> Ganz ehrlich Marc, ich verstehe Dich nicht>> Und ich verstehe es ganz einfach nicht, wieso du nicht verstehst...>
Sorry, da habe ich mich missverständlich ausgedrückt :-). Deinen
Vorschlag habe ich (auch schon beim ersten Mal) verstanden. Ich verstehe
nur weiterhin nicht, wieso Du kluge Gedanken in unfreundliche Worte
packen musst.
> Deinen Code brauchst du in keiner Weise anzufassen...
Das "in keiner Weise" bezweifle ich wiederum. Ich muss ja (so verstehe
ich die Dokumentation) jeder Funktion und jeder globalen Variable die
Section zuweisen.
Da mein Bootloader doch recht umfangreich ist (sollte nicht so sein, ich
weiß, ist aber der Anwendung und der Historie geschuldet), müsste ich an
mehreren Stellen die Section mit definieren.
Der momentane Bootloader ist getestet und im Einsatz, jede kleine
Änderung am Code ist eine Fehlerquelle. Gerade im Bootloader, der ja,
wie Du oben richtig geschrieben hast, das Herzstück, weil die
Update-Fähigkeit, darstellt.
PunchBoy schrieb:> Das "in keiner Weise" bezweifle ich wiederum. Ich muss ja (so verstehe> ich die Dokumentation) jeder Funktion
Nur denen, die sich im Bootloader befinden. Man nimmt den Namen der
Funktion, kopiert diese eine Zeile nach oben und fügt den Namen der
Sektion dazu.
Nennt sich Copy&Paste
> und jeder globalen Variable die Section zuweisen.
Was haben Variablen mit Flash zu tun ?
PunchBoy schrieb:> Da mein Bootloader doch recht umfangreich ist (sollte nicht so sein, ich> weiß, ist aber der Anwendung und der Historie geschuldet), müsste ich an> mehreren Stellen die Section mit definieren.
Nein.
Marc V. schrieb:> Was haben Variablen mit Flash zu tun ?>> PunchBoy schrieb:>> müsste ich an mehreren Stellen die Section mit definieren.>> Nein.
Variablen haben mit dem Flash nichts zu tun, da war ich gedanklich
falsch unterwegs. Der Gedanke kam daher, dass ein paar Daten (natürlich
nicht Variablen) per PROGMEM im Flash abliegen.
Diesen Daten müsste ich, genau wie jeder einzelnen Funktion, die Section
zuweisen.
Es ist aber, wie gesagt, eine gute Lösung. Ich werde mir überlegen, ob
mir die Vereinfachung beim Linken das (geringe) Risiko wert ist, damit
noch einen Fehler einzubauen.
Zusammen mit Markus F.s
> arm-none-eabi-objcopy bl.elf --add-section application=app.elf fat.elf
habe ich damit zwei gute Lösungswege.
Danke für die Diskussion.
Die ich damit nicht schließen möchte, falls jemand noch eine andere Idee
hat :-)
Thread beobachten
Seitenaufteilung abschalten