HEX-/BIN-Editor gesucht

[Duesentrieb7]

Hallo,

ich bin auf der Suche nach einem HEX-/Bin-Editor mit dem ich folgendes
einfach machen kann:
1. eine vorhandene Datei bis zu einer bestimmten Pos. mit "FF" auffüllen
2. dann eine zweite Datei anhängen

Kennt Ihr ein, möglichst freies, Programm für eine solche Aufgabe?

Habe schon einige ausprobiert, aber keines, was das kann... :(

Danke und Gruß,
Frank

[linux_80]

Hallo,

such mal nach "Tiny Hexer", der scheint nicht schlecht zu sein. V1.8.1.6 ist das Aktuellste was ich finden konnte.

[Duesentrieb7]

Danke @linux_80,

habe das Prog gerade getestet.
Bietet möglicherweise nur mit Hilfe eines Script, das, was
ich mir vorstelle. :(

Hat noch jemand einen Tipp für mich?

Gruß,
Frank

[zerush]

HxD kann das...
http://www.mh-nexus.de/de/downloads.php?product=HxD

edit: Das Verketten von 2 Dateien kann der HxD zwar auch, aber was auch immer funktioniert ist der gute alte copy Befehl in der Konsole:


copy Datei1.bin /B + Datei2.bin /B Datei1und2.bin /B

[Duesentrieb7]

Danke erst einmal,

das Zusammenhängen bekomme ich jetzt hin... :lol:
Habe den HxD ausgekramt.

Leider ist jetzt ein anderes Problem aufgetreten:

Ich "hänge" denn BootLoader an eine Bin-Datei an.
Dann wandle' ich sie in eine Hex-Datei.
Wenn ich diese Datei mit dem AVR-Studio in meine
ATmega128 schreibe ist alles gut.
Die Hex-Datei ist also scheinbar ok.
Wenn ich diese Datei aber mit meinem BootLoader
in die CPU schreibe, läuft das Programm nicht :x :x :x
Scheinbar erzeugt BASCOM ein "anderes" Hex-Format ?!?
Bin kein Kenner davon, dachte aber immer, Intel-Hex ist
gleich Intel-Hex...

Wo ist der Haken, bei der Sache?

Ich verwende hier NICHT den MCS-BootLoader, der
in Basic geschrieben ist, sondern den "alten", der noch
in Assembler geschrieben ist.
NEIN - ich kann (im Moment noch) nicht den neuen
verwenden...!



Danke und bis denn,
Frank

[zerush]

Binärdateien (meisten .bin) sind wirklich nur Rohdaten, die man mit einem normalen Text-Editor auch gar nicht lesen kann (sieht zumindest sehr unschön aus).

Intel-Hex-Dateien sind aufbereitete Daten, so dass man sie auch mit einem Text-Editor lesen kann. Hier werden tatsächlich die Hexwerte durch ASCII Zeichen dargestellt. Dazu kommt noch eine Adressierung am Anfang und noch irgendwas hinten dran (pro Zeile).

.bin und .hex zusammengefügt gibt also irgendwas sehr seltsames!

Ich hoffe ich habe dein Problem richtig verstanden?

[Duesentrieb7]

Hallo zerush,

ich denke, nicht.

Mit dem HxD kann ich auch prima die Bin-Dateien öffnen,
im Klartext ansehen und bearbeiten. Das passt.
Klar, ich kann eine Bin-Datei nicht mit einer Hex verknoten.

Ich gehe wie folgt vor.
1. Öffnen der ersten Bin-Datei
2. Anhängen der zweiten Bin-Datei
3. Speichern in eine gemeinsame Bin-Datei
4. Export der gemeinsamen Bin-Datei in eine Intel-Hex-Datei
Dabei wird das benötigte "Drumherum" der Hex-Datei vom
HxD erzeugt und das Format schein zu stimmen.

Diese kombinierte Hex-Datei kann ich prima mit dem AVR-Studio
in die CPU schreiben und sie funzt.
Schreibe ich die gleiche Hex-Datei mit dem besagten BootLoader
in die CPU, so läuft das Prog nicht. paff ?

Was mache ich falsch?

[linux_80]

Ich glaub auch nicht, dass bei dieser Art der Dateiverbindung ein Lauffähiger Bootloader rauskommt :-k
Denn der muss schon dorthin compiliert werden, damit er auch was macht !

Und ich glaub mittels Hexdateikopieren gehts noch am ehesten, denn dort wird in jeder Zeile die Zieladresse mitgegeben.
Siehe Wiki -> https://www.roboternetz.de/wissen/index.php/HEX-Datei
Nur von der 1. Datei das Endekennzeichen entfernen, und die 2. Anhängen.

[Duesentrieb7]

Hallo linux_80,

vielleicht hätte ich besser erwähnt, dass ich natürlich
die erste Bin-Datei mit "FF" bis zu der Position auffülle,
an der der BootLoader stehen muss... In diesem
Fall ist das bis h001FC00. Ab da beginnt der BootLoader.

Die CPU spring ja auch in den BootLoader, das
gesamte Programm wird vom BootLoader in die
CPU übertagen, aber funzt dann eben nicht.
Will heißen, das Programm startet nicht, bzw. ich
kann nicht erkennen was es macht.
Jedenfalls nicht das, was es soll... :(

[linux_80]

Funktioniert denn der Bootloader, oder das Programm, alleine ?
Passen die Einstellungen zum/im verwendeten Controller in den Ausgangsprogrammen ?

Das mit den FF's hätte man sich in der Hex-Datei sparen können, denn eine Zeile FF' kann man ruhig weglassen, da in jeder Zeile die Adresse vorkommt, es also kein Problem ist ein paar Adressen auszulassen ;-)

Warum soll überhaupt beides auf diese Weise in den Controller übertragen werden, und nicht hintereinander mit laufendem Bootloader ?

[Duesentrieb7]

Also das Programm funktioniert und der BootLoader auch.
Irgend wo ist der Wurm drin...
Selbst wenn ich den BootLoader einzeln reinschreibe und dass
Prog damit hinter her schiebe, läuft es nicht.

Der Grund ist relativ einfach: Zeitersparnis
Bei neuen Geräten müßten wir dann zwei Schritte machen:
1. BootLoader in die CPU mit ISP-Schnittstelle programmieren
2. Dann das Prog per Sellerie in die CPU

Hat bisher auch gut funktioniert, da ich eine (ur)alte Version des
Compilers (1.11.67) verwendet habe. Der hat aber leider die "Macke",
den 64k-Wechsel nicht sauber zu verwalten und ich muß an der
Stelle eine Lücke ins Programm zaubern. Den Speicher brauche
ich aber jetzt, da es eng wird.
Wenn ich das gleiche Programm mit einer aktuellen Version des
Compiler übersetze, bekomme ich die Fehlermeldung "no more
space for Bit" im Teil des BootLoader. Selbst Marc weiß (angeblich?)
nicht, was er da gemacht hat... Habe ihn jetzt schon mehrfach
dazu befragt.

Werde morgen Versuche mit dem MegaLoader von MicroSyl machen.
Mir läuft jetzt die Zeit zu schnell davon!

Danke und Gruß,
Frank

[repi64]

Hi,
ich habe mal ähnliche Sachen ebenfalls mit dem MegaLoad gemacht.
Die Prozedur, die du scheinbar erreichen möchtest, hatte ich so gemacht:
Microsyl Bootloader in den Mega geflasht (keine Lockbits setzen).
Per Bootloader die Anwendung geladen. Wenn alles läuft (Anwendung und erneutes Flashen per Megaload) kannst du den ATMega mit deinem Programmer wieder komplett auslesen und du erhältst deine Anwendung + Bootloader hinten dran als Bin bzw. Hex File.
Dieses kannst du in deine anderen Controller flashen und bei Bedarf auch die Lockbits entsprechend setzen.

[Duesentrieb7]

Danke @repi64,

habe dieses Problem erst einmal vom Eis :)

nachdem mein Kollege den Sonntag damit verbracht hat,
Hex-Files zu vergleichen, sind wir auf die Lösung gekommen:
Der "alte Assembler" BootLoader darf im Hex-File wirklich
nur Data-Records enthalten. Das haben ältere Versionen vom
Bascom-Compiler tatsächlich auch so "falsch" erzeugt. Deshalb
konnte man die "alten" Hex-Files auch nicht mit dem AVR-Studio
programmieren. Aktuelle Compiler machen echte Intel-Hex-Files,
die wiederum vom "alten" BootLoader" nicht zu gebrauchen sind...
Bei 128k wird aber bei einem "normgerechten" Hex-File zwei
Zeilen mit :02xx als Kennzeichnung "Extended Segment Address Record" eingefügt.
Diese Zeilen Programmiert der BootLoader ganz braun einfach in
den Flash der CPU und das Prog läuft nicht...

Die Idee mit dem Auslesen hatten wir auch - hatte aber auch nicht
funktioniert, da beim Auslesen mit dem AVR-Studio auch "echte"
Hex-Files erzeugt werden, die das oben genannte Problem haben.

Lösung:
1. Mit HxD das Bin-File des Programmes und des BootLoaders
verketten und den BootLoader an die Start-Adresse schieben.
Dabei die "Lücke" zwischen Programm und BootLoader brav
mit "FF" aufgefüllt lassen
2. Das verkettet Bin-File in ein Intel-Hex-File exportieren
3. Kopie davon erstellen, damit man das mit dem AVR-Studio
programmieren kann
4. Im Hex-File die zwei Zeilen :02xx löschen
Nun lässt sich das veränderte Hex-File mit dem BootLoader laden...

Habe inzwischen mit dem MCS-BootLoader experimentiert und
bin wieder voll auf die Schn**** gefallen. Aber das ist ein neues
Thema wert ](*,)

Danke an Alle,
Gruß Frank