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
> double Sievert;
..bringt Dir grob 4kiB Codegrößenzuwachs.
HTH
Float braucht etwa 1kB. Beim AVR-GCC: double = float Sprintf ist recht teuer und mit float nochmal deutlich teurer. Peter
danke, gib es eine Alternative zu sprintf? Float muss ja leider sein, eine kleinere kommazahl Art gibt es ja leider nicht, oder? MfG
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
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.
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.
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
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...
Sievert = click / 15.0; reicht schon. Du solltest aber auch mal über click = (click / zeit2) * 240; nachdenken. Denke daran dass dies eine Integerdivision ist.
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
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!
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?
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.
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
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ß.
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
Du nutzt die glibc auf einem atmega8? Das glaube ich kaum.
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...).
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.