Forum: Compiler & IDEs Atmelstudio: Wie Zeilen mit 0xFF entfernen aus hex-File ?


von mega_clever (Gast)


Lesenswert?

Hallo zusammen,

ich habe festgestellt, dass das Atmelstudio nicht belegte Bereiche im 
hex-File mit 0xFF auffüllt. Wie kann ich dies verhindern?

Hintergrund:
Bevor ich einen Chip programmiere wird ein Chiperase durchgeführt. Nach 
dem Chiperase ist der komplette Speicher mit 0xFF gefüllt. Beim 
Programmieren werden die 0xFF-Bytes aus dem Hex-File programmiert, 
obwohl das Byte ja schon durch das Löschen den Wert 0xFF hatte. Dies 
kostet unnötig Programmierzeit. Ich habe jetzt mal testweise manuell 
alle

:1059D000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD7

Zeilen entfernt. Und siehe da, die Progammierzeit hat sich erheblich 
reduziert.

Jetzt gibt es zwei Möglichkeiten:

1) Schon beim der HEX-File-Erzeugung verhindern, dass die nicht belegten 
Bereiche im Hex-File landen. Wie geht das?

2) Nachträglich mit einem Tool die 0xFFen entfernen. Gibt es hierfür ein 
Tool?

Oder gibt es noch anderen Möglichkeiten?

Viele Grüße
Tron

von Hendrik L. (hlipka)


Lesenswert?

'grep -v' gibt nur die Zeilen aus die nicht auf das angegebene Pattern 
passen - damit kanst Du alle Zeilen die nur aus 0xFF bestehen 
rauswerfen.

von Mike (Gast)


Lesenswert?

Das SRecord Tool kann das: https://sourceforge.net/projects/srecord/

von Mike (Gast)


Lesenswert?

Aus dem Manual: srecord-1.64.pdf (Seite 45)

Unfilling the Blanks
It is common to need to “unfill” an EPROM image after you read it out of 
a chip. Usually, it will have had
all the holes filled with 0xFF (areas of the EPROM you don’t program 
show as 0xFF when you read them
back).
To get rid of all the 0xFF bytes in the data, use this filter:
srec_cat infile −unfill 0xFF −o outfile
This will get rid of all the 0xFF bytes, including the ones you actually 
wanted in there. There are two ways
to deal with this. First, you can specify a minimum run length to the 
un-fill:
srec_cat infile −unfill 0xFF 5 −o outfile
This says that runs of 1 to 4 bytes of 0xFF are OK, and that a hole 
should only be created for runs of 5 or
more 0xFF bytes in a row. The second method is to re-fill over the 
intermediate gaps:
srec_cat outfile −fill 0xFF −over outfile \
−o outfile2
Which method you choose depends on your needs, and the shape of the data 
in your EPROM. You may
need to combine both techniques.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

mega_clever schrieb:
> ich habe festgestellt, dass das Atmelstudio nicht belegte Bereiche im
> hex-File mit 0xFF auffüllt.

"das Atmelstudio" baut gar keine Hexfiles.

Die bauen die Tools.

Die füllen nicht freiwillig und kein 0xff; es muss also einen Grund 
geben. Daher solltest du hier konkrete (Code-)Beispiele präsentieren.

Außerdem: warum überhaupt Hexfiles und nicht gleich das ELF-File?

von mega_clever (Gast)


Lesenswert?

Mike und Hendrik
Danke für die Tipps. Werde ich morgen mal austesten. Die beste Lösung 
wäre aber die Daten nicht nachträglich zu entfernen sondern von Anfang 
an zu verhindern, dass nicht benutzter Speicher im Hex-File auftaucht.

von mega_clever (Gast)


Lesenswert?

Jörg W. schrieb:
> "das Atmelstudio" baut gar keine Hexfiles.
>
> Die bauen die Tools.
>
> Die füllen nicht freiwillig und kein 0xff; es muss also einen Grund
> geben. Daher solltest du hier konkrete (Code-)Beispiele präsentieren.
>
> Außerdem: warum überhaupt Hexfiles und nicht gleich das ELF-File?


Das ist mir schon klar, das die unterlagerte Toolchain (gnu) das 
Hex-File generiert. Ich habe im Atmelstudio keine Möglichkeit gefunden, 
um den Aufbau des Hex-Files beeinflussen zu können. Vermutlich müsste 
ich manuell Änderungen am vom Atmelstudio erzeugten makefile vornehmen.
Vermutlich erzeugt der Linker das Hex-File. Ich schau mir morgen mal das 
Makefile an.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

mega_clever schrieb:
> Vermutlich erzeugt der Linker das Hex-File.

Nein, der erzeugt ein ELF-File. Das Hexfile wird erst danach draus 
gebaut. (Daher auch mein Hinweis, gleich das ELF-File zu nehmen.)

Wie geschrieben: schick mal ein Beispiel. Also nicht vom Hexfile, 
sondern Beispiel-Source und Makefile.

: Bearbeitet durch Moderator
von mega_clever (Gast)


Lesenswert?

Jörg W. schrieb:
> Außerdem: warum überhaupt Hexfiles und nicht gleich das ELF-File?

Das ist auch ein gute Idee. Ich werde mal die Programmierung 
(atprogram.exe) mit dem elf-File durchführen anstatt mit dem hex-File. 
Eventuell werden dann nur die notwendigen Bytes programmiert.

von Kaj (Gast)


Lesenswert?

Wie viele Controller musst denn so am Tag flashen, dass das wirklich 
eine Rolle spielt?

von Thomas (kosmos)


Lesenswert?

im .elf sind doch auch die ganzen Fuses mit drin, so das die dann auch 
jedesmal mitprogrammiert werden?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Die Fuses sind nur drin, wenn man sie im Quellcode angibt.

Ansonsten muss man natürlich gucken, welche Teile aus dem ELF man 
tatsächlich programmieren will. Das wird man ja wohl auch bei 
atprogram.exe irgendwie angeben können.

Bitte 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
Noch kein Account? Hier anmelden.