Forum: Compiler & IDEs HEX File, Anzahl der bytes pro Zeile ändern.


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von A. F. (artur-f) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?

von Anonym (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Warum nimmst du nicht einfach eine Binärdatei und schickst immer genau 
so viele Bytes auf einmal wie du willst?

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Anonym (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Weil ein Hexfile weniger fehleranfällig und vielseitiger ist, da es auch
> die Adressen beinhaltet.

Supernützlich für einen STM32.

von Nop (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von A. F. (artur-f) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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/

von Anonym (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Anonym (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von A. F. (artur-f) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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...

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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".

von A. F. (artur-f) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
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
von A. F. (artur-f) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.....

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von A. F. (artur-f) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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:
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
von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von A. F. (artur-f) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
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)

von Nop (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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."

von A. F. (artur-f) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.