Hi! Ich wollt mal fragen, was eigentlich mein Compiler für ein ergebniss erzeugt. Das was aus dem compiler herauskommt ist ja eine Hexdatei. Wenn ich das richtig verstanden habe sind da auch die adressen drin gespeichert. Wenn also beispielsweise meine hex Datei 1,37 KB gross ist ist sie später im avr nicht mehr 1,37 KB gross weil die adressennicht mit gepeichert werden. Was ist eigentlich der unterschied zwischen Hexdateien und Binaries? Kann ich Binaries auch im avrstudio erzeugen ? MfG Erni
Eine Hex-Datei ist - wie der Name bereits sagt - eine hexadezimale Repräsentation der vom Compiler erzeugten Binärdaten. Sie ist damit mehr als doppelt so groß wie "nackte" Binärdaten, da zur Darstellung eines Bytes zwei Zeichen benötigt werden und desweiteren Adressinformationen und Prüfsummen in der Datei enthalten sind. Üblich ist hier das Intel-Hex-Format, eine Alternative ist noch das seltenere Motorola S19-Format. Eine Hexdatei ist also ein Binary, nur in einem etwas anderen Format.
Der alte Galep-I z. B. brauchte Binärdateien, wenn mein ein EPROM programmieren wollte. Leider kann AVR Studio keine Binärdateien erzeugen, dazu gibt es aber ungefähr 100000 Freewaretools für alle Betriebssysteme und mindestens genau so viele Nichfreewaretools. Dieses hier hab ich mal benutzt: http://sourceforge.net/projects/hex2bin Gruß Thorsten
Bei AVR-GCC braucht man nichtmal ein separates Tool: avr-objcopy, das bereits benutzt wird, um die Hex-Datei zu erzeugen, kann genauso gut auch gleich eine Binärdatei erzeugen.
Eine Windows Datei (PE-Format, *.exe) ist im Binary Format. Das Würde Dann ja bedeuten, dass Ein HexEditor die Datei im HexFormat darstellt und sie vor der darstellung in ein Hexformat umwandeln muss. Liege ich da richtig ?
Ach ja noch was: ist die Binary Datei genau so groß wie der coder , der später im speicher meines AVRs liegt ? Oder sin da auch wider so unnütze infos drinne wie adressen... ? MfG
Die Binärdatei ist ein Abbild des (Flash-)ROMs des Microcontrollers. Die Adressen als "unnütze Infors" zu bezeichnen ist allerdings ... fragwürdig.
Wiso sind die Adressen nicht überflüssig ? man kann sie doch berechnen! und wiso sollte ich sowas mit in eine datei schreiben (aussen aus irgendwelchen prüfungs zwecken) ??
Btw., PE-COFF ist kein reines Binärformat in diesem Sinne, sondern immer noch ein Objektformat. COFF ist dabei der Vorläufer von ELF, welches die GNU Toolchain benutzt. Beiden gemeinsam ist, dass die Objektdatei deutlich mehr an Informationen enthält, als dann tatsächlich in den Speicher geladen wird (mindestens noch section headers, u. U. auch eine Symboltabelle und/oder Debug-Infos).
Die Adressen sind deshalb nicht überflüssig, weil ein Hex-File so auch Lücken enthalten kann. Damit werden nur die wirklich notwendigen Teile des ROMs programmiert, auch wenn nicht "von vorne" angefangen wird. Das ist beispielsweise beim Mega128 sinnvoll - wird ein 1 kByte großes Programm geladen, muss die Binärdatei keine 128 kByte groß sein, auch wenn das erste und letzte Byte im ROM zu programmieren ist. Ein Hexeditor ist übrigens was ganz anderes. Der stellt jedes in einer Datei enthaltene Byte in hexadezimaler Form dar und gibt noch den Offset relativ zum Dateianfang aus, ohne dabei in irgendeiner Art und Weise auf die Art der Datei einzugehen. Hex-Dateien wie Intel-Hex und Motorola S19 enthalten je Zeile auch eine Prüfsumme, so daß Dateiübertragungsfehler beim Download in Programmiergeräte erkannt werden können.
Was ist eigentlich ein Offset ? Ist das z.B. wenn ein header am anfang der datei ist...dann wär der offset quasi die stelle wo der eigentliche programmcode beginnt (und wo wieder von 0x00 gezählt wird). Oder ?
Du kannst Offset in diesem Zusammenhang recht gut mit Versatz übersetzen. Ein Offset gibt immer einen Abstand zu einem Fußpunkt an, um damit wieder eine Position zu beschreiben. Ein Offset relativ zum Dateianfang ist in dem Fall das gleiche wie ein absoluter Offset, und wenn Du die gesamte Datei als einen Adressraum siehst, dann ist er gleich der absoluten Adresse. Wenn Du Dir einen beliebigen Punkt raussuchst, und sagst "Drei Byte weiter", dann ist der beliebige Punkt der Fußpunkt, die +3 Byte der Offset. Dieser Offset ist relativ zum Fußpunkt zu verstehen und ohne diesen nicht zu gebrauchen. Von diesem Punkt aus gesehen ist "+3" eine relative Adresse, die zusammen mit der absoluten Adresse des Fußpunktes wieder eine absolute Adresse bildet. Eine absolute Adresse ist also eine relative Adresse vom Nullpunkt aus, und in allgemeiner Form gilt das für Offsets. Wichtig ist, daß Offset = Adresse nur gilt, wenn der Anfang des Images an der Adresse 0 liegt. Wenn jetzt ein Binary z.B. in den Speicher geladen wird, um ausegführt zu werden, dann landet es u.U. an einer anderen Stelle, und die Adressen für Sprünge etc. müssen angepasst werden. Dafür sind z.T. die zusätzlichen Informationen in der Objektdatei nötig. Bei einem AVR ist das in sofern einfacher, als daß man dort genau beeinflussen kann, wo das Image landet, und die Rechnereien daher quasi off-line erledigen kann. Wenn da ein Betriebssystem drunter liegt, ist's kniffliger, und bei dynamischen Zeugs wie DLLs in der Windows-Welt versagt es gänzlich, weil der Code vorher absolut nicht weiß, wo er landen wird. Ein Header muss jetzt nur seine eigene Länge kennen, damit hast Du den Offset zum Anfang des Maschinencodes (oder was auch immer er kapselt, TCP/IP, MPEG, ...), falls nicht noch weitere Header folgen. Üblicherweise sollte aber ein Header auf sein Ende verweisen, um nicht weitere Header zu überspringen (wäre dann eine aufgeweichte Form von Verpackung, im Allgemeinen kein gutes Zeichen). So bilden sich dann bei manchen Anwendungen ganze Kolonnen von Headern, die Daten kommen in einen Umschlag, der Umschlag in eine Tüte, die Tüte in einen Karton, und der wird der Post übergeben.
Meine Güte, ich habe gerade mal im Dosfenster "avr-objcopy" eingetippt. Bei diesen vielen Optionen vergeht einem ja schon wieder die Laune, sich mit dem Tool näher auseinander zu setzen, nicht zu fassen! Wie war das, WinAVR ist eine Portierung für Windows kommend aus der Linux Welt? Wäre ja auch ein Wunder, wenn es da mal was gibt das einfach und intuitiv bedienbar ist. Und dann soll mir nochmal jemand sagen, Linux sei ne Alternative.
Du darfst Dich von der --help Ausgabe nicht erschrecken lassen, die ist im Grunde nur als Spicker zu gebrauchen. Wenn man nicht mehr weiss, wie eine Option hiess, man sie aber wiedererkennt, weil man sie schonmal kannte. Beurteile die Schrecklichkeit einer Software lieber an der Dokumentation (also Manpages, info-Dokumente etc.), da bekommt man einen viel tieferen Einblick. Dort finde ich avr-objcopy sogar überraschend freundlich, es gibt Dinge da verliert man viel stärker die Lust. OK, kann auch daran liegen, daß ich zu lange FreeBSD-geschädigt bin und mich von sowas nicht erschrecken lasse :-) Was wirklich widerlich ist, ist Software die keine brauchbaren Fehlermeldungen gibt, wenn was nicht klappt. Ich kriege jedesmal einen dicken Hals wenn ich yaap verwende, die Meldungen sind z.T. sowas von nichtssagend, gruslig.
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.