Tach auch
ich programmiere auf einem ATmel controller und möchte an den Anfang des
hex-files ein paar Infos in Form eines Strings schreiben. Zum Beispiel
Infos zur aktuellen Firmware-Version oder Datum o.ä.
Leider jedoch ohne Erfolg.
Ich habe die Suche bemüht und benuitze vielleicht die falschen
Suchwörter.
Habe folgendes gefunden (Stichwort: Segmente, Memorys, Section, etc):
In meinem C-Code schreibe ich folgendes:
In den Linker Einstellungen (Atmel Studio) Toolchain-->AVR/GNU
Linker-->Miscellaneous:
1
-Wl,--section-start=.FWversion=0x800000
Wie gesagt, hatte ich damit keinen Erfolg. (Habe auch schon andere
Adressen probiert)
Habt ihr einen Vorschlag für mich? Habe ich einen Fehler?
Gruß Tobi
Tobi schrieb:> Wie gesagt, hatte ich damit keinen Erfolg.
Wenn ich richtig informiert bin, ist ein .hex-File im Intel-Hex-Format.
Und dort sind die Byte-Werte als ASCII (pro Byte 2 Zeichen) abgelegt.
Das heißt du könntest sowieso nur die Ziffern 0..9 und die Buchstaben
A..F verwenden. Alles andere ist nicht darstellbar.
Anders würde es aussehen, wenn du die gewünschten Informationen in einem
binären File ablegen würdest, dort geht dann alles, dort sieht man alle
Zeichenketten. Mußt nur mal eine *.exe mit einem Textbetrachter öffnen.
Aber binäre Files sind m.M. relativ ungebräuchlich zum Programmieren von
µC. Dort wird in der Regel mit hex oder elf gearbeitet...
Tobi schrieb:> (Habe auch schon andere> Adressen probiert)
Warum "probieren"? Wie groß ist dein Flash? Bestimmt nicht mehr als
0x800000 Bytes. Also nimm die Größe, ziehe 16 ab (für deinen String) und
nimm das als Adresse.
Es bleibt die Frage, warum du extra eine Section dafür aufmachen willst.
Ich packe solche Infos ganz einfach ins Programm. Dann landen sie zwar
nicht immer an der gleichen Stelle, aber das müssen sie ja wohl nicht.
?!? schrieb:> Wenn ich richtig informiert bin, ist ein .hex-File im Intel-Hex-Format.> Und dort sind die Byte-Werte als ASCII (pro Byte 2 Zeichen) abgelegt.> Das heißt du könntest sowieso nur die Ziffern 0..9 und die Buchstaben> A..F verwenden. Alles andere ist nicht darstellbar.
Das hex-File muss man natürlich mit einem Hex Editor betrachten. (siehe
Bild im Anhang).
Bisher habe ich diese Info separat im EEPROM abgelegt, daher stammt auch
das Foto. Das ist natürlich umständlich. Praktischer ist es, wenn ich
ein update der Firmware vornehme, dass diese Info auch in dem gleichen
File vorhanden ist und ich nicht an einer anderen Stelle suchen muss.
Ich habe es auch schon einmal bei jemanden gesehen. Leider habe ich aber
keinen Zugriff mehr auf diese Person.
Georg G. schrieb:> Warum "probieren"? Wie groß ist dein Flash? Bestimmt nicht mehr als> 0x800000 Bytes. Also nimm die Größe, ziehe 16 ab (für deinen String) und> nimm das als Adresse.
Das habe ich ja gemacht, aber ich konnte meine Daten trotzdem nicht im
hex-file finden. Falls es hilft: ich benutze den AT90CAN von Atmel.
Tobi schrieb:> Das habe ich ja gemacht
Das von dir gezeigte Beispiel sagt mir aber, dass du weder die Größe
auch nur annähernd kennst, noch, dass du 16 abgezogen hast.
Der AT90CAN128 hat 128MBytes Flash. Die letzte verfügbare Adresse ist
also 0x1ffff. Dein Versionsstring sollte dann bei 0x1fff0 liegen. Nun
musst du nur noch herausfinden, wie dein Entwicklungssystem rechnet.
Atmel verwendet nämlich manchmal Byte Adressen und manchmal Wort
Adressen. Also nimmst du für den ersten Schuss ein Miniprogramm "Hello
World" und legst den String nach 0xfff8. Dann siehst du dir das Hex-File
an. Liegt der String in der Mitte, rechnet deine Kiste in Bytes und du
musst 0x1fff0 als Adresse nehmen.
Tobi schrieb:> Das hex-File muss man natürlich mit einem Hex Editor betrachten. (siehe> Bild im Anhang).
Ich glaube, da liegt immer noch ein Mißverständnis vor. Ich hatte das
gestern schon versucht zu erklären. Was du meinst, ist ein binäres File,
welches so wie bei dir aussieht, wenn man es mit einem Hex-Editor
öffnet.
Im Gegensatz dazu ist ein Hexfile (Endung *.hex) ein ganz normales
ASCII-File, also ein Text-File, was zum Beispiel so aussieht
(Ausschnitt):
1
:100000000C947E000C94A0000C94A0000C94A00012
2
:100010000C94A0000C94A0000C94A0000C94A000E0
3
:100020000C94A0000C94A0000C94A0000C94A000D0
4
:100030000C94A0000C94A0000C94A0000C942F1021
5
.....
6
:1044D000002863292030382F323031342000253233
7
:0E44E00058002534580025346400253364004C
8
:00000001FF
Aber du meinst offensichtlich kein Hex-File, sondern eben ein binäres
File, richtig?
Das Intel-Hex Format sieht keine Texte vor.
Speziell die Atmels haben am Programmanfang (0000++) einen reservierten
Bereich (Sprungtabelle).
Willst Du also den Kreis quadrieren, wirst Du wohl einen Hammer oder
eine Feile nehmen müssen.
Jetzt bin ich verunsichert!?!
Am besten schreibe ich was ich möchte. Ich glaube jetzt habe ich ein
generelles Verständnisproblem.
- Ich schreibe ein Programm mit C-Code.
- Ich kompiliere das File und erhalte ein *.hex - file
- Dieses öffne ich mit einem hex-Editor (siehe Bild weiter oben)
- in der linken tabelle stehen die hex-daten in der rechten Tabelle sehe
ich die entsprechenden Ascii Daten ("0x65" = "e")
- ich hatte jetzt erwartet, dass ich mein erzeugtes hex-file öffne und
in der Ascii Tabelle meine Firmwareversion im Klartext lesen kann (so
wie es im Bild aus dem EEPROM hexfile hervorgeht)
Geht das ?
Wenn ja wie?
Durch Eure Antworten, weiß ich im Moment gar nicht mehr was los ist :(
- Ich bin verwirrt -
Tobi schrieb:> - Ich kompiliere das File und erhalte ein *.hex - file> - Dieses öffne ich mit einem hex-Editor (siehe Bild weiter oben)
Hier liegt schon mal ein Verständnisproblem vor.
*.hex Files sind gewöhnlich vom Format "Intel Hex".
Dieses Format ist kein Binärformat sondern reiner ASCII-Text. Somit
brauchst du zum öffnen keinen hex-Editor sondern einen stinknormalen
Editor (Notepad).
Ich schlage vor du liest dich erstmal hierrüber ein.
Peter Dannegger schrieb:> Ich schreibe mir ein _version.c:#include <avr/pgmspace.h>>> prog_uint8_t Version[] __attribute__((used));> prog_uint8_t Version[] = PROJECT_STRING ", "> "V:" REVISION_STRING ", "> _DATE_ "\n";>> Durch den _ wird es als erstes hinter der Vektortabelle gelinkt.> Die Defines schreibe ich ins Make (oder Batch).
Aber auch bei dieser Lösung gilt: deinen Text wirst du nicht im .hex
File finden. Völlig egal ob du es mit einem Editor öffnest (dafür ist es
gedacht) oder mit einem Hex-Editor.
Im .hex findest du niemals deinen Text in Klarschrift.
Die Dannegger Lösung funktioniert, wenn du die .elf im Hexeditor
öffnest. Dann muss irgendwo dein Text zu finden sein.
Wo ist ein Schreibfehler?
Ist eine Verwechslung von 10 Millionen Euro und 10 Milliarden Euro nicht
jeden zweiten Tag in den Medien?
Die Journalisten reden sich dann auch immer auf "Druckfehler" heraus.
Im technischen Bereich sind es dann k/M oder p/n Vorsilben die gerne
verbuchselt werden.
Mit megamäßigen Grüßen
Zum Thema:
Mit dem Tool SRecord kann man nachträglich an beliebigen Adressen eines
.HEX files was reinschreiben.
Die Syntax ist jedoch etwas kryptisch und für die TE hier wohl eher
nicht förderlich.
Nur der Vollständigkeithalber nachgetragen.
http://srecord.sourceforge.net/
Gruss
Erich schrieb:> Zum Thema:> Mit dem Tool SRecord kann man nachträglich an beliebigen Adressen eines> .HEX files was reinschreiben.> Die Syntax ist jedoch etwas kryptisch und für die TE hier wohl eher> nicht förderlich.> Nur der Vollständigkeithalber nachgetragen.> http://srecord.sourceforge.net/> Gruss
Das Tool kann zwar hex-Files lesen, aber es schreibt keine Infos direkt
ins File. Es dekodiert das hex-File, schreibt in das dekodierte
Binärfile und kodiert das dann wieder zum Hex-File. Deswegen kannst du
auch damit keine Zeichenkette im hex-File lesen. Wenn andere
ASCII-Zeichen als 0..9 und A..F im hex-File stehen, ist es kaputt. Gut,
am Zeilenanfang steht noch ein ":".
?!? schrieb:> Wenn andere> ASCII-Zeichen als 0..9 und A..F im hex-File stehen, ist es kaputt. Gut,> am Zeilenanfang steht noch ein ":".
Ich biete noch '\r' und '\n' ;-)
Vielleicht wäre das Tool etwas für den TO
http://firmwarebatchtools.ugfx.org/
Du kannst damit bspw. die .hex einlesen und, sollte deine
Firmwareversion an einer bestimmten Adresse stehen, diese extrahieren
und anzeigen lassen.
Task 1: Load file from disk
Task 2: Read variable from RAM
Zum Schluss am besten bei "Project settings" deine Variable bei "Display
success text" mit eintragen (siehe Screenshot
http://firmwarebatchtools.ugfx.org/wp-content/uploads/2014/05/settings_project.png
)
Natürlich gibt es Hex-Viewer, die Dir am rechten Rand versuchen Text
anzuzeigen.
Das ändert aber nichts daran, dass bei Atmel's, am Programmanfang, nur
Sprungbefehle (Interrupttabelle) stehen.
Diese als Text zu interpretieren, ist bestenfalls lustig.
?!? schrieb:> Und dort sind die Byte-Werte als ASCII (pro Byte 2 Zeichen) abgelegt.> Das heißt du könntest sowieso nur die Ziffern 0..9 und die Buchstaben> A..F verwenden. Alles andere ist nicht darstellbar.
Klar. Und ein Computer kennt nur 0 und 1, alles andere ist nicht
darstellbar.
Johann L. schrieb:> Klar. Und ein Computer kennt nur 0 und 1, alles andere ist nicht> darstellbar.
Es geht hier um die ASCII-Darstellung innerhalb eine *.hex-Files. Und da
gibt es per Definition nun mal keine anderen Zeichen als die oben
erwähnten. Anders in einem Binärfile, dort kann jedes Zeichen von
0..0xFF enthalten sein.
In EPROMS wurden die Firmware-relevanten Informationen immer am Ende des
HEX-Files sichtbar.
Das wurde früher (tm) mit dem DOS-Befehl copy hex1 + hex2 hex3 erledigt.
Damit wuchs das Hexfile um die Bytes in hex2. Die wurden mitgebrannt und
enthielten deine Textstrings. K.A., wie das heute gemacht wird.
Peter Xuang schrieb:> Damit wuchs das Hexfile um die Bytes in hex2. Die wurden mitgebrannt und> enthielten deine Textstrings. K.A., wie das heute gemacht wird.
In HEX Files steht die Adresse, an der die Payload geschrieben werden
soll, als 2tes Argument pro Zeile. Da kann man nicht einfach mit copy
was zusammenbasteln, wenn sich hex1 mal in der Länge der Firmware
ändert. hex2 könnte höchstens fest kodiert aufs Ende des
Programmspeichers sein, dann klappt das. Das wiederum ist
Prozessor-abhängig. x86 z.B. hat da oben den Reset Vektor.
Siehe 'Load Offset' :
https://de.wikipedia.org/wiki/Intel_HEX#Aufbau_eines_Datensatzes
Matthias Sch. schrieb:> Peter Xuang schrieb:>> Damit wuchs das Hexfile um die Bytes in hex2. Die wurden mitgebrannt und>> enthielten deine Textstrings. K.A., wie das heute gemacht wird.>> In HEX Files steht die Adresse, an der die Payload geschrieben werden> soll, als 2tes Argument pro Zeile. Da kann man nicht einfach mit copy> was zusammenbasteln, wenn sich hex1 mal in der Länge der Firmware> ändert. hex2 könnte höchstens fest kodiert aufs Ende des> Programmspeichers sein, dann klappt das. Das wiederum ist> Prozessor-abhängig. x86 z.B. hat da oben den Reset Vektor.>> Siehe 'Load Offset' :> https://de.wikipedia.org/wiki/Intel_HEX#Aufbau_ein...
Ich hab's auch schon paarmal versucht zu erklären. Da kommen dann
Argumente wie:
Johann L. schrieb:> Klar. Und ein Computer kennt nur 0 und 1, alles andere ist nicht> darstellbar.
Klar, darstellen kann man alles mögliche. Aber man kann keinen String in
ein Hex-File reinschreiben. Auch wenn man einen Editor benutzt, der
vielleicht das Intel-Hex-Format vor dem Anzeigen dekodiert, kann man
dort nichts einfach ändern. Dann stimmen die vom Linker generierten
Adressen nicht mehr, die Segmentadressen verschieben sich und was weiß
ich noch alles. Die einzige Möglichkeit wäre, wenn der Editor
beispielsweise ein neues Segment erzeugt, wo der String untergebracht
würde. Aber wenn man den Speicher des Zielobjektes nicht kennt (z.B. ein
µC) dann kann das auch nach hinten losgehen. Das neue Segment muß ja
dann auch adressiert werden. Und dann muß das ganze veränderte File
wieder ins Intel-Hex-Format codiert werden.
Und wenn man das so macht, ist die Zeichenkette nicht im *.hex-File zu
sehen, sondern nur im dekodierten Binärfile.
Thread beobachten
Seitenaufteilung abschalten