Moin, Kann mir einer erklären, wozu man in einer Entwicklungsumgebung für embedded Systeme die Option "Create Hex File" braucht? gruß
Mit dem Hex-File kannst Du z.B. in der Produktion Deine Controller programmieren.
@ Steffan (Gast) >Kann mir einer erklären, wozu man in einer Entwicklungsumgebung für >embedded Systeme die Option "Create Hex File" braucht? Auf die Gefahr hin, mal wieder einem Troll zum Opfer zu fallen, sag ich trotzdem mal. "Create Hex File" ist der Ganze sinn der Entwicklungsumgebung, denn damit wird letztendlich die Datei erzeugt, welche in den Mikrocontroller programmiert wird.
Ich gehe mal davon aus, dass das vielfach noch Gewohnheit ist. Anno Toback, als dieses Format entwickelt wurde, gab es mehrere Gründe dafür. 1. Es berücksichtigte ein paar Eigenheiten der Intelprozessoren. (Offset- und Segment-Adressierung) 2. Es ist im Grunde ein ASCII-/Textformat. Früher gab es oft Probleme Binärdaten zu übertragen. 3. Es ist ein sicheres Format. (Prüfsummen) 4. Es ist ein kompaktes Format. 5. Es enthält die wichtigsten Strukturinformationen. Heute ist es wohl so ähnlich wie mit dem englischen. Natürlich kann man auch in der russischen Sprache alles ausdrücken, aber man hat sich nun mal in diesem, unserem Bereich aufs englische Festgelegt. Solange es keinen triftigen Grund gibt etwas anderes zu verwenden... Was dann auch alle verstehen... Grundsätzlich kann jeder einen neuen Vorschlag einbringen, dass heißt aber noch lange nicht, auch wenn er erkennbar besser ist, das ihn irgendwer verwendet. Das "Bekannte" hält sich nun mal.
Steffan schrieb: > Kann mir einer erklären, wozu man in einer Entwicklungsumgebung für > embedded Systeme die Option "Create Hex File" braucht? Weil ein Echter Programmierer (tm) ein Hexfile lesen kann wie 'ne Zeitung. Du etwa nicht?
Sry Threadstarter, ich frag hier jetzt einfach mal: Warum eigentlich nicht BIN-Format? Ich persönlich tu mich bei zwei-, lder dreistelligen Hex-Formaten, sowas wie 0xFFF schwieriger wie im Binärformat
Steffan schrieb: > Kann mir einer erklären, wozu man in einer Entwicklungsumgebung für > embedded Systeme die Option "Create Hex File" braucht? Ja, stimmt. ;-) Es gab auch schon µC, bei denen man den Quellcode downloaden konnte. Die hatten dann einen Hochsprache-Interpreter im festen ROM. Der 8052-AH-BASIC beispielsweise. Ich selbst habe sowas nie benutzt, und Kommentare und Leerzeichen dürfen in den Dateien wohl auch nicht vorhanden sein. Man brauchte also gar keinen Compiler auf dem PC, keine Entwicklungsumgebung, nur einen Texteditor. Und hat den Inhalt quasi geflasht.
ProblemKind schrieb: > Warum eigentlich nicht BIN-Format? und wo steckt du die Prüfsummen hin? Oder die Adressen wohin die Daten geschrieben werden soll?
Ganz so einfach ist das Hex-Format nun auch nicht. Lesen geht ja noch, die wenigsten können aber die Prüfsummen im Kopf bilden. Darüber hinaus kann fast kein Prozessor etwas mit dem Hex-File anfangen. Du schickst es ja zum Programmiergerät, das weiß dann was zu tun ist. Z.B. im Flash erscheinen dann ja "echte" Binärdaten. Warum nicht einfach Binärdaten: Ich denke das ist selbsterklärend. Vor dem Brennen braucht das Programmiergerät so simple Infos wie: Wie viel, wohin und so. Vor allem, wenn du dir einen eventuellen Bootloader nicht zerschießen willst, ist das echt toll.
amateur schrieb: > Ganz so einfach ist das Hex-Format nun auch nicht. > Lesen geht ja noch, die wenigsten können aber die Prüfsummen im Kopf > bilden. > Darüber hinaus kann fast kein Prozessor etwas mit dem Hex-File anfangen. > Du schickst es ja zum Programmiergerät, das weiß dann was zu tun ist. > Z.B. im Flash erscheinen dann ja "echte" Binärdaten. > Warum nicht einfach Binärdaten: Ich denke das ist selbsterklärend. Vor > dem Brennen braucht das Programmiergerät so simple Infos wie: Wie viel, > wohin und so. Vor allem, wenn du dir einen eventuellen Bootloader nicht > zerschießen willst, ist das echt toll. Das Hex-Format, ob es nun Intel oder Motorola S1 oder S2 oder S3 oder S19 oder S37 ist, hat erst mal auch das Download-Protokoll mit drin. Was da aber übertragen und ausgewertet wird, ist das Programm, wie eine EXE auf dem PC. Man kann sich diese Dateien ja auf einem Editor anschauen. Zwischen den Steuerbytespalten befindet sich original der Code in Maschinencode. Aber noch im ASCII-Format, was im Bootloader zu Zeichen umgewandelt wird. Da steckt auch Redundanz mit drin.
Ich bin mir nicht ganz sicher, was Du unter Download-Protokoll
verstehst.
Zum Intel-Hex-Format ein einfaches Beispiel:
Wenn du im Flash ab der Adresse
0x1234
die Werte
0x56 und 0x78
ablegen willst, so mußt du folgende Sequenz zum Programmiergerät
schicken:
:021234005678EA Daten
:00000001FF EOF-Sequenz
aufgedöselt bedeutet dies:
: 02 1234 00 5678 EA
: 00 0000 01 FF
Der Doppelpunkt ist der Zeilenanfang.
Der nächste Wert gibt die Anzahl an Datenbytes an (nicht Zeichen)
-Hier zwei bzw. keine
Es folgt die Adresse, an der die Daten abgelegt werden sollen.
-Hier 1234 bzw keine
Nun kommt der Datentyp
-00 "Normale" Daten, 01 EOF-Kennung, mir sind die Datentypen 02, 03, 04
und 05 bekannt
Nun kommen die Daten
-Hier 56 und 78, EOF (keine Daten)
Als letztes folgt eine Prüfsumme
-Hier EA und FF jeweils für die Zeile, in der Sie stehen.
Dein Programmiergerät sollte jetzt:
1. Alle Bytes zwischen 0x0000 und 0x1233 in Ruhe (Unverändert) lassen.
2. An Position 0x1234 den Wert 0x56 schreiben.
3. An Position 0x1235 den Wert 0x78 schreiben.
4. Alle folgenden Bytes lassen wie sie sind.
5. Feierabend machen.
Wie man diese Sequenz, mit vernünftigem Aufwand, in einem Binärformat
realisieren kann ist mir nicht ganz klar.
Falk Brunner schrieb: > @ Steffan (Gast) > >>Kann mir einer erklären, wozu man in einer Entwicklungsumgebung für >>embedded Systeme die Option "Create Hex File" braucht? > > Auf die Gefahr hin, mal wieder einem Troll zum Opfer zu fallen, sag ich > trotzdem mal. Ausnahmsweise glaube ich mal, du liegst hier falsch. > "Create Hex File" ist der Ganze sinn der Entwicklungsumgebung, denn > damit wird letztendlich die Datei erzeugt, welche in den Mikrocontroller > programmiert wird. Genau wie hier, setzt man die IDE zur Entwicklung einer Library ein, benötigt man auch kein Hex-File. Daher macht es durchaus Sinn, dies (wie z.B. Keil uVision4) als Option anzubieten. Gruß, Edson
Stimmt und stimmt gleichzeitig auch nicht. Der Sinn einer IDE ist es, möglichst komfortabel einen Prozessor zu programmieren und tatsächlich nicht ein Hex-File zu generieren. ...aber Am Beispiel einer Textverarbeitung: Der Sinn der Textverarbeitung ist es Texte zu schreiben. So weit - so gut. Manche Leute verspüren aber den nicht zu unterdrückenden Wunsch, diese auch auszudrucken. Aus diesem Grunde haben die Programmierer eine Schnittstelle zu einem Drucker implementiert. Oft PLC5, Postscript oder wie die Protokolle auch immer heißen. Wie ein Drucker funktioniert interessiert an dieser Stelle nicht. Welchen Drucker Du verwendest auch nicht. Du übergibst einfach Daten, in einem standardisierten Format - und nach mir die Sintflut. Es gibt nicht nur „deine“ Entwicklungsumgebung, manche lieben die Kommandozeile und den GNU-Compiler der u.U. versteckt unter deiner IDE lauert und die Programmierer derselben haben bestimmt keine Lust eine Schnittstelle zu jedem möglichen Programmiergerät zu schaffen. Also verwendet man ein Standartprotokoll. Das schreibt man einmal und die Sache ist gegessen. Natürlich ist es jetzt die Aufgabe eines Programmieradapterherstellers, seinen Adapter an die „üblichen“ Datenprotokolle anzupassen. Auch die sind glücklich, wenn sie mit einem Protokoll möglichst viele Kunden erreichen. Übrigens das schließt nicht aus das es andere Protokolle gibt, die vielleicht viel besser sind. Die eine oder andere Umgebung stellt dann auch diese zur Verfügung. Manchmal auch nur einen Konverter. Sind nämlich alle Informationen vorhanden, so ist eine Konvertierung meist kein Problem. Wie auch immer: Einfach binär raus reicht nicht aus - man kann sich aber über das Format streiten.
amateur schrieb: > Ich bin mir nicht ganz sicher, was Du unter Download-Protokoll > verstehst. > > Zum Intel-Hex-Format ein einfaches Beispiel: > Wenn du im Flash ab der Adresse > 0x1234 > die Werte > 0x56 und 0x78 > ablegen willst, Du mußt mir das nicht erklären. ich mache und kann das alles. Schon lange. Ein File mit Maschinencode braucht man aber auf jeden Fall, immer. Dafür ist ja der Compiler da, um es zu machen.
Steffan schrieb: > Kann mir einer erklären, wozu man in einer Entwicklungsumgebung für > embedded Systeme die Option "Create Hex File" braucht? Weil die Aufteilung des Speicherinhaltes in Hex-Zeichen wesentlich besser zur übersichtlichen Byte-Darstellung geeignet ist, als z.B. ein Binärdarstellung oder die früher auch verwendete Oktaldarstellung. Die Datei braucht man nur, wenn man das System nicht direkt aus der Entwicklungsumgebung programmieren will, sondern dazu einen separaten Programmierer verwenden möchte/muß - darum auch Option.
Wo bitte enthält ein Binärfile die Adresse, wohin die Daten geladen bzw. programmiert werden sollen? Von Sicherung gegen Fehler mal ganz abgesehen. Gruss Reinhard
elf oder coff ist auch ein Binätformat und so viel besser, als intel hex. Binärformat muss ja nicht heißen, dass nur die Rohdaten enthalten sein müssen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.