AVRDUDE und Intel-Hex

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?

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.

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

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.

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.

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?

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.

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).