Hallo,
ich bin auf der suche nach einem Hex Editor, mit dem es möglich ist aus
zwei hex Files ein hex file zusammen zu bauen.
Anwendung:
Firmware AVR Controller Atmega 168, 328 verschiedene Ausführungen bei
denen der Bootloader angehängt werden soll, so das aus den zwei hex
Files eines entsteht.
Ein Hex Editor der in zwei Instanzen verwendet werden kann, oder ein
Editor der zwei Editor Bereiche hat, wäre die Lösung dafür.
Zur Zeit mache ich das mit der Software des TL866, hier kann man die
Software zwei mal starten und von einer Instanz zur anderen kopieren.
Copy von Adresse bis Adresse, bzw. Bereich und Einfügen ab Adresse.
Welche hex Editoren gibt es dafür.
Der Editor sollte mit Windows 10 funktionieren.
Du kannst doch auch die .hex files nacheinander flashen.
Ich hab auch etliche Zeit drüber nachgedacht wie ich mir da was basteln
kann damit das eine Datei ist, bis ich irgendwann ganz pragmatisch
beschlossen habe in Zukunft einfach nur immer beide hex in einen Ordner
zu werfen und dann noch ein passendes Batchfile dazu das beides flasht
und auch gleich die Fuses setzt. Derjenige der das dann nutzt muss nur
den Ordner öffnen und das Batchfile starten, fertig. Null Aufwand,
maximales Ergebnis.
Bernd K. schrieb:> Du kannst doch auch die .hex files nacheinander flashen.
So sieht's aus. Aber natürlich darf man nicht vergessen, das
normalerweise implizite Chip-Erase für den zweiten Flash-Vorgang
abzuschalten...
Milka_Bitter schrieb:> Zur Zeit mache ich das mit der Software des TL866, hier kann man die> Software zwei mal starten und von einer Instanz zur anderen kopieren.> Copy von Adresse bis Adresse, bzw. Bereich und Einfügen ab Adresse.
Geht doch!
Ich kenne deine Soft nicht, aber bei allen Programmern, die ich kenne,
konnte man nacheinander HEX auf bestimmte Adressen laden.
Irgendwann gab es einen Hexeditor, wo man zwei Files laden konnte und
dann vergleichen.
Ich sehe aber keinen Sinn für deine Wünsche.
Für HEX-Files braucht man keinen speziellen Editor. Notepad ist völlig
ausreichend. Beide Files zusammenkopieren (copy file1.hex,file2.hex
file.hex) und dann mit Notepad die eine EOF-Marke (:00000001FF) löschen.
Fertig.
michael_ schrieb:> Ich kenne deine Soft nicht, aber bei allen Programmern, die ich kenne,> konnte man nacheinander HEX auf bestimmte Adressen laden.>> Irgendwann gab es einen Hexeditor, wo man zwei Files laden konnte und> dann vergleichen.
Die Software brauchst auch nicht kennen, es geht nur um die Hex Files.
Das mit der Programmer Software des TL866 funktioniert auch so weit, ist
aber nicht ganz nicht ganz so komfortabel wie es sein könnte. Fernost
Software eben.
Ich dachte an die Möglichkeit, an ein geöffnetes Hex File, ein zweites
Hex File ab Adresse xxxx anzuhängen.
Aber wenn es so was nicht gibt mache ich es eben mit copy paste wie
gehabt.
Georg G. schrieb:> dann mit Notepad die eine EOF-Marke (:00000001FF) löschen.> Fertig.
Am Ende kommt doch immer noch eine Prüfsumme, wird die nicht gebraucht?
> Ich dachte an die Möglichkeit, an ein geöffnetes Hex File,> ein zweites Hex File ab Adresse xxxx anzuhängen.
Hex Files enthalten Adressen. Wie ist das beim Bootloader, muss man da
dann noch einen Offset addieren, oder steht der schon korrekt im Hex
File drin?
Milka_Bitter schrieb:> Das mit der Programmer Software des TL866 funktioniert auch so weit, ist> aber nicht ganz nicht ganz so komfortabel wie es sein könnte. Fernost> Software eben.
Hat das Programm einen Namen?
Oder einen Link?
Ich habe hier Khazama und eXtreme-burner AVR, da geht das auch nicht.
Aber bei meinem TopWin 3.0 geht das.
Das Programm läuft auch ohne Programmer.
michael_ schrieb:> Hat das Programm einen Namen?
Der TL866 ist der weit verbreitete Universal Programmer.
So eine Art GALEP.
Eine Suche nach TL866 Programmer bringt dir sicher viele Ergebnisse,
auch den Link zum Hersteller aus China.
Der Programmer ist auch für die AVR Controller gut geeignet wenn man die
Ausführung mit dem ISP Port hat.
Die Software kann auch ohne Programmer Hardware verwendet werden, um
z.B. die HEX Files zu bearbeiten.
Stefanus F. schrieb:> Georg G. schrieb:>> dann mit Notepad die eine EOF-Marke (:00000001FF) löschen.>> Fertig.>> Am Ende kommt doch immer noch eine Prüfsumme, wird die nicht gebraucht?
Doch, jeweils für die Zeile.
Und welche Adressen dort für die Zeilen angegeben sind ist doch vom
Erzeuger abhängig.
Ob ein Bootloader die nun auswertet oder auch noch umrechnet ist Sache
des Bootloaderprogrammierer.
Wenn die Adressen sauber im hex-file drin stehen, der PC das
entsprechend weiter reicht braucht der Bootloader das doch nur
entsprechend umsetzen.
Der Riesenvorteil vom Intelhex ist doch das alle zulässigen Zeichen mit
jedem Editor dargestellt werden können.
Somit ist der Lieblingseditor gut geeignet.
Georg G. schrieb:> Für HEX-Files braucht man keinen speziellen Editor. Notepad ist völlig> ausreichend. Beide Files zusammenkopieren (copy file1.hex,file2.hex> file.hex) und dann mit Notepad die eine EOF-Marke (:00000001FF) löschen.> Fertig.
LOL. Genau so.
Es kann sowieso nicht vorkommen, dass sich die Adressen überlappen.
Stefanus F. schrieb:> Am Ende kommt doch immer noch eine Prüfsumme, wird die nicht gebraucht?
Nein, es kommt keine Prüfsumme am Ende, jede Zeile hat eine eigene
Prüfsumme.
Marc V. schrieb:> Nein, es kommt keine Prüfsumme am Ende, jede Zeile hat eine eigene> Prüfsumme.
Ah Ok, dann hatte ich das missverstanden. Da es nun so ist, würde ich
die Dateien einfach zusammen kopieren. Diese eine Zeile wegschneiden ist
mit Linux Boardmitteln (unter Windows mit CygWin) kein Kinderspiel.
Stefanus F. schrieb:> die Dateien einfach zusammen kopieren. Diese eine Zeile wegschneiden ist> mit Linux Boardmitteln (unter Windows mit CygWin) kein Kinderspiel.
Kein Kinderspiel oder ein Kinderspiel?
Marc V. schrieb:> Stefanus F. schrieb:>> die Dateien einfach zusammen kopieren. Diese eine Zeile wegschneiden ist>> mit Linux Boardmitteln (unter Windows mit CygWin) kein Kinderspiel.>> Kein Kinderspiel oder ein Kinderspiel?
Upps: ein Kinderspiel.
Die Bezeichnung HEX-editor ist nicht eindeutig. Hier sollen anscheinend
Daten im Intel-Hex-Format zusammengebunden werden. Mit einem
"Hex-Editor" z.B. HxD (Windows) oder ghex (Linux) werden normalerweise
Dateien als hexadezimale Zahlen dargestellt und editiert.
Jedec-Files für CPLDs haben am Ende eine Gesamt-Prüfsumme, die darf man
nicht einfach aneinanderhängen. Für Intel-Hex gilt das anscheinend
nicht.
https://de.wikipedia.org/wiki/Intel_HEX
Die Zeilen heißen hier "Datensatz" und eine Prüfsumme gilt immer nur für
eine Zeile.
Auch das Intel-Hex-Format schreibt in jede Zeile, wo im Speicher diese
Zeile liegen soll (absolute Adressen), wie Stefanus schon schrieb. Vor
dem einfachen Aneinanderhängen muss klar sein, dass keine Adressbereiche
doppelt belegt werden.
Geht das ganze überhaupt?
Ein Hex-File ist zwar eine Textdatei, enthält aber keine Strukturen wie:
1. Kapitel und 2. Kapitel.
Normalerweise enthalten Hex-Dateien Programmadressen in jeder Zeile.
Prinzipiell können diese in beiden Dateien Duplikate enthalten. Keine
Ahnung was ein Programmer in diesem Falle macht.
Marc V. schrieb:> LOL. Genau so.> Es kann sowieso nicht vorkommen, dass sich die Adressen überlappen.
Das kann schon vorkommen, z.B. wenn man das .OVERLAP-Feature des
Atmel-Assemblers nutzt.
Das Verhalten in diesem Fall ist aber eindeutig geregelt: wer zuletzt
kommt, gewinnt.
So löst sich auch das Problem ganz einfach, wenn App und Bootloader Code
sharen, was durchaus sinnvoll sein kann, um Flash zu sparen (für
Bootlader, die nichttriviale Datenquellen benutzen).
Der shared Code überlappt dann zwar, ist aber im Überlappungsbereich
identisch, so dass es nichtmal eine Rolle spielt, in welcher Reihenfolge
die beiden Dateien zusammengebaut werden.
Sebastian S. schrieb:> Ein Hex-File ist zwar eine Textdatei, enthält aber keine Strukturen wie:> 1. Kapitel und 2. Kapitel.
Doch.
Jede Zeile ist ein Datensatz, und jeder Datensatz beginnt mit einer
Adresse, dem Typ (Kapitel) und endet mit einer Prüfsumme.
Sebastian S. schrieb:> Geht das ganze überhaupt?
Ja.
> Ein Hex-File ist zwar eine Textdatei, enthält aber keine Strukturen wie:> 1. Kapitel und 2. Kapitel.
Doch.
> Normalerweise enthalten Hex-Dateien Programmadressen in jeder Zeile.
Diese Adressen sind nur der Offset im jeweiligen "Segment". Genau diese
Segmente sind die übergeordnete Verwaltungsinstanz. Es gibt sie in zwei
Spielarten, als echte Segmente im Sinne des Intel-x86-segmented
Speichermodells, aber auch als lineare Adressen.
Sogar schon beim AVR8 bekommt man es mit diesen Offsets zu tun. Nämlich
bei allen AVR8 mit Flash>64k. Der Bootloader liegt dort nämlich im
zweiten Segment...
> Prinzipiell können diese in beiden Dateien Duplikate enthalten. Keine> Ahnung was ein Programmer in diesem Falle macht.
Wenn er dem Standard folgt, nimmt er das zuletzt im File erscheinende
Datum.
Christoph db1uq K. schrieb:> Auch das Intel-Hex-Format schreibt in jede Zeile, wo im Speicher diese> Zeile liegen soll (absolute Adressen), wie Stefanus schon schrieb. Vor> dem einfachen Aneinanderhängen muss klar sein, dass keine Adressbereiche> doppelt belegt werden.
Das ist so nicht korrekt.
Es gibt Zeilen die beinhalten nur Daten, max 16 Bytes, da ist kein Platz
für eine Adresse.
c-hater schrieb:> Marc V. schrieb:>>> LOL. Genau so.>> Es kann sowieso nicht vorkommen, dass sich die Adressen überlappen.>> Das kann schon vorkommen, z.B. wenn man das .OVERLAP-Feature des> Atmel-Assemblers nutzt.
Das setzt aber voraus, dass beide (App und BL) zur gleichen Zeit
und in einem File compiliert werden und das ist fast niemals der Fall.
>> Der shared Code überlappt dann zwar, ist aber im Überlappungsbereich> identisch, so dass es nichtmal eine Rolle spielt, in welcher Reihenfolge> die beiden Dateien zusammengebaut werden.
In zwei verschiedenen Assembler Dateien .overlap auf selbe Adresse zu
setzen ist einfach sinnlos.
.OVERLAP dient nur dazu, Compilerwarnungen bzw. Errors zu vermeiden,
der Compiler wird aber niemals (und kann nicht) einen solchen Fehler
bei 2 getrennten Dateien melden.
P.S.
Die Option Bootloader zusammen mit App zu laden, habe ich in meinem
Prommer schon ewig, noch nie Probleme damit gehabt.
Macht genau das, was weiter oben beschrieben wurde, nämlich die
EOF Markierung aus dem ersten File zu entfernen und die beiden Dateien
dann einfach zusammenzufügen und zu flashen.
NichtWichtig schrieb:> Es gibt Zeilen die beinhalten nur Daten, max 16 Bytes, da ist kein Platz> für eine Adresse.
Falsch. Sieh dir bitte die Definition des Intel-HEX Formates an. Jeder
Datenrecord (Typ 0) enthält die Ladeadresse.
Nicht 16 Byte Nutzdaten, sondern soweit ich sehe sind 255 Byte pro Zeile
möglich. (Null Byte ist erlaubt) Dann ist es auch sinnvoll nicht mehr
von Zeilen zu sprechen.
Die Adresse ist in jeder Zeile maximal 32 Bit lang, kann also nur 64k
umfassen. Für 16- und 32-Bit CPUs wurde die Norm erweitert.
Christoph db1uq K. schrieb:> Die Bezeichnung HEX-editor ist nicht eindeutig. Hier sollen anscheinend> Daten im Intel-Hex-Format zusammengebunden werden.
Deshalb habe ich am Anfang beschrieben was ich damit machen möchte.
So mit sollte die Frage schon eindeutig sein.
Leider wurde das Thema etwas zerrissen mit der Meinung, es kann jeder
Editor dafür verwendet werden, was natürlich Unsinn ist.
Ich bleib einfach bei dem Editor des TL866.
Milka_Bitter schrieb:> Leider wurde das Thema etwas zerrissen mit der Meinung, es kann jeder> Editor dafür verwendet werden, was natürlich Unsinn ist.Das ist Unsinn.
Warum sollte es nicht gehen? Zeige doch mal deine beiden hex Dateien,
dann für ich sie dir mit einem Texteditor zusammen.
Milka_Bitter schrieb:> Leider wurde das Thema etwas zerrissen mit der Meinung, es kann jeder> Editor dafür verwendet werden, was natürlich Unsinn ist.
Ein Hexfile ist eine Textdatei aus ASCII-Zeichen. Die kann mit jedem
Editor, der ASCII-Zeichen darstellen kann, bearbeitet werden. Dazu
gehört auch das Einfügen von Text aus einer anderen Datei.
Georg G. schrieb:> NichtWichtig schrieb:>> Es gibt Zeilen die beinhalten nur Daten, max 16 Bytes, da ist kein Platz>> für eine Adresse.>> Falsch. Sieh dir bitte die Definition des Intel-HEX Formates an. Jeder> Datenrecord (Typ 0) enthält die Ladeadresse.
Ups, vollkommen korrekt. Sorry!
Ich habe zu lange nix mehr damit gemacht und stolper aktuell exakt über
das Problem.
Der Offset im Segent ist vorhanden.
Meine DIY Software verkackt beim 128KB IntelHex file für den BluePill.
Da muß ich nochmal in alten VisualStudio-Zeugs nachbessern.
Waren beim ollen AVRTiny44 oder 89S8252 das noch unsichtbare bugs fällt
es nun beim BluePill mit 128KB auf sobald man die ersten 64K
überschreitet.
Jetzt brauche ich ein 128kB file was ab 0x08000000 gespeichert wird.
Georg G. schrieb:> NichtWichtig schrieb:>> Es gibt Zeilen die beinhalten nur Daten, max 16 Bytes, da ist kein Platz>> für eine Adresse.>> Falsch. Sieh dir bitte die Definition des Intel-HEX Formates an. Jeder> Datenrecord (Typ 0) enthält die Ladeadresse.
Bei so einer Prozedur wie vom TO sollte man sich ganz schnell vom
Intel-hex verabschieden.
Natürlich sind dort Adress-Informationen enthalten.
Also nach xxx.hex/bin konvertieren.
Milka_Bitter schrieb:> michael_ schrieb:>> Hat das Programm einen Namen?>> Der TL866 ist der weit verbreitete Universal Programmer.> So eine Art GALEP.> Eine Suche nach TL866 Programmer bringt dir sicher viele Ergebnisse,> auch den Link zum Hersteller aus China.> Der Programmer ist auch für die AVR Controller gut geeignet wenn man die> Ausführung mit dem ISP Port hat.
Bist du nicht in der Lage zu liefern?
Ich soll für dich mich durchs Internet zu wühlen?
Bist du nicht in der Lage zu zitieren, was in der oberen Zeile deiner
Soft steht?
Hat mich zwar angestunken, aber ich habe mir mal die Arbeit gemacht.
Nach mehreren/vielen Angeboten zum TL866 habe ich diese Soft gefunden
und zum Test installiert.
Xgpro v8.51
www.autoelectric.xx/EN/TL866_MAIN.html
Die Forensoft meckert.
Der Beitrag scheint Spam zu enthalten: "xx"
Wer Mut hat, ersetzt das xx durch cn.
Und dort kann man beim Einlesen zwischen Intel.hex und ...hex auswählen.
Und den Speicherbereich auch auswählen.
Was will man mehr!
Oder hast du eine andere Soft?
