Mit c51 Kompiler aus dem erstellten Hex File ein Bin File erstellen

Gast #3848192
Lesenswert?

Guten Tag zusammen

Ich habe einen 8051F044, das Projekt ist fertig und ich habe ein Hex 
File erstellt. Allerding benötige ich ein Bin File und habe es bis jetzt 
nicht geschafft es zu erstellen. Ich hab eine converter exe 
heruntergeladen mit der es anscheinend möglich sein sollte 
(srec_cat.exe) wenn man die exe ausführt erscheint eine Console dort 
habe ich srec_cat datei.hex -o datei.bin -binary eingegeben es entstand 
nur eine fehler Meldung (srec_cat: standart input:1; warning:ignoring 
garbage lines). Kennt jemand vieleicht einen einfachen Weg aus dem Hex 
ein Bin File zu convertieren? (Habe nicht so viel Erfahrung) zB. bei ARM 
gibt es eine sehr simple Anleitung. Würde mich freuen wenn mir jmd einen 
Link bzw Rat hätte.
Gast #3848237
Lesenswert?

Mit diesem Befehl hat es leider auch nicht funktioniert.

Das Winhex ist leider kostenpflichtig.. Ich habe jetzt hex2bin.exe 
heruntergeladen und versuch mal mit diesem. Danke für die schnelle 
Antwort
#3848479
Lesenswert?

Markus schrieb:
> Meldung (srec_cat: standart input:1; warning:ignoring
> garbage lines).

Der 8051 ist ursprünglich von Intel und deshalb benutzen die Tools auch 
alle das Intel Hex Format. SREC is IIRC Motorola, und sieht ganz anders 
aus.

Das Simplicity Studio kennt arm-none-eabi-objcopy, wenn die EFM32 
Toolchain installiert wurde. Anders als der Name suggeriert, kann es 
auch die .hex von 8051 in ein Binary umwandeln.

Aber auch bei jeder anderen GCC Version ist ein Objcopy dabei (genauer: 
bei den Binutils, die werden aber praktisch immer mitgeliefert).
Gast #3848506
Lesenswert?

Markus schrieb:
> Kennt jemand vieleicht einen einfachen Weg aus dem Hex
> ein Bin File zu convertieren?

Nein, das muss auch garnicht funktionieren: ein Hex-File enthält 
Adressen und deren Inhalt, das können auch Adressen verschiedener 
Bereiche sein. Ein Bin-File enthält einen reinen Datenblock ohne 
Adressen. Das hat zur Folge, dass in jedem Fall die Adresse der Daten im 
Zielsystem verloren ist, und mehrere Datenblöcke an verschiedenen 
Adressen können garnicht sinnvoll in Bin umgewandelt werden (in Bin gibt 
es keine Lücken).

Sowas wie Hex2Bin funktioniert nur unter ganz einfachen Voraussetzungen: 
alles muss am Stück sein, und die Adresse muss man sich aufschreiben, 
jedenfalls wenn sie nicht 0000 ist.

Verwendet man einen Programmer mit PC-Bedienung, existiert das Problem 
nicht. Ein Hexfile wird an die Adressen geladen, die drinstehen, und vor 
dem Einlesen eines BinFiles fragt der Programmer, an welche Adresse er 
das einlesen soll.

Georg
Gast #3848604
Lesenswert?

@Jim Meba
Mit der Option -intel kann SRECORD (http://srecord.sourceforge.net/) 
selbstverständlich Intel-Hex-Dateien lesen oder auch schreiben.
@Georg (Gast)
Daher werden .bin Dateien zunächst immer bei 0 beginnend erzeugt und 
gehen bis zur höchsten vorkommenden Adresse (oder wahlweise bis zum 
darauf folgenden 2^n vielfachen).
Evtl. vorhandene Lücken aus dem .HEX file sind undefiniert und werden 
i.d.R. entweder mit 0x00 oder 0xFF gefüllt. Letzteres ist auch bei 
normalen Speicherbausteinen der übliche Löschzustand.
@Markus (Gast)
Dein "Hex" file scheint ja extrem geheim zu sein.
Vermutlich ist es gar kein richtiger?
http://de.wikipedia.org/wiki/Intel_HEX

Gruss
Gast #3848715
Lesenswert?

Erich schrieb:
> Evtl. vorhandene Lücken aus dem .HEX file sind undefiniert und werden
> i.d.R. entweder mit 0x00 oder 0xFF gefüllt

Das muss aber ja nicht richtig sein, z.B. wenn da in der Hardware 
Special Function Register sitzen. Sicherer wäre es, für jeden 
zusammenhängenden Block eine extra Bin-File zu erzeugen, aber das macht 
den Umgang damit sehr kompliziert. Ich würde daher empfehlen, wann immer 
möglich die Hexfiles zu verwenden.

Erich schrieb:
> Daher werden .bin Dateien zunächst immer bei 0 beginnend erzeugt

Das stimmt definitiv in vielen Fällen nicht und dann muss die korrekte 
Adresse manuell definiert werden. Umgekehrt kann man einem Binfile, z.B. 
der Sicherheitskopie eines ROMs, nicht ansehen wohin es gehört, das muss 
man dann am Dateinamen sichtbar machen wie ROM0, ROM1 oder so ähnlich.

Insgesamt ist die Frage, warum der TO sein Hexfile eigentlich umwandeln 
will anstatt es einfach zu verwenden.

Georg
Gast #3848733
Lesenswert?

Da wir ein spezielles Service Programm verwenden welches nur BIN Files 
übertragen kann.

(Ich habe beides nicht geschrieben und bin in der Einarbeits Phase nach 
der Techniker Schule was leider auch schon wieder 1,5 Jahre zurück liegt 
)

Das Hex File habe ich über die IDE von uVision erstellt.
Gast #3848862
Lesenswert?

C:\Keil\ARM\ARMCC\bin\fromelf.exe

Ich habe einen C51 und keine fromelf.exe

mit der Hex2Bin.exe müsste es eigentlich funktionieren ich verstehe 
allerdings nicht wie genau ich die Parameter konfiguriere bzw. welche 
ich benutzen muss.

wenn ich den Pfad eingebe in die Console um die Exe auszuführen kommt 
der Screen

http://www.softpedia.com/get/Others/Miscellaneous/Hex2bin.shtml#sgal_0

Wie muss ich dann weiter verfahren?
Gast #3848889
Lesenswert?

So wie ich es verstehe müssen der hex2bin.exe erst die Parameter wie Ort 
der Datei grösse bzw. Anfang Ende übergeben werden um das Ganze nacher 
in der IDE als User Command auszuführen.

(Die Daten bei den SFR übergebe ich weiterhin als Hex File)
#3850171
Lesenswert?

Wo ist das Problem?
1
D:\Downloads>hex2bin.exe XRC1000-12Bit-V02.02.hex
2
hex2bin v1.0.11, Copyright (C) 2012 Jacques Pelletier & contributors
3

4
Lowest address  = 00000000
5
Highest address = 00002370
6
Pad Byte        = FF
7
8-bit Checksum = 7A
8

9
D:\Downloads>dir *.bin
10
 Datenträger in Laufwerk D: ist DATA
11
 Volumeseriennummer: 7C71-E468
12

13
 Verzeichnis von D:\Downloads
14

15
21.10.2014  11:37             9.073 XRC1000-12Bit-V02.02.bin

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren