|
Anzeige
|
sprintf-Funktion - Speicherbedarf
Gast
#3665468
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?
Gast
#3665471
Es lief bestimmt was schief.
Gast
#3665474
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?
Gast
#3665485
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.
Gast
#3665491
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.
Gast
#3665498
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.
Gast
#3665502
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?
Gast
#3665503
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!
Gast
#3665548
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
Gast
#3665552
sprintf ist eine eierlegende Wollmilchsau. Hat wahrscheinlich, versteckt, sogar Optionen für's Waschen und Bügeln. So was braucht Platz.
Gast
#3665557
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
Gast
#3665600
>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.
Gast
#3665943
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. Der Thread geht allerdings um printf. 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. Antwort schreiben |
Anzeige
|
