Frage zu Programm Optimierung (Größe)

#2125975
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
Gast #2126255
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.
#2126335
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
Gast #2126495
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
#2126501
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?
#2128590
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
Gast #2128597
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ß.
#2128637
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

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren