Hallo Zusammen! Ich habe für Debugzwecke meinem Programm eine kleine Routine hinzugefügt, die Speicherinhalt als Hexdump über die serielle Schnittstelle ausgibt und benutze dazu sprintf mit %x. Dabei habe ich festgestellt, dass durch bloßen Ein- und Auskommentieren sich die Größe des Programms um 19kB ändert. In diesem Fall ist es ja nicht weiter schlimm, da es eh nur für einen kurzen Test benutzt wird. Trotzdem würde mich für die Zukunft interessieren, ob das normal ist, oder ich da grundsätzlich was falsch gemacht habe? Die Suche lieferte mir bisher nur die Information, dass sprintf aufgrund des Funktionsumfanges recht groß ist, aber wenn ich daran denke, dass ich sprintf auch auf deutlich kleineren Controllern, wenn auch mit anderen Compiler und RTLs, benutzt habe kommt mir das doch sehr seltsam vor! Ich benutze einen AT91SAM7S mit WinARM. Viele Grüße, Tobias Wegner
Try this implementation: http://www.menie.org/georges/embedded/index.html#printf I used this successfully on a LPC2148 and it takes only slightly more than 1k of code.
Ja, würde ich auch vorschlagen, einfach selbst die bytes über die schnittstelle kloppen
Das ist völlig normal, daß ein 32-Bitter wesentlich mehr Code braucht, als ein 8-Bitter. Zusätzlich hat er eine RISC-Architektur, die keine direkten Befehle auf SRAM oder IO-Register erlaubt und auch keine Bitbefehle. Z.B. ein simples Löschen eines Interruptbits kostet aufm 8051 2 Bytes und aufm ARM 20 Bytes. Bzw. da die meisten Interruptbits des 8051 automatisch bei Eintritt gelöscht werden, sinds aufm 8051 oftmals nur 0 Byte. Peter
@Peter Dannegger > Z.B. ein simples Löschen eines Interruptbits kostet aufm 8051 2 Bytes > und aufm ARM 20 Bytes. 20????? Wirklich? Hat der ARM 32 Bit Befehle, ähnlich wie der AVR (16 Bit), oder haben die Befehle unterschiedliche Längen? Oder willst du uns auf den ARM nehmen ;-) (5 Euro in die Schlechte-Wortspiel-Kasse) MFG Falk
Dass Peter hier wieder sein 8051er-Loblied singt war zu erwarten. Aber mit Extrembeispielen zu argumentieren macht keinen Sinn - oder wollen wir mal den Code für ein 32x32 Multiply & Accumulate vergleichen? Der eigentliche Grund für diesen Unterschied ist die Float-Unterstützung in printf. Deine 19 kB bestehen also nicht nur aus printf, sondern enthalten dazu noch die komplette Floating Point Bibliothek. Wenn Float-Unterstützung nicht gebraucht wird sollte man iprintf nehmen. Und wenn es keinen triftigen Grund gibt der dagegen spricht sollte man immer für Thumb-Befehlssatz kompilieren, damit erreicht man eine deutlich höhere Codedichte. Auf Prozessoren mit schmaler Flash-Anbindung und ohne Cache (AT91SAM7) ist er sogar oft schneller.
Mit printf werden grosse Teile der newlib reingezogen, darunter beispielsweise auch Speicherverwaltung. Die newlib ist nicht derart auf Platz programmiert wie das Äquivalent aus WinAVR.
Erstmal vielen Dank an Alle für die Antworten! Mein Gewissen und Weltbild sind damit gerettet. Ich werde in Zukunft also printf zu vermeiden oder zumindest die Integerversion verwenden. Mit Thumb und Arm Mode bin ich noch nicht so ganz vertraut, bisher bin ich froh, wenn es kompiliert. (Ja, ich bin Microsoft Visual Studio verwöhnt, da braucht man keine Makefiles ;)) Aber mit ist auch klar, dass ich mich da mal einarbeiten muss.
Andreas Schwarz wrote: > Dass Peter hier wieder sein 8051er-Loblied singt war zu erwarten. Aber > mit Extrembeispielen zu argumentieren macht keinen Sinn - oder wollen > wir mal den Code für ein 32x32 Multiply & Accumulate vergleichen? Bitschubserei ist kein Extrembeispiel, sondern oftmals Brot und Butter einer typischen MC-Anwendung. Man wird in praktischen Anwendungen mit nem 32Bit-RISC nie die Codeeffizienz eines 8-Bitters erreichen. Bei Flashgrößen von typisch 265kB ist das heutzutage aber nicht mehr so wichtig. Man sollte es eben nur wissen. Daher wird eben printf zusammen mit float gelinkt, was ja beim 8051 auch schon mit 2kB zu Buche schlägt (1kB ohne float). Auch fügt ein 8Bit-Compiler nie eine 32Bit-Multiplikation direkt ein, sondern lädt die Register mit den Operanden und ruft sie auf. Sie steht also nur einmal im Code und hat damit keinen signifikanten Einfluß auf die Gesamtgröße. Man muß die Kirche im Dorf lassen, d.h. der 32Bitter hat nur dort Vorteile, wo wirklich schnell 32Bittig gerechnet werden muß oder wo großer Speicher schnell adressiert werden muß. Oftmals werden 32Bitter leider nur dazu eingesetzt, um den Benutzer mit langweiligen Animationen auf nem Grafikdisplay zu nerven, wären der eigentliche sinnvolle Funktionscode schon von nem 4Bitter zu wuppen ist. Peter
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.