HEX Datei wird zu groß

[miranda (Gast)]

Hilfe!

Ich schreibe ein Programm für Atmega 16 mit AVRStudio. Benutze 
Schleifen, Switch-Block, Struckturen und Funktionen. Die HEX-Datei für 
den Controller wird bald zu groß, obwohl ich noch nicht so viel gemacht 
habe.
Kann mir jemand sagen, was ich vermeiden soll, damit die HEX-Datei nicht 
zu groß wird und in den Flash reinpasst.

Danke

[Karl H. (kbuchegg)]

Die Größe der HEX Datei ist ein eher schlechter Indikator
für die Größe des Programms. Als Faustregel: Eine HEX-Datei
ist ca. 3 mal so gross wie das eigentliche Programm, so wie
es dann zum AVR übertragen wird.

> Kann mir jemand sagen, was ich vermeiden soll

Keine unnötigen Dinge programmieren. Den Optimizer einschalten.
Ansonsten gibt es nicht viel. Wenn dein Programm gewisse Dine
tun soll, dann muss es diese Dinge auch tun. Und das bedeutet nun
mal Programmcode dafür.

Edit: Ach ja. Mach einen grossen Bogen um Fliesskommaarithmetik.
Die schlägt richtig heftig zu Buche.

[Wolfram Quehl (Gast)]

Nicht in C sondern in assembler programmieren. Evtl. kann man sich auch 
den übersetzten C Code in Assembler ansehen und darin was ändern und 
anschließend mit dem Assembler übersetzen.
Statt mega16 den mega32 oder mega644 verwenden.

mfg

[Horst Gschwandtner (Gast)]

> Nicht in C sondern in assembler programmieren. Evtl. kann man sich auch
> den übersetzten C Code in Assembler ansehen und darin was ändern und
> anschließend mit dem Assembler übersetzen.
> Statt mega16 den mega32 oder mega644 verwenden.

Mit heutigen C Compilern muss man schon richtig gut Assembler können um 
eine bessere Dichte zu erzeugen. Ich denke, dass sonst ein 
Assemblerprogramm (ausser bei ganz kleinen Projekten) sich mit der Zeit 
mehr aufbläst als ein C Programm, ausser es ist ein Assembler Experte am 
Werk.

[Rahul D. (rahul)]

Wolfram Quehl wrote:
> Nicht in C sondern in assembler programmieren. Evtl. kann man sich auch
> den übersetzten C Code in Assembler ansehen und darin was ändern und
> anschließend mit dem Assembler übersetzen.
> Statt mega16 den mega32 oder mega644 verwenden.
>
> mfg

Da hat mal wieder jemand nicht verstanden, was das Problem ist:
Eine (Intel-)Hex-Datei enthält einen "Overhead", damit das 
Programmier-Werkzeug weiß, an welche Adresse es welche Daten schreiben 
soll.
Zwecks Überprüfung der Richtigkeit der Daten ist auch noch eine 
Prüfsumme beigefügt.
Damit man als Mensch die Datei auch noch lesen kann, sind die einzelnen 
Byte auch noch als ASCII-Zeichen aufgeführt, was schon mal dazu führt, 
dass der Quellcode schon mal doppelt so lang ist, wie sie als Binärdatei 
wäre.

http://www.roboternetz.de/wissen/index.php/HEX-Datei

Es hat überhaupt nichts damit zu tun, wie das Programm erstellt wurde.
Selbst ein Assembler erzeugt HEX-Dateien, wenn er das Programm 
assembliert.
Der einzige Unterschied zwischen Assemler und einer Hochsprache ist, 
dass der Compiler und der Rest der Werkzeugkette dem Programmierer 
"lästige" Tätigkeiten wie Register-auf-Stack-Rettung, Beschreiben der 
Interrupt-Vektor-Tabelle etc., sowie kompliziertere Berechnungen 
abnimmt.
Der Vergleich zwischen Assembler (eigentlich auch eine Hochsprache im 
Gegensatz zum manuellen programmieren eines Controllers mit Hilfe von 
Schaltern und Tastern...) und einer Hochsprache ist also völlig 
sinnfrei.
Assembler kann man bis zu einer gewissen Projektgrösse (auch die Anzahl 
der mitarbeitenden zählt) benutzen. Ab einer bstimmten Grösse verliert 
man den Überblick.

Mir fällt da immer das allseits beliebte Zitat von Dieter Nuhr ein...

[gast (Gast)]

Bei avr-studio wird jedesmal bein bauen angezeigt wie voll der Flash 
schon ist... kA wie die das machen

sonst bauen auf jeden Fall mit -Os das spart ordentlich

[Rahul D. (rahul)]

>Bei avr-studio wird jedesmal bein bauen angezeigt wie voll der Flash
>schon ist... kA wie die das machen

Die interessieren sich auch nicht für das HEX-File...

[Wolfram Quehl (Gast)]

ich habe das schon verstanden, habe mir die Hex Datei auch mal 
angesehen. Aber bei jeder Übersetzung wird doch der Speicherverbrauch 
angegeben und da habe ich vermutet, daß der angegebene Speicherverbrauch 
höher ist als der Mega16 fassen kann.

mfg

[Christian U. (z0m3ie)]

Der Speicherverbrauch kann beim gcc nicht höher sein als das Target 
fassen kann. Der Linker prüft nämlich automatisch wie "voll" der Flash 
schon ist wenn er zu voll ist bekommt man das Projekt erst gar nicht 
gelinkt. Die Diskussion mein Controller ist so schnell voll hab ich auch 
ständig mit Kumpels die mit AVR anfangen. Da wird mal schnell ne LCD 
Library genommmen noch Floating Point mit eincompiliert und dann heissts 
Hilfe ich hab nur 20 Zeilen in meinem Hauptprogramm stehen und mein 
Controller ist schon zu 40% voll ich brauch nen grösseren Controller ...

[Bernhard Walle (Gast)]

Schau dir mal avr-size an (ist bei den binutils dabei).

[Horst Gschwandtner (Gast)]

> Da hat mal wieder jemand nicht verstanden, was das Problem ist:
> Eine (Intel-)Hex-Datei enthält einen "Overhead", damit das
> Programmier-Werkzeug weiß, an welche Adresse es welche Daten schreiben
> soll.
> Zwecks Überprüfung der Richtigkeit der Daten ist auch noch eine
> Prüfsumme beigefügt.
> Damit man als Mensch die Datei auch noch lesen kann, sind die einzelnen
> Byte auch noch als ASCII-Zeichen aufgeführt, was schon mal dazu führt,
> dass der Quellcode schon mal doppelt so lang ist, wie sie als Binärdatei
> wäre.

Ich glaub schon, dass er verstanden hat worum es geht. Wenn jemand sagt, 
die Hex datei passe nicht dann glaube ich ist nicht gemeint, dass die 
Hex Datei selbst zu groß ist sonder dass sie zu weit geht (z.B. bis 
10400 und der Controller kann nur bis FFFF).