AVRDUDE: Lesen des EEPROM von 32Byte auf 16Byte umstellen

[Daniel (Gast)]

Hi Zusammen

weis jemannd von Euch ob ich das Ausgabeformat bei Lesen eines EEPROM
bei AVRDUDE von 32Byte auf 16Byte umstellen kann?

Beispiel

So gibt AVRDUDE derzeit das EEPROM aus

:2000000001FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0B83753FFFFFFFFFFF55FFFF62
:2000200095B205008BF68E37806F203BAAFFFFFF22B3050066028F37004D2F3ACCFFFFFFB6

ich möchte aber den OUTPUT so formatiert haben

:1000000001FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE
:10001000FFFFFFFF0B83753FFFFFFFFFFF55FFFF54
:1000200095B205008BF68E37806F203BAAFFFFFF4D
:1000300022B3050066028F37004D2F3ACCFFFFFF39

OK Ihr sagt jetzt "Ist doch egal beides sagt das gleiche aus".
Aber ich möchte das File weiterbearbeiten und da mein PC Tool mit dem
unteren Format rechnet, müsste ich das Tool anpassen, worauf ich nicht 
so recht die Lust habe

Danke für die Hilfe

Gruß

Daniel

[Axel S. (a-za-z0-9)]

Daniel schrieb:

> weis jemannd von Euch ob ich das Ausgabeformat bei Lesen eines EEPROM
> bei AVRDUDE von 32Byte auf 16Byte umstellen kann?

Durch Ändern des Quellcodes von avrdude ;)

--- fileio.c.orig       2014-06-06 10:29:59.207848810 +0200
+++ fileio.c    2014-06-06 10:30:17.783373982 +0200
@@ -1206,7 +1206,7 @@
 
   switch (fio->op) {
     case FIO_WRITE:
-      rc = b2ihex(mem->buf, size, 32, fio->fileoffset, filename, f);
+      rc = b2ihex(mem->buf, size, 16, fio->fileoffset, filename, f);
       if (rc < 0) {
         return -1;
       }

> OK Ihr sagt jetzt "Ist doch egal beides sagt das gleiche aus".
> Aber ich möchte das File weiterbearbeiten und da mein PC Tool mit dem
> unteren Format rechnet

Was für ein Tool ist das? Es ist kaputt. Die einzige Bedingung für die 
Recordlänge bei Intel-HEX ist, daß sie zwischen 0 und 255 liegen muß.

> müsste ich das Tool anpassen, worauf ich nicht so recht die Lust habe

Schreib einen Bugreport. Laß es reparieren.

Als Workaround gibt es sicher diverse Umwandlungstools HEX/SREC/BIN, die 
man geeignet verketten könnte um ein HEX-File mit der gewünschten 
kürzeren Recordlänge zu bekommen.


XL

[Daniel (Gast)]

Danke dir XL

Dann pass ich "MEIN TOOL" doch an.
War nur ne Frage ob ich das mit einfachen mittel hin bekomme.
In meinem Tool nehme ich die Bytes auseinander und das Tool
ist sehr rudimentär geschrieben. Daher meine Frage ;-)

Gruß

Daniel

[Cyblord -. (cyblord)]

Daniel schrieb:
> Danke dir XL
>
> Dann pass ich "MEIN TOOL" doch an.
> War nur ne Frage ob ich das mit einfachen mittel hin bekomme.
> In meinem Tool nehme ich die Bytes auseinander und das Tool
> ist sehr rudimentär geschrieben. Daher meine Frage ;-)


Warum schreibst du ein Pfusch-Tool um iHex einzulesen, anstatt ein 
fertiges hex2bin einzusetzen und anschließend entspannt direkt die 
Binärdaten zu lesen?
Wenn man schon ein Tool macht, sollte man sich schon an den Standard 
halten.

[Daniel (Gast)]

Das Programm ist nicht von mir geschrieben ich muss nur den Pfusch am 
leben halten. Aber egal last es gut sein Ihr habt mir schon 
weitergeholfen

Ein schönes heißes Wochenende

Daniel

[Peter D. (peda)]

Mit hex2hex.exe kann man die Rekordlänge ändern und sie nach 
aufsteigender Adresse sortieren.

Besser ist natürlich, wenn das Leseprogramm mit jeder Rekordlänge 
(1..255) zurechtkommt. Auch müssen die Rekords nicht sortiert sein.

[Jörg W. (dl8dtl) (Moderator)]

cyblord ---- schrieb:
> Warum schreibst du ein Pfusch-Tool um iHex einzulesen, anstatt ein
> fertiges hex2bin einzusetzen und anschließend entspannt direkt die
> Binärdaten zu lesen?

Wobei bei einer reinen Binärdatei die Adressinformation verloren
geht.  Eine Hex- oder S-Record- oder ELF-Datei kann beliebige
Teilstücke des Adressraums enthalten.  Eine Binärdatei hat dafür
keine Information, man kann also nur ein zusammenhängedes Stück
Speicher damit beschreiben, und die Startadresse muss separat
(außerhalb der Datei) vereinbart sein.

[Cyblord -. (cyblord)]

Jörg Wunsch schrieb:
> cyblord ---- schrieb:
>> Warum schreibst du ein Pfusch-Tool um iHex einzulesen, anstatt ein
>> fertiges hex2bin einzusetzen und anschließend entspannt direkt die
>> Binärdaten zu lesen?
>
> Wobei bei einer reinen Binärdatei die Adressinformation verloren
> geht.

Jein. Wenn die Datei einfach bei Adresse 0 anfängt und durchgehend den 
gesamten Adressraum bis zur max. verwendeten Adresse im iHex abdeckt, 
dann geht keine Info verloren und es muss keine Startadresse vereinbart 
werden.
Im Zweifel gibt es Lücken in der Ihex, diese werden dann halt mit 0 
gefüllt.
Klar, die Datei könnte dadurch recht aufgebläht werden.
In den meisten Fällen handelt es sich aber doch um durchgehende Dumps 
von Adresse 0 bis Adresse X. Grade bei einem EEPROMs.

[Jörg W. (dl8dtl) (Moderator)]

cyblord ---- schrieb:

> Jein. Wenn die Datei einfach bei Adresse 0 anfängt ...

Das ist das, was ich mit „Startadresse muss außerhalb der Datei
vereinbart werden“ meinte.

> In den meisten Fällen handelt es sich aber doch um durchgehende Dumps
> von Adresse 0 bis Adresse X. Grade bei einem EEPROMs.

Gerade bei EEPROMs will man u. U. nur einen Datensatz an einer ganz
bestimmten Stelle hinterlegen, ohne den Rest zu ändern.