Intel-Hex Format: erst Low- oder High-Byte?

Hallo,

da ich auf meine Anfrage nach einem ATTiny11 Programmer keine Antwort bekam, habe ich mich nun daran gemacht, selber einen Programmer zu bauen und die passende Software zu schreiben. Lediglich ein Problem gibt es da noch: wird in den Hexfiles zuerst das High- oder erst das Low-Byte angegeben? Und gleich noch eine Frage hinterher: müssen die Hexfiles immer eine gerade Zahl Bytes je Zeile enthalten (weil es sich ja um

16-Bit Speicher handelt), oder darf auch nach einer ungeraden Zahl Bytes eine neue Zeile anfangen? Über eine aufschlussreiche Antwort würde ich mich sehr freuen.

Gruß, Arne

Reply to
Arne Rossius
Loading thread data ...

Arne Rossius schrieb:

Google: 'intel hex format', 1.Hit

formatting link

Gruß Dieter

Reply to
Dieter Wiedmann

Bei mir auch.

Bitte sag mir doch noch, wo im PDF die Antwort auf meine Frage steht. Ich habe dort nämlich nichts über 16-Bit Daten gefunden.

Gruß, Arne

Reply to
Arne Rossius

Arne Rossius schrieb:

Das liegt daran, dass es im Intel-Hex Format (im Datenfeld) nur Bytes gibt. Wenn man Code für einen Intel 16-Bit Prozessor erzeugt sind die geraden Addressen für das LB und die ungeraden für das HB. Wie das dein Assembler/Compiler für den Atmel Prozessor handhabt kannst du doch leicht testen, schreib halt das ultimative Programm: .dw 1234h.

Gruß Dieter

Reply to
Dieter Wiedmann

Eine Beschreibung wäre auch in

formatting link
Heft 1 Die 16 Bit Variante ( ohne USBA ) wird z.B. für PICs 16xx ( 12 Bit ) verwendet.

Als Daten zählen dann Worte zu 16 Bit.

Wie die Bytes in den Worten angeordnet sind ist nominell wohl nicht Intel-Hex sondern prozessorspezifisch. Für den PIC 16xx wurde allerdings a la Intel little-endian genommen.

MfG JRD

Reply to
Rafael Deliano

Arne Rossius schrieb:

avrdude?

--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
 Click to see the full signature
Reply to
Joerg Wunsch

Also genau falschrum, genauer LLHH (wenn die Reihenfolge HHLL wäre, könnte man ja alle 4 Stellen als eine Zahl ansehen, deshalb ist sie IMHO falschrum).

Argh, warum bin ich da nicht selber drauf gekommen? Danke für den Tipp, jetzt weiß ich es - es ist, wie von dir oben beschrieben: :020000003412B8 ^^^^ LLHH

Gruß, Arne

Reply to
Arne Rossius

Genau. Aber darf jetzt mitten in einem Wort ein Zeilenumbruch erfolgen, so dass man immer 2 Zeilen braucht, um auf eine ganze Anzahl Wörter zu kommen? Oder müssen sich die 2 Byte eines Wortes immer in der gleichen Zeile befinden?

Danke, wie ich gerade mit Hilfe von Dieters Tip herausfand, ist es bei den AVR genauso. Liegt ja auch nahe, beim *Intel* Hex Format den Intel-Standard zu verwenden. Nur dass ich nicht wusste, dass Little-Endian Intel-Standard ist.

Gruß, Arne

Reply to
Arne Rossius

So wie ich das verstehe, kann der auch nur ISP (und das kann der Tiny11 wiederum nicht, der muss mit 12V Spannung an Reset' programmiert werden!). Aber jetzt ist es sowieso zu spät, meine (Windows-)Software und der passende Programmer ist bis auf die High/Low-Geschichte fertig und funktioniert (und in Kürze unter

formatting link
verfügbar).

Gruß, Arne

Reply to
Arne Rossius

Am Zeilenende folgt ein CR und ein LF als Zeilenendezeichen ( wiewohl es Systeme gab/gibt die in ASCII-Files nur CR oder nur LF am Ende haben ). Man wird die Zeilenlänge auf maximal 80 Zeichen begrenzen damit man auf PC keine Probleme bei Darstellung mit Texteditor hat. Wenn man das File jedoch in altertümliche Emulatoren oder Programmiergeräte schreibt kann es sein daß deren frugale Hardware die 80 Zeichen Zeilenlänge nicht puffern kann. Oft wird deshalb vorsichtshalber jede Zeile nur mit 16 Byte Data erzeugt. Nachteil offensichtlich, daß man dann deutlich längere Files bekommt. Vorteil auf PC: wenn man mit simplem Texteditor reinschaut findet man sich bei solchen kurzen Zeilen mit "gerader Startadresse" leichter zurecht als wenn man versucht genau 80 Zeichen zu machen.

MfG JRD

Reply to
Rafael Deliano

Moin,

die anderen Fragen wurden ja schon beantwortet. Das mit der ungeraden Anzahl Bytes noch nicht. AVR-GCC hat früher dummerweise mal ein Wort in zwei Zeilen verteilt. Das darf man weil die HEX-Datei byteorientiert ist. Sowas sollte man besser abfangen. Wer weiß woher die Nutzer deines Proggis ihre Daten bekommen. Ein paar andere Dinge die ich in HEX Dateien schon gesehen habe sind:

Zeile am Ende mit Spaces aufgefüllt um immer dieselbe Zeilenlänge zu bekommen. Bei PICs steht meistens nicht die Byteadresse sondern die Wortadresse * 2 ! Es kommen noch Daten hinter der Endemarkierung

:00000001FF :PIC16F873

Irgendwie macht da jeder was er will :(

Gruß Holger

--
Dipl. Ing. (FH) Holger Klabunde
http://home.t-online.de/home/holger.klabunde/homepage.htm
Reply to
Holger Klabunde

verteilt.

abfangen.

Danke für den Hinweis, da wird es wohl Zeit für eine neue Software (und das obwohl die alte noch nicht mal 2 Tage alt ist ;-().

Stört nicht, mein Programm nimmt nur soviel, wie im "length"-Feld steht. Die Checksum am Ende lässt es auch unbeachtet (wozu ist die eigentlich heute noch gut?)

Wo ist da der Unterschied (sofern man nicht innerhalb von Wörtern trennt)?

Au weia. Ich glaube kaum, dass das darf, aber ich werde vorsichtshalber eine Interpretation der Endmakierung einbauen.

Tja, wie auch sonst überall (ich sag' nur HTML...) :-((

Gruß, Arne

Reply to
Arne Rossius

Ja. Laut Standard dürfen auch ungerade Bytezahlen pro Record (also Zeile) vorkommen - je nachdem, wie es der Software, die die Datei erzeugt hat, am besten paßte.

Es kommt noch schlimmer: die Zeilen müssen IIRC nicht zu aufsteigenden Adressen gehören, sondern können theoretisch in beliebiger Reihenfolge stehen.

cu Michael

Reply to
Michael Schwingen

Aha - danke!

Uiuiui - da macht es ja wohl am meisten Sinn, die Software erst mal das Hex-File neu schreiben zu lassen, bevor programmiert wird! Wieso machen die es so kompliziert? Es sollte doch einfacher sein, den Kram in der richtigen Reihenfolge in die Datei zu schreiben, als das beim Auslesen zu korrigieren. Ich werde mich morgen mal an die neue, 100% standardkonforme (hoffentlich) Version der Programmiersoftware für den Tiny11 setzen.

Gruß, Arne

Reply to
Arne Rossius

Jein. Das Format war ztur Ansteuerung von Programmern gedacht - zu Zeiten, als über Pagemode noch niemand nachgedacht hat.

Dem Prommer ist das also völlig egal, in welcher Reihenfolge er die Daten bekommt - egal, ob er direkt brennt oder das erstmal in einen RAM-Puffer schreibt.

Dem Linker ist das aber u.U. nicht egal: wenn mehrere Segmente gemischt vorkommen (Text/Data) kann er die in der Reihenfolge, wie er die abarbeitet, wegschreiben, ohne einen Ausgabepuffer zu brauchen.

Ich sehe auch nicht ganz das Problem: Du wirst doch wohl genug RAM haben, um einen Puffer in der Größe des Targets anzulegen, oder?

cu Michael

Reply to
Michael Schwingen

Was ist denn "Pagemode"?

Stimmt, da hast du auch wieder recht. Und bei 16-Bit Programmern (wie meinem) kann man ja ganz einfach ausrechnen, an welche Adresse und Stelle (High/Low) das jeweilige Byte muss. Dass ich da nicht eher drauf gekommen bin ...

Alles klar, so ergibt das Sinn.

Könnte ich auch, aber die Idee mit dem "durcheinander-Programmieren" des AVR finde ich noch besser - wer weiß, wie viel RAM so ein Win3.0 System (auf dem meine Software ja auch läuft) noch frei hat.

Gruß, Arne

Reply to
Arne Rossius

Eine Möglichkeit bei moderneren Flashes/EEPROMs, mehrere Bytes (eben eine Page) auf einmal zu schreiben - typischerweise in fast der gleichen Zeit, die sonst ein einzelnes Byte braucht.

Na ja - für die Codegröße eines AtTiny wird es wohl noch reichen, oder?

cu Michael

Reply to
Michael Schwingen

Klingt interessant. Wie groß ist so eine "Page" normalerweise? Im Datenblatt des Tiny stand auch was von Page, aber wenn ich für jedes Byte den gesamten Adress-Selektions-Befehl wiederhole (was ich tue), ist das irrelevant.

Eigentlich[tm] schon.

Gruß, Arne

Reply to
Arne Rossius

Hallo,

nicht nur theoretisch ! Mein alter Keil 8051 Compiler macht das nur so. Adressen in nicht aufsteigender Reihenfolge. Da steigen viele von den professionellen Programmiergeräten aus. Grund: Intel8 Hex kann eigentlich nur 64kB adressieren. Sobald eine kleinere Adresse gefunden wird addieren die doch tatsächlich nochmal 64kB weil sie glauben die neue Adresse muß über der zuletzt gelesenen liegen. Das machte z.B. ein Chiplab von Dataio bei mir. Hex Dateien die mit Keil erzeugt wurden konnte man nicht mit dem Chiplab in ein Eprom brennen !

Cu Holger

--
Dipl. Ing. (FH) Holger Klabunde
http://home.t-online.de/home/holger.klabunde/homepage.htm
Reply to
Holger Klabunde

Das wäre nun wirklich das letzte, was mir einfallen würde (oder auch nicht). Wenn mir das mit dem Durcheinander niemand gesagt hätte, hätte ich vermutlich irgendwann eine Fehlermeldung eingebaut, wenn eine kleine auf eine große Adresse folgt. Aber einfach 64k addieren... Nee, sowas macht man doch nicht!

Gruß, Arne

Reply to
Arne Rossius

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.