Forum: Compiler & IDEs Frage zu Programm Optimierung (Größe)


von Fer T. (fer_t)


Lesenswert?

Hallo,
Ich habe kein wirkliches Problem, aber ich frage mich gerade:
Ist es normal, dass ein Programm das die normalen LCD Lib hier von 
Mikrocontroller.net enthält gleich 7 Kb groß ist?
Oder liegt das an meinem Programm?
Also ich habe ein nicht sehr großes Programm für einen AtMega8(8) 
geschrieben, und nach dem kompilieren und Linken ist das gesamte Projekt 
7,3 Kb groß (HEX Datei), was schon an die grenzen des Speichers kommt.
Dabei nutze ich einfach dieses Programm von mir: 
http://pastebin.com/BaS1BAEE
Und die LCD Lib von hier.
Im Makefile habe ich auch die Optimierung auf Größe gestellt, aber 
erhalte wie erwähnt, die 7,3 Kb....
Daher auch meine Frage ob jemand weiß, wie ich das Programm noch 
optimieren kann. Weil laufen tut es, aber ich finde es doch sehr komisch 
mit der Größe...
MfG,
Fer

von g457 (Gast)


Lesenswert?

> double Sievert;

..bringt Dir grob 4kiB Codegrößenzuwachs.

HTH

von Peter D. (peda)


Lesenswert?

Float braucht etwa 1kB.
Beim AVR-GCC: double = float
Sprintf ist recht teuer und mit float nochmal deutlich teurer.


Peter

von Fer T. (fer_t)


Lesenswert?

danke, gib es eine Alternative zu sprintf?
Float muss ja leider sein, eine kleinere kommazahl Art gibt es ja leider 
nicht, oder?
MfG

von Peter II (Gast)


Lesenswert?

Fer T. schrieb:
> Float muss ja leider sein
Warum?

von Klaus (Gast)


Lesenswert?

Peter II schrieb:
> Fer T. schrieb:
>> Float muss ja leider sein
> Warum?

Weil

Fer T. schrieb:
> Float muss ja leider sein, eine kleinere kommazahl Art gibt es ja leider
> nicht, oder?

Eigentlich braucht man dafür einen anständigen Floatingpoint DSP (SCNR)

MfG Klaus

von U.R. Schmitt (Gast)


Lesenswert?

Fer T. schrieb:
> Float muss ja leider sein, eine kleinere kommazahl Art gibt es ja leider
> nicht, oder?
Die Zauberformel heisst meistens Festkommaarithmetik. Man muss nur etwas 
Gehirnschmalz reinstecken und prüfen wie groß die Zahlen werden können 
und in welcher Reihenfolge man dann Zahlen geschickt multipliziert und 
dividiert ohne zu große Rundungsfehler oder Überläufe zu bekommen.
sprintf ist bequem, aber man kann sich auch kleine Ausgabeformatierungen 
selber schreiben und spart so Platz. itoa und ltoa sind hier deine 
Freunde.

von Klaus F. (kfalser)


Lesenswert?

Fer T. schrieb:
> 7,3 Kb groß (HEX Datei)

Ist die Hex Datei 7 KB groß?
Die Größe der Hex-Datei ist nicht die Größe des Programms.

von Karl H. (kbuchegg)


Lesenswert?

Fer T. schrieb:
> danke, gib es eine Alternative zu sprintf?
> Float muss ja leider sein, eine kleinere kommazahl Art gibt es ja leider
> nicht, oder?

Wie schon gesagt:
Nö, muss nicht.
Überleg dir mal, worin wohl der Unterschied besteht, wenn du deine 
Restaurantrechnung in Euro bzw. wenn du sie in Cent zusammenzählst. Beim 
einen (Euro) hast du Kommastellen, beim anderen (Cent) hast du keine. 
Zugegeben, die Zahlen sind größer, wenn man in Cent rechnet, aber das 
ist ja beherrschbar. Und wenn man in Cent rechnet, ist es ja auch kein 
großes Problem, aus den Cent zu Anzeigezwecken wieder Euro zu machen, 
mit einem gefakten Dezimalkomma.

Aber wenn du schon float/double benutzt, dann solltest du das auch 
richtig machen.

   int click;
   double Sievert;

 ...

   Sievert = click / 15;

Hier zb. bringt dir der double genau gar nichts. Trotz double wirst du 
niemals Kommastellen sehen.

http://www.mikrocontroller.net/articles/FAQ#Datentypen_in_Operationen

von Fer T. (fer_t)


Lesenswert?

Danke schon mal.
Denke das war die Müdigkeit, hatte erst:
Sievert = click;
Sievert = Sievert / 15;

Dachte aber dann ich könnte das so zusammenfassen...

von DirkB (Gast)


Lesenswert?

Sievert = click / 15.0;
reicht schon.

Du solltest aber auch mal über
click = (click / zeit2) * 240;
nachdenken. Denke daran dass dies eine Integerdivision ist.

von Sebastian Hepp (Gast)


Lesenswert?

Kleine Frage zwischendurch zu
1
click = (click / zeit2) * 240;

Würde es was bringen die Formel so umzustellen?
1
click = click * 240 / zeit2;

Wenn erst Multipliziert und danach Dividierd wird, müsste der 
Rundungsfehler kleiner sein, oder? Ein Beispiel wären die Werte click=1 
und zeit2=1.2

von Loonix (Gast)


Lesenswert?

Sebastian Hepp schrieb:
> Wenn erst Multipliziert und danach Dividierd wird, müsste der
> Rundungsfehler kleiner sein, oder?

Das ist das kleine C-Programmierer-Einmaleins. Gratuliere!

von Karl H. (kbuchegg)


Lesenswert?

Sebastian Hepp schrieb:

> Wenn erst Multipliziert und danach Dividierd wird, müsste der
> Rundungsfehler kleiner sein, oder?

Wie Loonix schon sagte: Das ist das kleine 1*1 der Programmierung. Man 
möchte Divisionen soweit nach rechts verschieben wie es geht. Weil man 
bei einer Division immer etwas verliert.

Aber: Was ist die Kehrseite der Medaille?
Worauf musst du jetzt im Gegenzug aufpassen?

von DirkB (Gast)


Lesenswert?

Sebastian Hepp schrieb:
> Ein Beispiel wären die Werte click=1
> und zeit2=1.2

das sind doch alles integer Variablen. (nix mit 1.2)

> click = (click / zeit2) * 240;

Bsp.: Wenn Zeit2 = 240 sollte immer click rauskommen. Es kommen aber nur 
Vielfache von 240 dabei raus.

von Fer T. (fer_t)


Lesenswert?

Danke an alle!

DirkB schrieb:
>> click = (click / zeit2) * 240;
>
> Bsp.: Wenn Zeit2 = 240 sollte immer click raus kommen. Es kommen aber nur
> Vielfache von 240 dabei raus.

In dem Fal, in dem dies aufgerufen wird, ist aber Zeit2 < 240.
Da das nur aufgerufen wird, wenn noch nicht eine Minute lang gemessen 
wurde, sprich Zeit < 240.
Daher erst klick pro zeit, dann mal 240 um klick pro Minute zu erhalten.

Naja, ich bearbeite gerade noch mal das gesamte Programm, besonders 
versuche ich das Double und sprintf herauszubekommen. (Hätte auch schon 
geklappt, wenn itoa funktionieren würde (und die Verkettung mehrere 
stings...).

Klaus Falser schrieb:
> Ist die Hex Datei 7 KB groß?
> Die Größe der Hex-Datei ist nicht die Größe des Programms.

Ja ist Sie, was ist denn sonst die Größe des Programms? Weil die HEX 
wird ja später auf den uC gebrannt, also muss dieser einen Speicher 
haben, der die Größe der HEX Datei aufnehmen kann. Oder irre ich da?

MfG

von Klaus Falser (Gast)


Lesenswert?

Fer T. schrieb:
> Klaus Falser schrieb:
>> Ist die Hex Datei 7 KB groß?
>> Die Größe der Hex-Datei ist nicht die Größe des Programms.
>
> Ja ist Sie, was ist denn sonst die Größe des Programms? Weil die HEX
> wird ja später auf den uC gebrannt, also muss dieser einen Speicher
> haben, der die Größe der HEX Datei aufnehmen kann. Oder irre ich da?

Nein, eine Hex Datei ist eine ASCII lesbare Datei, da werden 1 Byte 
Programmspeicher in 2 Hex-Digits gespeichert und es kommen noch ein paar 
Felder dazu.
Eine Hex-Datei ist mehr als doppelt so groß.

von Fer T. (fer_t)


Lesenswert?

Oh danke, also doch nicht ganz so groß...

Ich weiß jetzt, warum ich so ein Problem mit itoa habe, nach langem 
forschen bin ich drauf gestoßen, das itoa gar nicht in meiner C Lib 
ist...
Ich nutze nämlich die glibc, und da ist nur atoi drinnen.
Dann muss ich jetzt wohl mal nach einer lib mit itoa suchen...
MfG

von Rolf Magnus (Gast)


Lesenswert?

Du nutzt die glibc auf einem atmega8? Das glaube ich kaum.

von Fer T. (fer_t)


Lesenswert?

Verdammt stimmt, die avr-lib 1.7.1 ...
(hatte des code wo die Formatierung mittels itoa gemacht wird auf dem PC 
ausprobieren wollen und vergessen, das verschiedene Bibliothekaren 
benutzt werden...).

von Fer T. (fer_t)


Lesenswert?

So,
habe mal etwas umgeschrieben, und siehe da, keine Errors und das gute:
vorher war die GEX Datei 7,3 KiB groß, jetzt nur noch 3,5 KiB, das ist 
weniger als die Hälfte!!
Mal hoffen das auch alles klappt wie gehofft...
http://pastebin.com/nRmK6ZH7

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.