Firmwareinfo im Flash / hexfile

http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Speicherzugriffe

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...

?!? 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 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.

bal schrieb:
> Ich schlage vor du liest dich erstmal hierrüber ein.

Das glaube ich auch.
Hast du einen Link oder ein Schlagwort wonach ich suchen soll?

Aber wie komme ich jetzt an die Textinfos, die ich haben möchte? Welchen 
Viewer oder welches Programm benötige ich nun?

Tobi schrieb:
> Hast du einen Link oder ein Schlagwort wonach ich suchen soll?

bal schrieb:
> ... Format "Intel Hex".

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.

Georg G. schrieb:
> Der AT90CAN128 hat 128MBytes Flash.

Genial!
Wo kann ich den kaufen?

Gruss

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 ":".

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.

Amateur schrieb:
> Natürlich gibt es Hex-Viewer, die Dir am rechten Rand versuchen Text
> anzuzeigen.

Aber nicht, wenn du ein *.hex-File damit geöffnet hast.
http://de.wikipedia.org/wiki/Intel_HEX#Beispiel

@!?!
>Aber nicht, wenn du ein *.hex-File damit geöffnet hast.

Bist Du Dir sicher?

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.

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.