Hi Leute! Ich staune grad nicht schlecht...ist es normal, dass unter Verwendung der sprintf-Funktion in ihrer vollen Funktionalität mein Speicherbedarf von 864 Bytes auf über 14kB ansteigt? Oder läuft hier was schief bei mir?
Martin schrieb: > Es lief bestimmt was schief. Ist die Antwort jetzt ernst gemeint oder nur ein dummer Kommentar? Mich würde nur interessieren, ob das realistisch ist?
Es lief bestimmt was schief. Zumindest bei der Atmel Toolchain ist das sehr viel kompakter.
Float Formate mit eingebunden? Das Thema gibt es hier im Forum dutzendfach. Es wäre auch hilfreich gewesen, wenn du den Prozessor und den Compiler genannt hättest.
Georg G. schrieb: > Float Formate mit eingebunden? > Das Thema gibt es hier im Forum dutzendfach. > Es wäre auch hilfreich gewesen, wenn du den Prozessor und den Compiler > genannt hättest. Ja, float mit eingebunden. Compiler: Code Composer Studio V6 uC: MSP430G2553
Hans schrieb: > Mich > würde nur interessieren, ob das realistisch ist? Kommt drauf an. Auch wenn sprintf per se erst mal nicht wissen kann, ob du zb float oder double Zahlen ausgeben willst, muss es trotzdem den entsprechenden Code dafür mitbringen. Was dann zb den Rattenschwanz der Floating Point Bibliotheken nach sich zieht, was natürlich ärgerlich ist, wenn du dieses Feature gar nicht brauchst. Daher gibt es auf einem AVR eine abgespeckte Version von sprintf, die zb Floating Point nicht ausgeben kann, dafür aber demenstprechend einen kleineren Memory Foorprint hat. Es ist also nicht sprintf selbst, welches so dermassen aufträgt, sondern die ganzen 'Supportfunktionen', die sprintf benötigt um in der allgemeinsten Form alle Formatieraufgaben erledigen zu können, die sich da summieren.
Hans schrieb: > Ja, float mit eingebunden. > Compiler: Code Composer Studio V6 > uC: MSP430G2553 In dem Fall realistisch. Karl Heinz schrieb: > Daher gibt es auf einem AVR eine abgespeckte Version von sprintf, die zb > Floating Point nicht ausgeben kann, dafür aber demenstprechend einen > kleineren Memory Foorprint hat. Ich habe schon auf AVR Controllern mit sprintf einen float verarbeitet. Dabei ist der Speicherbedarf nicht (oder nur so minimal, dass ich es nicht gemerkt hab) gestiegen.
Marcel schrieb: > Ich habe schon auf AVR Controllern mit sprintf einen float verarbeitet. > Dabei ist der Speicherbedarf nicht (oder nur so minimal, dass ich es > nicht gemerkt hab) gestiegen. im vergleich zu was?
Karl Heinz schrieb: > Daher gibt es auf einem AVR eine abgespeckte Version von sprintf, die zb > Floating Point nicht ausgeben kann Ja die gibt es hier auch. Aber OK, war nurmal ein kleiner Schock :-) Danke!
Hallo Hans, nach meiner Erfahrung ist die Verwendung von printf, sprintf usw. mit dem MSP430G2553 in Verbindung mit dem CCS-Compiler nicht möglich (ich verwende die Version 5.2). "C I/O Mysteriously Fails If there is not enough space on the heap for a C I/O buffer, operations on the file will silently fail. If a call to printf() mysteriously fails, this may be the reason. The heap needs to be at least large enough to allocate a block of size BUFSIZ (defined in stdio.h) for every file on which I/O is performed, including stdout, stdin, and stderr, plus allocations performed by the....." Quelle: spru187u.pdf - Compiler UserGuide Kapitel 7.2 #define BUFSIZ 256 steht in der stdio.h von der runtime-support-library Damit ist gesagt, dass mindestens 3 Buffer à 256 byte aufgemacht werden, sobald man eine dieser Funktionen benutzt und damit platzen die 512 byte RAM die der 2553 hat. Gruß wv
sprintf ist eine eierlegende Wollmilchsau. Hat wahrscheinlich, versteckt, sogar Optionen für's Waschen und Bügeln. So was braucht Platz.
Ich benutze in allen meinen Projekten (AVR/STM32) immer diese schlanke Version von printf: http://www.menie.org/georges/embedded/printf-stdarg.c
>Ebenfalls bewährt: >http://www.sparetimelabs.com/tinyprintf/tinyprintf.php Beim: >uC: MSP430G2553 ...wohl nicht so sehr.
Amateur schrieb: >>Ebenfalls bewährt: >>http://www.sparetimelabs.com/tinyprintf/tinyprintf.php > > Beim: >>uC: MSP430G2553 > ...wohl nicht so sehr. Der verlinkte Code ist portabel und läuft mindestens auf 8-Bit AVR, x86 und x86-64 mit GCC und Clang, ich sehe also spontan keinen Grund, wieso der Code auf einem MSP430 nicht laufen sollte.
Marian B. schrieb: > ich sehe also spontan keinen Grund, wieso > der Code auf einem MSP430 nicht laufen sollte. Stelle die Frage doch einfach mal anders herum: Wieso sollte man printf bei einem µC überhaupt einbauen, wenn man nicht Ressourcen bis zum Abwinken hat? Ein paar schlichte Char_Out, String_Out, Dezi_Out und Hex_Out sollten doch für den gewöhnlichen Bedarf komplett ausreichen. gelle? W.S.
W.S. schrieb: > Stelle die Frage doch einfach mal anders herum: Wieso sollte man printf > bei einem µC überhaupt einbauen, wenn man nicht Ressourcen bis zum > Abwinken hat? Naja, 1-2 KB Flash- und 0.5-1 KB Stackverbrauch empfinde ich nicht als "Ressourcen bis zum Abwinken". Kleinere Systeme haben oft keine ausreichende Ausgabemöglichkeit. Für's Debugging ist ein funktionierendes printf() deutlich angenehmer, als alles mit puts/puthex/putdec/... zusammenstückeln zu müssen. Liest sich außerdem besser.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.