Bootloader .hex-Datei auf einheitliche Stringlänge bringen - wie?!

Dann machst du aber etwas grundlegend falsch beim Einlesen der Datei.
Hier

1

:1000000014C026C025C024C023C022C021C020C0E7

2

 **

steht die Länge der Daten in Bytes. Brauchst du nur lesen und auswerten 
bzw. im Programm berücksichtigen. Wenn du natürlich in deinen Programmen 
(Bootloader) davon ausgehst, dass das immer 16 Bytes wären, dann musst 
du eben mal ein wenig universeller und mit weniger Annahmen 
programmieren.

- Im Terminalprogramm ein "binäres" Feld mit der Größe des Bootladers 
definieren und mit 0xff oder einer anderen genehmen Konstante füllen.

 - Das Hexfile in dieses Feld einlesen.

 - Die Daten des Feldes wieder in Hex mit konstanter Rekordlänge wandeln 
und programmieren.

Alles andere geht auf Grund der Seitenstruktur des AVR Programmspeichers 
nur sehr mühsam. In einem Hexfile müssen nämlich nicht die Rekords mit 
den Adressen aufeinander folgend abgelegt sein.

Amateur schrieb:
> die letzte Zeile

Das ist üblicherweise der Rekord mit der Startadresse. Der interessiert 
beim Flashen nicht.

Hallo Marius,

Marius Dege schrieb:
> Die Checksumme
> bekomme ich berechnet, und ich weiß auch das man die Daten vom nächsten
> String "einfach" anhängt, aber wie verhalten sich dabei die Adresse?

So wie du es in "Gewandelte.txt" gemacht hast wäre es richtig.

Aber: In einer hex-Datei können auch Lücken entstehen, z.B. wenn man die 
sections explizit positioniert. Das Format lässt sogar zu, dass 
Fragmente in beliebiger Reihenfolge auftauchen oder Speicher sogar 
zweimal geschrieben wird - das wird in der Praxis aber wohl eher nicht 
auftauchen.

Also entweder so wie von Georg vorgeschlagen den Flash-Speicher im 
Terminalprogramm nachbilden, die hex-Datei komplett einlesen, und dann 
den Speicher wieder als hex-Datei rausschreiben.

Oder aber, besser, wie von Karl-Heinz empfohlen den Bootloader so 
erweitern dass er beiebige Längenbytes und Adressen verarbeiten kann und 
Fragmente sauber in den seitenweisen Flash programmiert.

Marius Dege schrieb:
> Klappt das auch so dann noch bei 256kb AVRs?

Bei denen enthält die hex-Datei immer nach 64kB Typ 02 Einträge. Siehe 
http://de.wikipedia.org/wiki/Intel_HEX.

LG, Sebastian

Sebastian Wangnick schrieb:

> Oder aber, besser, wie von Karl-Heinz empfohlen den Bootloader so
> erweitern dass er beiebige Längenbytes und Adressen verarbeiten kann und
> Fragmente sauber in den seitenweisen Flash programmiert.

Na ja. Ob das 'besser' ist, lass ich mal dahin gestellt. Besser ist es 
sicherlich im allgemeinen Fall nicht, weil ja, wie du richtig sagst, im 
Prinzip es keine Garantie gibt, dass die Records in aufeinanderfolgende 
Adressen zu liegen kommen.

Aber: Im speziellen Fall hat man es meistens nicht mit dem allgemeinen 
Fall zu tun. Man kennt seine Tools und wie sie das Hex-File generieren 
und das ändert sich normalerweise nicht. Solange man damit leben kann, 
einen kleineren Subset von Hex-Files per Bootloader zum AVR zu 
übertragen, müsste das eigentlich möglich sein (Ohne jetzt den Aufbau 
seines Bootloaders zu kennen), den soweit zu pimpen, dass er wenigstens 
mit unterschiedlichen Längen im Data-Record klar kommt.
Frickellösung ist es - zweifellos. Ob sie akzeptabel ist, dass muss der 
TO entscheiden. Zumal auch das Erstellen eines übertragbaren Files (muss 
ja kein HEx-File sein) aus einem Hex-File auf dem PC für einen 
Programmierer keine große Herausforderung ist. Georg G. hat ja schon 
angesprochen wie man das macht: Speicher bereitstellen und dann einfach 
das Hex-File Zeile für Zeile lesen und das was man dort vorfindet als 
Befehl auffassend auf diesen Speicher anwenden. Zum Schluss hat man ein 
'Speicherimage' aus dem man sich dann das zu übertragende File 
generiert, egal welches Format dieses dann hat.

Marius Dege schrieb:
> Karl Heinz schrieb:
>> Dann machst du aber etwas grundlegend falsch beim Einlesen der Datei.
>> Hier
>>

1

>> :1000000014C026C025C024C023C022C021C020C0E7

2

>>  **

3

>>

>> steht die Länge der Daten in Bytes. Brauchst du nur lesen und auswerten
>> bzw. im Programm berücksichtigen. Wenn du natürlich in deinen Programmen
>> (Bootloader) davon ausgehst, dass das immer 16 Bytes wären, dann musst
>> du eben mal ein wenig universeller und mit weniger Annahmen
>> programmieren.
>
>
> Ich versuche eigentlich universell zu programmieren - hier hat es mich
> voll erwischt; habe ich ehrlich gesagt auch gar nicht dran gedacht an
> sowas.
> Weißt du denn, wie der BL auch mit unterschiedlich langen Lines klar
> kommen kann, bzw wie er diese handhabt?

?
Du schickst doch, wenn ich das richtig verstanden habe, die Zeile so wie 
sie ist zum Bootloader. Oder nicht.
Der holt sich aus den ersten beiden Zeichen nach dem ':' die Anzahl der 
Datenbytes raus und weiß daher, was und wieviel nach der 
Datensatzkennung kommen muss. Wo ist da jetzt das große Problem?

Marius Dege schrieb:

> wenn es einfacher ist) lösen kann, weil ich nicht so wirklich weiß, wie
> dieses Programm die "Gewandelte.txt" erstellt hat (außer das die Daten
> von der nächsten Line an die vorherige angehängt werden, und dann die
> Checksum neu berechnet wird; Datenlänge wird natürlich auch angepasst).

Man kann das natürlich so machen, wenn man davon ausgeht, dass die 
Datenbytes grundsätzlich aufsteigend im Speicher angeordnet sind.

> Aber wie das tolle Programm da die Adressen berechnet - ?!

Na komm.
Das kannst du selbst auf Papier auch.

Wenn du eine Startadresse von 10 hast, ich dir 7 Datenbytes gebe, danach 
9 und dann nochmal 4, an welche Adresse kommt dann das nächste Byte?


> bin ich dort mit der Adressenberechnung nicht durchgestiegen. Hast du
> evtl. eine Ahnung wie das "Gewandelte.txt" entstanden ist?!

Höchst wahrscheinlich (zumindest würde ich das so machen), genau so wie 
das beschrieben wurde:
Datenrecord vom original lesen. Den dadurch codierten 'Befehl' (schreibe 
8 Datenbytes beginnend ab Adresse xyz) in einem Array ausführen und wenn 
das File komplett gelesen wurde, dann schreib ich ein neues File 
basierend auf dem was ich an Daten im Array vorfinde.

Das ist nicht wirklich schwer. Das sollte eigentlich jeder 
C-Programmierer in längstens 2 Stunden hinkriegen. Zumal das File-Format 
eines HEX-Files nicht sehr komplex ist.

Hallo Marius,

Marius Dege schrieb:
> Mein Bootloader ist recht einfach aufgebaut: [...]
> Die gesendete Line wird dann im BL zu HEX convertiert und es wird dort
> Checksum, Data, Rekord, Adresse gebildet. Damit hat man erstmal alles um
> via boot_fill_page eine Seite zu füllen. [...]
> Ich kann euch gerne auch den Bootloader hochladen wenn gewünscht.

Tu das mal. Ich versteh nämlich nicht mehr was du nicht verstehst :)

LG, Sebastian

PS: Ich bastele gerade an einem Internet-Bootloader (für mein Board mit 
Atmega1284P und W5500) und benutze dabei auch das hex-Format. Ich lade 
keine ganzen Zeilen sondern liefere alle einlaufenden Zeichen in einen 
hex-Zustandsautomaten, und von dort die Adressen und Datenbytes in einen 
Flash-Zustandsautomaten. Ich bin allerdings schon bei >4K UND es fehlt 
noch DHCP ...

LG, Sebastian

Sebastian Wangnick schrieb:

> Marius Dege schrieb:
>> Mein Bootloader ist recht einfach aufgebaut: [...]
>> Die gesendete Line wird dann im BL zu HEX convertiert und es wird dort
>> Checksum, Data, Rekord, Adresse gebildet. Damit hat man erstmal alles um
>> via boot_fill_page eine Seite zu füllen. [...]
>> Ich kann euch gerne auch den Bootloader hochladen wenn gewünscht.
>
> Tu das mal. Ich versteh nämlich nicht mehr was du nicht verstehst :)

Willst du mit mir eine Wette eingehen, was das EIGENTLICHE Problem ist 
:-)

Das Primitivste wäre wohl ein kleines Batchfile, das das Hexfile 
aufbereitet.

hexbin %1.hex %1.bin
binhex %1.bin %1.neu 0

Tunixe können das auch per Pipe zu einer Zeile zusammenfassen.

Quältexte für hexbin und binhex gibt es auf Anfrage auch (einmal 
Turbopascal, einmal C).

Vielleicht hilft dir das:

1

2

  if(nUdr == ':')  //Neuer Hexstring

3

  {

4

    nFrameInd = 0;

5

    bNewFrame = true;

6

  }

7

//......

8

9

  default:    //Ascii-Daten (0..9, A..F, a..f)

10

    nFrame[nFrameInd++] = nUdr;

11

    nUdr = 0;

12

    break;

13

14

//....     

15

if(bNewFrame)

16

{  

17

  //Länge ermitteln

18

  if(nFrameInd == 2) nData[0] = AsciiToByte(nFrame[0], nFrame[1]);

19

20

  if(nFrameInd == ((nData[0] * 2) + 10)) //Hexstring angekommen

21

  {

22

    SendChar(XOFF);   //Um Ruhe bitten

23

    unsigned char nCsum = 0;

24

     for (unsigned char nInd = 0; nInd < (nData[0] + 5); nInd++)

25

     {

26

        //Datenbereich aus Hexstring umwandeln

27

        nData[nInd] = AsciiToByte(nFrame[nInd * 2], nFrame[(nInd * 2) +1]);

28

        nCsum += nData[nInd];

29

     }

30

     if(!nCsum)

31

     {

32

        //Adresse ermitteln und umwandeln auf Flashadresse

33

        UINT nAddress = (unsigned int)((nData[1] << 8) + nData[2]);

34

//....

Mit Längen- und Adressauswertung im Controller kannst du das Hexfile 
auch mit Hyperterminal oder sonstwas rüberschaufeln. Hauptsache der 
Knabe versteht XON/XOFF und müllt den Controller während er ins Flash 
brennt nicht zu.

mfg.

Marius Dege schrieb:
> Warte mal: Ich starte bei Adresse 000, dann bekomme ich 8 Datenbytes ==>
> die nächste Adresse für die nächste Line ist dann 008?

Marius Dege schrieb:
> Ich habe den Adressaufbau beim .hex nicht wirklich verstanden. Aber
> jetzt ist es klar. Aktuelle Adresse + Datenbytes = Nächste Adresse.

Nicht ganz. Die Adresse der nächsten Zeile steht immer in dem Header 
der Zeile.

Nehmen wir mal eine Ausschnitt aus Normale.txt und streuen Leerzeichen 
und Zeilennummern ein:

     len addr typ data                             cksum
Z1 : 10  00B0 00  E1F700C00000D9DF882389F3CE35D105 F0
Z2 : 10  00C0 00  31F4E0916000F09161000995E8CF83E8 98
Z3 : 0A  00D0 00  90E0D4DFE4CFF894FFCF F6
Z4 : 10  00DA 00  B004256900252E32660048616C6C6F2C CD
Z5 : 10  00EA 00  20776965206765687420657320646972 82

typ ist bei allen reinen Datenzeilen 00.

len gibt die Anzahl der Datenbytes in data. Oft ist len=0x10, also 16 
Bytes an Daten.

addr gibt die Adresse des ersten Datenbytes.

data sind die Datenbytes. Das erste Datenbyte kommt an Adresse addr, das 
zweite and addr+1, das dritte an addr+2 und so weiter. Das letzte, also 
sozusagen das len'te, kommt an addr+len-1.

Nur wenn ein grösserer zusammenhängender Datenbereich hex-kodiert ist 
(was aber fast immer der Fall ist), folgt in der nächsten Zeile dann 
addr(Z2) = addr(Z1)+len(Z1).

In deinem Fall gilt dass auch für den Übergang von Z3 auf Z4. Z3 beginnt 
bei 0x00D0 und ist 0x0A lang. Z4 beginnt dann bei 0x00DA.

Jetzt wird dir wohl auch klar, wie Gewandelte.txt entstanden ist. Die 
Datenbytes von 0xDA-0xDF aus Z4, also 0xB00425690025, wurden an die 
Datenbytes aus Z3 angehängt, um die Länge auf 16 zu erweitern. Die 
restlichen Datenbytes (0x2E32660048616C6C6F2C) beginnen eine neue Zeile 
mit Adresse 0x00E0, an die dann wieder Datenbytes aus Z5 angehängt 
werden um die Länge auf 16 zu bringen, und so weiter.

Du fragst dich vielleicht: Warum aber ist in Normale.txt dieser blöde 
Bruch bei Z3. Das hat mit den Loader-Segmenten zu tun. Alles bis Z3 
inklusive gehört zum .text-Segment, alles ab Z4 gehört (glaube ich) zum 
.bss-Segment (also zu den im Flash gespeicherten Daten die benötigt 
werden, vor dem Programmstart die Variablen im SRAM zu initialisieren). 
Wenn du das genau wissen willst, brauchst du die zur hex-Datei gehörende 
elf-Datei. Die kannst du mit avr-objdump -h -S dekodieren und dir die 
vom Loader generierten Segmente anschauen.


Bei uC mit >64kB Flash gibt es dann noch, wie oben erwähnt, die typ 02 
Zeilen. Dabei ist len 02, addr 0000, typ 02, und es gibt zwei Bytes 
data. Das unterste Nibble ist immer 0, siehe Wikipedia. data wird um ein 
Nibble linksgeshiftet und fortan noch zu addr dazugerechnet.

Also, wenn die folgende Zeile erscheint,

1

:020000021000EC

dann wird data (0x1000) um ein Nibble linksgeshiftet (=0x10000), und 
danach immer zu addr hinzugerechnet. Also aus addr 0x0010 in irgend 
einer Folgezeile wird dann tatsächlich die Flash-Adresse 0x10010.

LG, Sebastian