Hallo, weiß jemand, ob man die Speicherbreite beim Schreiben von Intel_HEX files einstellen kann? Mit dem AVR-Studio bekomme ich 0x10 bytes pro Zeile: :1000000028632920323031352D3230313620736566 :100010007276612D74732E636F6D00FF0C4D8B5DD6 mit AVRDUDE dagegen 0x20 bytes pro Zeile: :2000000028632920323031352D323031362073657276612D74732E636F6D00FF2E3D415 988 :2000200043424C304130303537393234323031370000018E00000176000049E20000490 2CD Grüße, Achim
Achim schrieb: > weiß jemand, ob man die Speicherbreite beim Schreiben von Intel_HEX > files einstellen kann? Ja, ich. :-) Nein, kannst du nicht. Also zumindest nicht, ohne das alles selbst zu modifizieren und neu zu compilieren. Warum willst du das tun?
srec_cat sollte sowas können. Das wird auch von Microchip Studio mit angeschleppt (...Atmel\Studio\7.0\shellutils\srec_cat.exe). Ob Du mit neu compilieren schneller bist als mit Durchlesen und kapieren der Anleitung zu srec_cat, kann ich allerdings nicht sagen.
Da das Format öffentlich ausliegt, sollte es doch möglich sein, mit recht schlichten Mitteln, einen Konverter zu bauen.
Vielen Dank für die schnellen Antworten! Ich wollte es einheitlich mit AVR-Studio, weil ich das EEPROM-File selber Parse / erstelle. Dann werde ich das einfach in meiner Software variabel gestalten... Grüße, Achim
Die Frage ist ja wirklich, wofür man das braucht. Wenn es nur zum Vergleich der Binärdaten ist, dann wäre es wohl sinnvoller, einfach beide in reine Binärdateien zu wandeln und zu vergleichen.
Achim schrieb: > Dann werde ich das einfach in meiner Software variabel gestalten... Wenn man "Intel hex" einlesen können möchte, ist es immer eine gute Idee, wenn man sich an die Formatspezifikation hält und alles verkraftet, was dieser entspricht. ;-)
Achim schrieb: > Ich wollte es einheitlich mit AVR-Studio, weil ich das EEPROM-File > selber Parse / erstelle. Dann erstelle es als binary und lasse es in hex konvertieren. Wer erstellt bitte direkt hex? Das ist doof. Und fürs parsen gilt was Jörg schon sagte: Erstelle den Parser so dass es laut Spec funktioniert, oder konvertiere vorher in bin, wenn du das parsen nicht sauber hinbekommst.
:
Bearbeitet durch User
Achim schrieb: > weil ich das EEPROM-File > selber Parse / erstelle. Dann sollte der Parser mit 1..255 Datenbytes je Zeile klarkommen.
Falls du die Dateien aber vergleichen willst hilft das srec_cat Tool. Damit kannst du s19/ihex etc hin und her konvertieren, Füllen, Abschneiden etc. aber auch einfach die Länge einer Intel-Hex Zeile ändern. Von 32Byte Daten zu 64Byte pro Zeile: srec_cat dump.hex -intel -output dump_formatx.hex -intel -line-length=76 Von 64Byte Daten zu 32Byte pro Zeile: srec_cat dump.hex -intel -output dump_formatx.hex -intel -line-length=44
Cyblord -. schrieb: > Dann erstelle es als binary und lasse es in hex konvertieren. Wer > erstellt bitte direkt hex? Das ist doof. Sicher ? Intel Hex kann Informationen speichern, die ein .bin so nicht enthält. Damit meine ich jetzt nicht die kaum genutzte Programmstartadresse. Die Prüfsumme pro Zeile kann auch nur grobe Schnitzer abfangen. Aber zum Besipiel sind mit Intel Hex oder Motorola Srec Speicherbereiche möglich, denen kein Wert zugewiesen wird. Bei 2 GB Adressraum mag man u.U. nicht alles mit 0x00 füllen bevor es endlich los/weiter geht. Wenn die Werte in der Datei ab Adresse 0 abzulegen sind und keine Lücken beinhalten, ist eine .hex-Datei halt mehr als doppelt so groß.
FOp schrieb: > Aber zum Besipiel sind mit Intel Hex oder Motorola Srec Speicherbereiche > möglich, denen kein Wert zugewiesen wird. Klar, für große und stark segmentierte Speicherbereiche hat hex Vorteile. Das kommt aber im klassischen Controller-Umfeld und den dort Vorkommenden Flash-Größen nicht wirklich zum tragen. Allgemein gesehen hast du sicher recht. Aber auch dann würde man die hex nicht from Scratch Byte für Byte bauen, sondern evt. aus mehreren Binaries zusammensetzen lassen. Der TE macht den Eindruck, er erstelle die Daten nativ und direkt als hex.
:
Bearbeitet durch User
Cyblord -. schrieb: > Das kommt aber im klassischen Controller-Umfeld und den dort > Vorkommenden Flash-Größen nicht wirklich zum tragen Stimmt so nicht, bei vielen ARMs fängt der Flash erst auf höheren Adressen an (0x200000, 0x400000 oder so). Wenn du dafür ein .bin File baust, dann hast du da megabyteweise Nullen am Anfang. Selbst für den hier besagten EEPROM eines AVR kann ein Dateiformat mit Adressierung sinnvoll sein: Zelle 0 war bei AVRs gefährdet, wenn während des Schreibvorgangs ein RESET auftritt. Insofern kann es wünschenswert sein, dass man seine eigenen EEPROM-Daten etwas weiter hinter legt, und ein Füllen mit 0 am Anfang würde alle Zellen davor umprogrammieren, während ein weiter hinten beginnendes Hexfile sie unangetastet (und damit auf 0xFF) lässt.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Cyblord -. schrieb: >> Das kommt aber im klassischen Controller-Umfeld und den dort >> Vorkommenden Flash-Größen nicht wirklich zum tragen > > Stimmt so nicht, bei vielen ARMs fängt der Flash erst auf höheren > Adressen an (0x200000, 0x400000 oder so). Wenn du dafür ein .bin File > baust, dann hast du da megabyteweise Nullen am Anfang. Natürlich macht man das nicht so. Man flasht das binary erst ab der Flash Adresse. Gibt das ST-Link Tool usw. ja selbst schon so vor. Geht ja nicht anders. Die Adressen davor kann dein Flasher-Tool ja gar nicht flashen. Was soll er mit den Megabyte nullen am Anfang also tun?
:
Bearbeitet durch User
Cyblord -. schrieb: > Was soll er mit den Megabyte nullen am Anfang also tun? Sicher, aber wenn man nur ein Binärfile erzeugt, fehlt die Information, für welche Adresse es ist. Es muss ja auch nicht zwingend für den Anfang des Flash sein (falls da bspw. ein Bootloader steht).
Jörg W. schrieb: > Cyblord -. schrieb: >> Was soll er mit den Megabyte nullen am Anfang also tun? > > Sicher, aber wenn man nur ein Binärfile erzeugt, fehlt die Information, > für welche Adresse es ist. Ich bestreite doch gar nicht dass hex fürs flashen praktischer ist. Nur wird diese nun mal aus einer oder mehreren bins zusammengebaut. Und nicht byte für byte erstellt. Darum schrieb ich: > Dann erstelle es als binary und lasse es in hex konvertieren.
:
Bearbeitet durch User
Cyblord -. schrieb: > Nur wird diese nun mal aus einer oder mehreren bins zusammengebaut. Eher aus dem ELF-File, und das hat natürlich auch Adressinformationen. Könnte man in AVRDUDE auch direkt flashen (in OpenOCD auch, bei den vendor tools bin ich mir da nicht so sicher).
Jörg W. schrieb: > bei vielen ARMs fängt der Flash erst auf höheren > Adressen an (0x200000, 0x400000 oder so). Wenn du dafür ein .bin File > baust, dann hast du da megabyteweise Nullen am Anfang. Da gibt man üblicherweise den Dateinamen und die Startadresse als Kommandozeilenparameter an. Füllbytes sind nicht nötig.
Stefan ⛄ F. schrieb: > Da gibt man üblicherweise den Dateinamen und die Startadresse als > Kommandozeilenparameter an. Füllbytes sind nicht nötig. Nunja, das Speichermapping kann schon etwas variantenreicher sein als du dir offensichtlich vorzustellen vermagst. Das fängt schon bei so primitiven Sachen wie Bootloader+App auf AVR8 an, wo leicht mal einige Dutzend kB "Lücken" entstehen können, aber endet damit längst nicht. Bei den richtig großen µC hat man es oft mit einer (kleinen) zweistelligen Zahl von Speicherbereichen zu tun, zwischen denen es "Lücken" im Bereichen von MB oder sogar GB gibt. Klar, es ist möglich, für jeden Teilbereich ein extra Image zu erstellen und dass dann auf den korrekten Offset zu "brennen". Aber diese Methode hat sich eben schon vor Jahrzehnten als viel zu fehlerträchtig herausgestellt. Klar ist da ein Format zu bevorzugen, was mit "Lücken" von Hause aus umgehen kann. Sei es z.B. ELF oder HEX. Alles ist besser als dumme binary images. Was wohl auch hinreichend erklärt, warum diese Formate überhaupt existieren...
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.