Hallo , ich blicke mal wieder nicht durch und brauche Hilfe . Ich benutze Basccom und bekomme beim compilieren eine Hex und eine Bin Datei. Die HexDatei ist ca 3 x so groß wie die Bin . Kann man auch die BinDatei in den MC laden ? Hat ein AtMega8 einen Speicher für 8kB Bin oder 8kB Hex ? Ich habe schon in anderen Quellen gesucht aber keine richtige Antwort erhalten . MfG Hans
Hans Lang schrieb: > Ich habe schon in anderen Quellen gesucht aber keine richtige Antwort > erhalten . dann hast du etas überlesen: http://de.wikipedia.org/wiki/Intel_HEX
Hans Lang schrieb: > Hat ein AtMega8 einen Speicher für 8kB Bin oder 8kB > Hex ? Der wesentliche Inhalt ist der gleiche, Hex ist nur eine andere Darstellung, die aber ein paar Vorteile hat: 1. Textdatei, mit Editor lesbar - für BIN braucht man einen Hex-Editor, und dann sieht die Anzeige ganz ähnlich aus wie beim HEX File sowieso. 2. Gesichert: nach jeder Datenzeile folgt eine Prüfsumme. 3. Zusatzinformationen: es können ausser dem direkten Speicherinhalt auch Adressinformationen enthalten sein, ein BIN File hat keine, da muss man wissen, wohin es zu laden ist, wenn das eine andere Adresse als 000000 ist. Es sind auch zusätzliche Angaben möglich wie Datum, Version, Kommentare, aber das wird selten benutzt. Ob man 8 kB BIN oder HEX lädt ist egal, der Inhalt muss danach exakt der gleiche sein, sonst ist eine der Dateien fehlerhaft. Gruss Reinhard
Reinhard Kern schrieb: > Ob man 8 kB BIN oder HEX lädt ist egal, der Inhalt muss danach exakt der > gleiche sein, sonst ist eine der Dateien fehlerhaft. Nicht ganz. BIN ist lückenlos ab der Startadresse, bei HEX können Lücken sein. Was an den Stellen dann steht, hängt von der Vergangenheit des Speichers ab, ist bzgl. der Funktion aber egal. Anwendungsbeispiel: am Ende des Programmspeichers wird die Versionsnummer abgelegt. Gruß Dietrich
Hallo , wenn ich das jetzt richtig verstanden habe wird bei der Hex-Datei nur der "Datenanteil" in den MC übertragen . Es kann eine Datei mit z. B. 20kB in einen ATMega 8 passen ? MfG Hans
In einer Hex-Datei steht drinnen "Ab Adresse 0x0000 kommen 8 Bytes mit den Werten 0x00, 0x40, 0x80, 0x18, 0x23, 0x78, 0x98, 0xA0. Das macht eine Quersumme von 0x87 Ab Adresse 0x0008 kommen 5 Bytes mit den Werten 0xFF, 0x87, 0x43, 0xFF, 0x00, mit der Quersumm von 0xA4" (ok, nicht so in Prosa sondern in Form von Codezahlen, aber im Prinzip läuft es darauf hinaus) In der Bin Datei steht drinnen (als Binärzahlen) 0x00 0x40 0x80 0x18 0x23 0x78 0x98 0xA0 0xFF 0x87 0x43 0xFF 0x00 (also ein File mit einer Länge von 13 Bytes) Klar ist die HEX-Form 'geschwätziger'. Die Nutz-Information in ihr ist allerdings 1:1 dieselbe wie in der BIN-Datei. Nur eben in einer anderen Form präsentiert Als Daumenregel kann man sagen: Nimm die Größe deiner HEX-Datei, dividiere durch 2.5 und du hast ungefähr die tatsächliche Anzahl an Bytes, die dann tatsächlich gebrannt werden. Bei 20K sind also ungefähr 8KB (+- ein paar Zerquetschte) an Nutzbytes im Hex-File.
Hans Lang schrieb: > Hallo , > wenn ich das jetzt richtig verstanden habe wird bei der Hex-Datei nur > der "Datenanteil" in den MC übertragen. jain, die Datei im HEX oder BIN Format, wird nicht in den µC geladen, sondern ist nur der Weg vom Compiler zum Brennprogramm. Das Brennprogramm schreibt dann die entsprechenden Binärdaten, die in beiden Dateien identisch enthalten sind, in den µC. > Es kann eine Datei mit z. B. > 20kB in einen ATMega 8 passen ? ja das kann sie. Wieviel Platz dein Programm braucht, sollte dir aber auch dein Compiler anzeigen können. Sascha
Reinhard Kern schrieb: > 3. Zusatzinformationen: es können ausser dem direkten Speicherinhalt > auch Adressinformationen enthalten sein, ein BIN File hat keine, da muss > man wissen, wohin es zu laden ist, wenn das eine andere Adresse als > 000000 ist. Es sind auch zusätzliche Angaben möglich wie Datum, Version, > Kommentare, aber das wird selten benutzt. Mehr noch: Bei Hex-Files sind Overlays möglich. Im Ziel landet natürlich für jede Adresse nur der im Hexfile zuletzt aufgeführte Inhalt. Aber nicht notwendigerweise ist ja das Flashen des Ziels direkt der Endzweck des Hexfiles. Mit dieser Eigenschaft kann man z.B. eine Art primitiven "Linker" für Spezialanwendungen basteln. Also insbesondere auf einfache Weise Informationen in den Code einfügen, die zum Zeitpunkt der Programmerstellung noch garnicht verfügbar waren, sondern erst zum Zeitpunkt des Flashens verfügbar werden, wobei der "Flasher-Guy" nur das Hexfile hat und auch nur dieses bekommen soll und nicht etwa den kompletten Quelltext samt Entwicklungsumgebung. Einfach nur deshalb, weil er damit sowieso nicht wirklich etwas anfangen könnte... Übrigens wird das Overlay-Feature in Hexfiles auch ohne eine solche "Spezialanwendung" tatsächlich praktisch benutzt, nämlich z.B. vom Atmel-AssemblerV2, jedenfalls wenn man dessen OVERLAP-Direktive benutzt und dann auch tatsächlich einen solchen produziert. Auch das kann durchaus nützlich sein. Damit lassen sich Sachen recht einfach und doch einigermaßen zuverlässig realisieren, die mit einem normalen Linker erst garnicht möglich sind. Nunja, hier muß natürlich der Ehrlichkeit halber auch erwähnt werden, daß sowas auch eher unter dem Begriff "Spezialanwendung" zusammenzufassen wäre... Ich persönlich nutze es aber tatsächlich. Sogar fast bei jedem Projekt. Auf jeden Fall bei jedem Projekt, in dem irgendwo ein "sei" vorkommt.
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.