Hi Leute, um FW Update vom STM32 via I2C bootloader zu beschleunigen (mein eigener BL), suche ich die Möglichkeit die Bytelänge vom HEX File zu verändern. GCC spuckt mir 16 Byte records aus. Ich habe einen Trick gefunden, wenn ich den uC programmiere und mit ST-Link Utility auslese, kann ich die gleiche HEX Datei mit einer Länge von 32 bytes / Zeile abspeichern. Mein I2C transfer würde aber auch 64 oder mehr erlauben. Gibt es bestimmte Tools (windows) die in der Lage sind HEX files in der Hinsicht zu manipulieren?
Warum nimmst du nicht einfach eine Binärdatei und schickst immer genau so viele Bytes auf einmal wie du willst?
Anonym schrieb: > Warum nimmst du nicht einfach eine Binärdatei und schickst immer > genau so viele Bytes auf einmal wie du willst? Weil ein Hexfile weniger fehleranfällig und vielseitiger ist, da es auch die Adressen beinhaltet.
Nop schrieb: > Weil ein Hexfile weniger fehleranfällig und vielseitiger ist, da es auch > die Adressen beinhaltet. Supernützlich für einen STM32.
Anonym schrieb: > Supernützlich für einen STM32. Genau, denn der Bootloader sollte nach Auslieferung tunlichst nicht mehr geändert werden. Allerdings kann man z.B. mehrere Applikationsvarianten an verschiedene Stellen laden, oder man lädt auch nur Datenbereiche neu. Das geht alles ohne Probleme, wenn man von vornherein auf Hexfiles setzt.
Anonym schrieb: > Warum nimmst du nicht einfach eine Binärdatei und schickst immer > genau > so viele Bytes auf einmal wie du willst? Es gibt einige Grüde warum ich bei HEX bleiben möchte. Habe damals bei meiner Betrachnung nur die 400Khz vom I2C mehr oder weniger im Blick gehabt und nicht die Flash-Schreibvorgänge, die bei jedem Buffer-write 5ms schlucken......Vergrößert man die Packenlänge, verkleinert man die Anzahl der Schreibvorgänge. Dem BL ist egal, ob ich 4 oder 64 Bytes schicke, deshalb bin ich auf der Suche nach einer Software, die in der Lage ist HEX Files zu manipulierne. Bevor ich meine PC Software anpasse, wollte ich schauen ob was für dieses Vorhaben existiert.
A. F. schrieb: > Bevor ich meine > PC Software anpasse, wollte ich schauen ob was für dieses Vorhaben > existiert. Vielleicht ist Srecord was? Hier für Windows: https://sourceforge.net/projects/srecord/files/srecord-win32/
A. F. schrieb: > Dem BL ist egal, ob ich > 4 oder 64 Bytes schicke, deshalb bin ich auf der Suche nach einer > Software, die in der Lage ist HEX Files zu manipulierne. Bevor ich meine > PC Software anpasse, wollte ich schauen ob was für dieses Vorhaben > existiert. Das Vorgehen finde ich etwas komisch, du schickst die Daten ja auch nicht als ASCII-Hex über den I2C, warum sollte also die Zeilenaufteilung der HEX-Datei dir da Vorgaben machen? Wenn deine PC-Software besondere Anforderungen an die HEX-Datei stellen muss, dann ist das doch Mist. Dann lies lieber so viele Bytes aus der Datei wie du auf ein Mal schreiben willst, unabhängig von der Zeilenlänge.
Anonym schrieb: > Dann lies lieber so viele Bytes aus der Datei wie du auf ein Mal > schreiben willst, unabhängig von der Zeilenlänge. Das wäre die sauberste Lösung, sofern der Bootloader noch geändert werden kann bzw. dafür noch Zeit ist. Allerdings ist das einiger Aufwand mit der sauberen Erkennung, weil Hexfiles auch Lücken haben dürfen.
Nop schrieb: > Das wäre die sauberste Lösung, sofern der Bootloader noch geändert > werden kann bzw. dafür noch Zeit ist. Wieso muss der Bootloader geändert werden? Der ist ja scheinbar in der Lage, mehr Daten anzunehmen. Das Problem scheint ja auf PC-Seite zu liegen. Nop schrieb: > Allerdings ist das einiger Aufwand mit der sauberen Erkennung, weil > Hexfiles auch Lücken haben dürfen. "einiger Aufwand" ist es mit den HEX-Files sowieso, allein schon weil man auch nur Page-weise den Flash löschen kann und das HEX dann auch immer ganze Pages enthalten muss. Wahrscheinlich wäre es sinnvoller, immer eine ganze Page auszulesen und zu buffern.
Anonym schrieb: > Wieso muss der Bootloader geändert werden? Weil der offensichtlich das Zeilenende als Schreibtrigger ansieht. > "einiger Aufwand" ist es mit den HEX-Files sowieso, allein schon weil > man auch nur Page-weise den Flash löschen kann Löschen ja. > und das HEX dann auch immer ganze Pages enthalten muss. Nö, denn schreiben geht ja byteweise. Es dürfen aber Lücken im Hexfile sein, die dann nach dem Löschen des Flashs auf FF stehen werden. Die Adressen müssen nichtmal in aufsteigender Ordnung sein. Allerdings können innerhalb einer Datenzeile keine Lücken auftreten. Da muß der Bootloader also nur zusehen, daß nicht gerade eine Pagegrenze überschritten wird.
Nop schrieb: > Vielleicht ist Srecord was? Hier für Windows: > https://sourceforge.net/projects/srecord/files/srecord-win32/ Habe ich zuvor schon angeschaut, jedoch nicht gesehen, dass es dafür geht. Anonym schrieb: > Das Vorgehen finde ich etwas komisch, du schickst die Daten ja auch > nicht als ASCII-Hex über den I2C, warum sollte also die Zeilenaufteilung > der HEX-Datei dir da Vorgaben machen? Wenn deine PC-Software besondere > Anforderungen an die HEX-Datei stellen muss, dann ist das doch Mist. > Dann lies lieber so viele Bytes aus der Datei wie du auf ein Mal > schreiben willst, unabhängig von der Zeilenlänge. Macht meine PC Software nicht. Die macht Parsing der HEX Datei so wie die ist: Adresse, Packetlänge, Daten, Checkbyte. Nop schrieb: > Das wäre die sauberste Lösung, sofern der Bootloader noch geändert > werden kann bzw. dafür noch Zeit ist. Wurde noch nicht ausgeliefert, an sich schon möglich... > Allerdings ist das einiger Aufwand mit der sauberen Erkennung, weil > Hexfiles auch Lücken haben dürfen. Genau ist es, mehr Aufwand und fehleranfälliger, aber nicht unmöglich...
A. F. schrieb: > Habe ich zuvor schon angeschaut, jedoch nicht gesehen, dass es dafür > geht. Du kannst auf jeden Fall die Länge der Datenzeilen bei der Ausgabe einstellen. IIRC ist die sogar per default auf 32. Ansonsten mak hier gucken: http://srecord.sourceforge.net/man/man1/srec_examples.html#CONVERTING FILE FORMATS Und etwas runterscrollen zu "Output Block Size".
Nop schrieb: > http://srecord.sourceforge.net/man/man1/srec_examples.html#CONVERTING > FILE FORMATS > > Und etwas runterscrollen zu "Output Block Size". Schön, Danke! Habe ich tatsächlich übersehen. Werde es ausprobieren.
A. F. schrieb: > Vergrößert man die Packenlänge, > verkleinert man die Anzahl der Schreibvorgänge. Aber nur wenn der Bootloader zu blöd ist selber zu puffern. Ein STM32 sollte eigentlich mehr als genug RAM haben um eine Flash Page zischenspeichern zu können. Das wäre dann effizienter und vermutlich auch sehr viel schneller.
Das müsste eigentlich mit Bordmitteln gehen. Der gcc erzeugt ja keine srec sondern elf. Normal konvertiert dann (arm-none-eabi)-objcopy elf zu srec. An der Stelle kann man mit "--srec-len=n" die Zeilenlänge angeben. "--srec-forceS3" möchte man evt. auch. Der Befehl müsste sowieso irgendwo im Makefile versteckt sein.
:
Bearbeitet durch User
Jim M. schrieb: > Aber nur wenn der Bootloader zu blöd ist selber zu puffern. Ein STM32 > sollte eigentlich mehr als genug RAM haben um eine Flash Page > zischenspeichern zu können. Das wäre dann effizienter und vermutlich > auch sehr viel schneller. Der Empfangsbuffer vom BL erlaubt 128 Byte Nutzdaten, BL selbst muss möglichst unkompöliziert gehalten werden. Was ich machen könnte, die PC Software schlauer machen, in dem ich die Daten nicht zeilenweise schicke sondern den ganzen BL Empfangsbuffer ausnutze. Werde ich Mal in machen.....
Bauform B. schrieb: > Das müsste eigentlich mit Bordmitteln gehen. Der gcc erzeugt ja > keine srec Es geht aber um Intel-Hexfiles, nicht Motorola-S19.
Habe nach ein wenig "Fummelarbeit" es hinbekommen hex files mit 64 byte payload / Zeile zu erzeugen. FW Update via I2C BL läuft nun wesentlich schneller. Hier eine kleine Anleitung: 1) von Atolic Studio HEX zu eurem Projekt erzeugen lassen. 2) Bei Build Optionen: post-build steps -> command folgendes einfügen:
1 | srec_cat PROJEKT.hex -intel -o PROJEKT_longline.hex -intel -line-length=140 |
3) srec_cat.exe in den arm-atollic-eabi Ordner kopieren So wird bei jedem build Vorgang aus der PROJEKT.hex Datei eine PROJEKT_longline.hex erzeugt mit 64 Byte payload / Zeile. Für 128 Byte payload: -line-length=268 Jetzt läuft mein Update mit ca. 1k Bytes pro Sekunde, geil :) Danke euch und ein extra Dank an den Nop für den Hinweis.
:
Bearbeitet durch User
A. F. schrieb: > Hi Leute, um FW Update vom STM32 via I2C bootloader zu beschleunigen > (mein eigener BL), suche ich die Möglichkeit die Bytelänge vom HEX File > zu verändern. Und wieso sollte dein Update dann schneller gehen? Weil du eine handvoll ASCII-Zeichen für den Header der Zeile sparst? Schon mal den Overhead ausgerechnet? Lohnt sich das.
A. F. schrieb: > Habe nach ein wenig "Fummelarbeit" es hinbekommen hex files mit 64 byte > payload / Zeile zu erzeugen. FW Update via I2C BL läuft nun wesentlich > schneller. Ein normales HEX-File mit 16 Bytes/Zeile hat 44 ASCII-Zeichen, davon sind 12 Overhead, macht 32/44 = 72% Nutzlast. Bei 64 Bytes / Zeile sind es 64 / 72 = 88%. Macht ca. Faktor 1,2 höhere Geschwindigkeit. Das ist für dich "wesentlich" schneller?
Falk B. schrieb: > Und wieso sollte dein Update dann schneller gehen? Erst lesen, dann posten. Beitrag "Re: HEX File, Anzahl der bytes pro Zeile ändern." Beitrag "Re: HEX File, Anzahl der bytes pro Zeile ändern."
Falk B. schrieb: > Und wieso sollte dein Update dann schneller gehen Hi Falk, die Pagegröße vom uC ist 128 byte, der Empfangsbuffer des BL's ebenfalls. Mein BL ließt erst die vorhandenen Daten der Page ein, ändert die betroffenen Bytes, löscht die Page und schreibt die Daten. Schicke ich in einem I2C Packet 128 Bytes passiert das Löschen und schreiben ein Mal. Bei 16 Bytes Payload ganze 8 mal. Dazu kommt der restliche verarbeitende Teil der minimal auch zusätliche Zeit kostet.
A. F. schrieb: > Hi Falk, > die Pagegröße vom uC ist 128 byte, der Empfangsbuffer des BL's > ebenfalls. > Mein BL ließt erst die vorhandenen Daten der Page ein, ändert die > betroffenen Bytes, löscht die Page und schreibt die Daten. Schicke ich > in einem I2C Packet 128 Bytes passiert das Löschen und schreiben ein > Mal. Bei 16 Bytes Payload ganze 8 mal. Dazu kommt der restliche > verarbeitende Teil der minimal auch zusätliche Zeit kostet. Und er hindert dich daran, auch mit einem 16 Byte/Zeile HEX-File 4 Zeilen einzulesen und dann erst in den Flash zu schreiben. Bei lausigen 400kHz I2C Datenrate ist der CPU-Overhead vollkommen nebensächlich. Und nochmal die Frage. Wieviel schneller ist dein Update REAL geworden? (Nicht nur gefühlt)
Falk B. schrieb: > Und er hindert dich daran, auch mit einem 16 Byte/Zeile HEX-File 4 > Zeilen einzulesen und dann erst in den Flash zu schreiben. Zu doof, um den Thread erstmal zu lesen? Das hatten wir alles schon. Beitrag "Re: HEX File, Anzahl der bytes pro Zeile ändern."
Falk B. schrieb: > Und er hindert dich daran, auch mit einem 16 Byte/Zeile HEX-File 4 > Zeilen einzulesen und dann erst in den Flash zu schreiben. Meine Faultheit, glaube ich. Falk B. schrieb: > Und nochmal die Frage. Wieviel schneller ist dein Update REAL geworden? > (Nicht nur gefühlt) ~8 Mal schneller.
:
Bearbeitet durch User
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.