File in µC Code einbinden

Schade, das du nicht schreibst, um was für einen MC es geht. Bei einem 
AVR deklariere ich ein Array als

1

const PROGMEM uint8_t myArray[LENGTH_OF_MYARRAY] = { 0x00,0x01,0x02...

2

};

und inkludiere es.
Beim STM32 kann ich mir 'const PROGMEM' sparen.

Peter II schrieb:
> dann muss man die Datei aber immer noch umwandeln.

Das sollte mit einem Konverter nicht so schwierig sein. Hex2Bin ist 
Standard und dann kann man sich z.B. sowas hier zusammenkloppen oder 
einen Online Konverter suchen:
http://lua-users.org/wiki/BinToCee

Wenn das nur ein paar Bytes sind, auch händisch - wir wissen ja nicht 
mal, wie lang das Hex File ist...

Schreib Dir ein Programm für den PC, welches das Hex-File in ein 
Include-File mit der Syntax

1

const PROGMEM uint8_t myArray[LENGTH_OF_MYARRAY] = { 0x00,0x01,0x02...

2

};

konvertiert. Fertig.

Frank M. schrieb:
> Schreib Dir ein Programm für den PC, welches das Hex-File in ein
> Include-File mit der Syntaxconst PROGMEM uint8_t
> myArray[LENGTH_OF_MYARRAY] = { 0x00,0x01,0x02...
> };
>
> konvertiert. Fertig.

Noch fertiger im Anhang...

Klaus W. schrieb:
> Noch fertiger im Anhang...

:-)

Wenn ich richtig gelesen habe, hat der TO eine Hex-Datei und keine 
Bin-Datei. Dafür ist bin2c.cpp ungeeignet.

pipapo schrieb:
> unter Linux gibt es xxd

Wenn es sich um eine Hex-Datei im Intel-Hex-Format - wovon ich stark 
ausgehe - handelt, ist xxd ebenso ungeeignet.

Man muss die Datei schon interpretieren: Links eine Datensatzmarkierung, 
danach eine Längeninformation und der Offset, dann der Datentyp des 
Records, dann die Daten selbst und rechts eine CRC, die in den Nutzdaten 
nichts zu suchen hat.

Ich habe mal so ein C-Programm (f. Linux und Windows) geschrieben, 
welches ich für diverse Bootloader verwende. Wenn Ulf daran interessiert 
ist, kann er sich ja melden. Oder es selbst machen - so schwierig ist 
das nicht.

Das Format ist hier erklärt:

   https://de.wikipedia.org/wiki/Intel_HEX

Man kann auch ganz einfach beide Hexfiles zusammen kopieren. Man muß nur 
vom ersten den Enderecord löschen, z.B. mit findstr.

Peter D. schrieb:
> Man kann auch ganz einfach beide Hexfiles zusammen kopieren.

Ja, wenn die darin verwendeten Adress-Offsets sich nicht überschneiden.

Der TO schweigt sich aber leider über die Art und den Inhalt der 
Hex-Datei komplett aus.

> Man muß nur vom ersten den Enderecord löschen, z.B. mit findstr.

Jepp.

Ulf Brandner schrieb:
> Die Hex Datei enthält den Code, den ich von µC1 über SPI zum Bootloader
> von µC2 schicken möchte.

Sags doch gleich, Du willst eine merge.hex aus boot + app.

1

findstr /V ":00000001FF" boot.hex >merge.hex

2

copy merge.hex+app.hex merge.hex

Ulf Brandner schrieb:

> Die Hex Datei enthält den Code, den ich von µC1 über SPI zum Bootloader
> von µC2 schicken möchte.

Dann gehts auf jeden Fall nicht mit dem Zusammenkopieren. Da sind 
Adressüberschneidungen (Code µC1 <--> Code µC2) auf jeden Fall gegeben.

Also entweder:

  - erst oben genanntes hex2bin
  - dann oben gezeigtes bin2c

verwenden oder das Programm selber schreiben.

Frank M. schrieb:
> Dann gehts auf jeden Fall nicht mit dem Zusammenkopieren. Da sind
> Adressüberschneidungen (Code µC1 <--> Code µC2) auf jeden Fall gegeben.

Beim AVR sind jedenfalls Bootloader und Applikation in getrennten 
Flashbereichen, d.h. es überschneidet sich nichts.

Warum sollen sich beim ARM beide überschneiden, bzw. wie soll das 
überhaupt gehen, wenn Applikation und Bootloader sich gegenseitig 
überschreiben?

Peter D. schrieb:
> Warum sollen sich beim ARM beide überschneiden, bzw. wie soll das
> überhaupt gehen, wenn Applikation und Bootloader sich gegenseitig
> überschreiben?

Weil Du es nicht verstanden hast:

µC1 soll µC2 flashen. In µC2 ist also ein Bootloader, ok.

Aber in µC1 steckt schon eine Applikation, nämlich die Senderoutine, um 
die zu flashenden Daten von µC1 nach µC2 zu schicken. Daher ist es mit 
hoher Wahrscheinlichkeit nicht möglich, die Applikation für µC2 in µC1 
1:1 zu speichern. Die Daten müssen in µC1 versetzt abgelegt werden.

1

    µC1                       µC2

2

----------------        ----------------

3

| Senderoutine |   +--> | Data f. µC2  |

4

|              |   |    |              |

5

| Data f. µC2  |---+    |              |

6

|              |        |              |

7

|              |        | Bootloader   |

8

----------------        ----------------

Wenn Du also die beiden Hex-Dateien (µC1 Programm 1 + Data für µC2 = 
Programm 2) zusammenkopierst, hast Du eine Überschneidung.

Frank M. schrieb:
> µC1 soll µC2 flashen

Sorry, das hatte ich überlesen.
Vergiß meinen Post.

Igori schrieb:
> Das Konvertierungsprogramm kann man sehr gut mit Java-Script schreiben
> und im Browser laufen lassen. Per Copy & Paste kann man die Ausgabe des
> Browsers dann in das Zielprogramm übertragen.

Keine gute Idee.
Denn sinnvollerweise wird man den Konvertierschritt mit ins makefile 
einbauen.

Frank M. schrieb:

> hoher Wahrscheinlichkeit nicht möglich, die Applikation für µC2 in µC1
> 1:1 zu speichern.


Versteh ich nicht. Warum soll das nicht gehen.
Die Applikation für µC2 ist aus Sicht des µC einfach nur ein Array aus 
Bytes, welches er 1:1 an den Bootloader in µC2 weitergibt. µC1 soll 
dieses Programm ja gar nicht ausführen.

>

1

>     µC1                       µC2

2

> ----------------        ----------------

3

> | Senderoutine |   +--> | Data f. µC2  |

4

> |              |   |    |              |

5

> | Data f. µC2  |---+    |              |

6

> |              |        |              |

7

> |              |        | Bootloader   |

8

> ----------------        ----------------

9

>

Karl H. schrieb:
> Versteh ich nicht. Warum soll das nicht gehen.

Ja, als const-Array geht das. Es ging aber hier um das Zusammenkopieren 
zweier Hex-Dateien, wie Peter es vorschlug:

       Applikation-fuer-uC1.hex
     + Applikation-fuer-uC2.hex

Diese beginnen aber beide an derselben Adresse im Flash. Das geht dann 
natürlich nicht.

sebastian schrieb:
> Braucht man nicht selber schreiben, srec_cat kanns schon.

Schönes Programm... ja, damit sollte es gehen.