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

[Arne Rossius]

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

 

[Dieter Wiedmann]

Arne Rossius schrieb:

Über eine aufschlussreiche Antwort würde ich mich sehr freuen.

Google: 'intel hex format', 1.Hit

http://www.interlog.com/~speff/usefulinfo/Hexfrmt.pdf


Gruß Dieter

 

[Arne Rossius]

Dieter Wiedmann wrote:

Google: 'intel hex format', 1.Hit

Bei mir auch.

http://www.interlog.com/~speff/usefulinfo/Hexfrmt.pdf

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

 

[Dieter Wiedmann]

Arne Rossius schrieb:

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.

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

 

[Rafael Deliano]

Eine Beschreibung wäre auch in http://www.embeddedFORTH.de Heft 1
Die 16 Bit Variante ( ohne USBA ) wird z.B. für PICs 16xx
( 12 Bit ) verwendet.

Und gleich noch eine Frage hinterher: müssen die Hexfiles
immer eine gerade Zahl Bytes je Zeile enthalten
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

 

[Joerg Wunsch]

Arne Rossius <ArneRossius@despammed.com> schrieb:

da ich auf meine Anfrage nach einem ATTiny11 Programmer keine
Antwort bekam, ...

avrdude?

--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
Kristian Köhntopp, de.comp.os.unix.misc

 

[Arne Rossius]

Dieter Wiedmann wrote:

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.

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

Wie das dein Assembler/Compiler für den Atmel Prozessor handhabt
kannst du doch leicht testen, schreib halt das ultimative Programm:
.dw 1234h.

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

 

[Arne Rossius]

Rafael Deliano wrote:

Und gleich noch eine Frage hinterher: müssen die Hexfiles
immer eine gerade Zahl Bytes je Zeile enthalten
Als Daten zählen dann Worte zu 16 Bit.

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?

Für den PIC 16xx wurde allerdings a la Intel
little-endian genommen.

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

 

[Arne Rossius]

Joerg Wunsch wrote:

avrdude?

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
http://www.elektronik.de.vu/schalt/mikro/attiny11.htm verfügbar).


Gruß,
Arne

 

[Rafael Deliano]

Aber darf jetzt mitten in einem Wort ein Zeilenumbruch erfolgen,
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

 

[Holger Klabunde]

Moin,

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?

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
IC16F873

Irgendwie macht da jeder was er will

Gruß
Holger

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

 

[Arne Rossius]

Holger Klabunde wrote:

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.

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 ;-().

Zeile am Ende mit Spaces aufgefüllt um immer dieselbe Zeilenlänge zu bekommen.

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?)

Bei PICs steht meistens nicht die Byteadresse sondern die Wortadresse * 2 !

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

Es kommen noch Daten hinter der Endemarkierung

:00000001FF
IC16F873

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

Irgendwie macht da jeder was er will

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


Gruß,
Arne

 

[Michael Schwingen]

In article <vgejm0tmw7b1.dlg@elektronik.de.vu>,
Arne Rossius <ArneRossius@despammed.com> wrote:

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?

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

 

[Arne Rossius]

Michael Schwingen wrote:

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.

Aha - danke!

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

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

 

[Michael Schwingen]

In article <17j7bls0chuh4.dlg@elektronik.de.vu>,
Arne Rossius <ArneRossius@despammed.com> wrote:

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.

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

 

[Arne Rossius]

Michael Schwingen wrote:

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

Was ist denn "Pagemode"?

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.

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

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.

Alles klar, so ergibt das Sinn.

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?

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

 

[Michael Schwingen]

In article <1tevhkdlha3ra.dlg@elektronik.de.vu>,
Arne Rossius <ArneRossius@despammed.com> wrote:

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

Was ist denn "Pagemode"?

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.

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.

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

cu
Michael

 

[Arne Rossius]

Michael Schwingen wrote:

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.

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.

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

Eigentlich[tm] schon.


Gruß,
Arne

 

[Holger Klabunde]

Hallo,

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.

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

 

[Arne Rossius]

Holger Klabunde wrote:

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