Hi, für ein neues Projekt will ich einen STM32F030 nehmen. Habe mir emIDE als Editor mit GCC ausgewählt auch wegen dem JLINK. Außerdem benutze ich Code::Blocks immer für AVR und WIN Programme. Nun habe ich nur das einfache Beispielprojekt (Main mit while 1 schleife) genommen und durch den GCC gejagt. Ich habe auch gesehen das eine Startup Datei dabei ist, aber da wird nicht wirklich viel gemacht. Das ganze kompilieren ging auch ohne Probleme. Aber wieso braucht ein solches kleines Programm schon 2,31KB Code und 1,2KB RAM? Das sind alleine vom RAM schon mehr als 25%. Peter
Du könntest das Ganze in Assembler schreiben
1 | b . |
;) Also der Compiler baut da standartmäßig Sachen ein: Initialisierung Stack, Initialisierung Heap, für C wichtige interne Variablen und Konstanten, RAM Initialisierung und ganz wichtig Initialisierung einiger Peripheriegeschichten. Ram wird warscheinlich hauptsächlich für Stack reserviert sein. Schau dir doch mal das MAP-File an. Da muss doch drin stehn, was wofür und wieviel benutzt wurde.
:
Bearbeitet durch User
Ja ASM wäre super, da könnte ich jedes Bit selber verwalten, aber C ist dann doch hübscher zu pflegen und zu portieren von anderen Projekten. Stack und Heap hatte ich schon aus meiner Aufzählung raus genommen. Die waren Standardmäßig so groß das nichts ging. Im wesentlichen scheinen die LIBs RAM zu brauchen für Funktionen die ICH noch nicht benutzte. Ich kann noch nicht mal sehen wer die LIBs überhaupt anfordert. Ist anscheinend der Fluch einer IDE.
Peter schrieb: > Ist anscheinend der Fluch einer IDE. Die gehorcht auch nur Deinen Befehlen ;-) Wenn es minimalistisch sein soll, hier steht wies geht: http://fun-tech.se/stm32/OlimexBlinky/mini.php Kopier mal die Dateien in ein Verzeichnis und führe make aus. - Hier wird in einer Schleife i++ ausgeführt. - Dann sollte etwas in der Art erscheinen:
1 | text data bss dec hex filename |
2 | 68 0 0 68 44 main.elf |
Von da aus kannst Du dann starten und mit viel Arbeit und studieren der Datenblätter und Manuals optimalen Code erzeugen....
So jetzt hatte ich endlich wieder Zeit. Nachdem studieren der emIDE und Ausgabe Files (ist jetzt nichts zur Hand) ist mir aufgefallen das der ganze Code ins RAM kopiert wird. Der eigentliche Code ist zwar auch nicht klein aber wäre zu verkraften. Ist halt das ganze Vector & Init Zeug. Wie ich nun das Umkopieren verhindere oder was ich ändern muss ist somit die nächste Frage.
Du brauchst die richtigen Startup, Linker und Makefiles. Alles, was eine gescheite IDE schon fertig mitliefert ;-)
Ja da hast Du recht. EmIDE ist da wohl noch nicht wirklich perfekt, obwohl die Firma Segger mit ihren Debuggen dahinter steckt. Ich werde mir heute oder morgen mal EM::Blocks ansehen, vielleicht haben die bessere Startprojekte. Ansonsten muss ich alles wieder selber machen.
@ Peter (Gast)
>Ansonsten muss ich alles wieder selber machen.
Nö, du WILLST es selber machen, warum auch immer. Wer oder was hindert
dich, bestehende (freie) IDEs oder Compiler zu nutzen?
So ich habe eben EM::Blocks kurz getestet. Ich bleibe bei EM::Blocks ist um Klassen besser als emIDE, was die Code Beispiele und das drumherum betrifft. Der Editor an sich ist ja der gleiche. Bei emIDE mag zwar der J-LINK besser integriert sein aber für meine Projekte wird es reichen. Außerdem habe ich jetzt einen direkten Support für den st-link2, somit habe ich gleich noch einen zweiten funktionierenden Debugger. Makefiles und Linker-Scripte selber schreiben vermeide ich wo ich nur kann. Da gebe ich Dir recht, das hat gefälligst eine IDE sauber mit zu bringen. Tja und an eine der aktuell nicht so guten IDE bin ich ran gekommen darum hier meine Frage.
Das bisschen Kleingeld. Für den Hausgebrauch sind die preislich etwas zu teuer. Ansonsten würde ich gerne den von Keil nehmen.
http://www.coocox.org/CooCox_CoIDE.htm + GCC 4.8 [cc] arm-none-eabi-gcc -mcpu=cortex-m0 -mthumb -Wall -ffunction-sections -g -O0 -c -DSTM32F030C6T6 Program Size: text data bss dec hex filename 656 0 0 656 290 test.elf [cc] arm-none-eabi-gcc -mcpu=cortex-m0 -mthumb -Wall -ffunction-sections -g -Os -flto -fno-builtin -c -DSTM32F030C6T6 Program Size: text data bss dec hex filename 514 0 0 514 202 test.elf ist mit der 0815 standard STM lib CMSIS Core ... einfach mal projekt erstellt cmsis boot dazu und fertig wenn man optimieren will kann man da einiges rauswerfen solange ich aber nicht jedes byte brauche .. lasse ich den mist einfach
Hier steht wie man den GCC dazu bringt kleinen Code zu erzeugen: http://www.mikrocontroller.net/articles/ARM_GCC#Code-Gr.C3.B6.C3.9Fe_optimieren Wie man das in der jeweiligen IDE umsetzt darfst du dann selber rausfinden.
coocox ist nicht Code:Blocks basierend, das ist aber meistens mein Wunscheditor. Darum habe ich mich auf die beiden Clone eingelassen. Am Compiler liegt es auch nicht warum meine ersten Versuche daneben gegangen sind sondern an den Linker & sonstigen Files die bei der IDE dabei sind. Mit EM::Blocks ist jetzt alles gut und mein Programm ist übers Wochenende kräftig gewachsen. Wenn man den GCC mit einem Keil oder IAR vergleichen würde, würde man schnell sehen das der GCC nicht gerade platzsparenden Code baut. Gleich zur Erklärung: Ich habe da berufliche Erfahrung gemacht beim 8051 und beim AVR. Beim ARM habe ich bis jetzt keine Erfahrung mit den gekauften Compilern aber ich gehe mal davon aus das es ähnlich sein wird. Aber da ich hier was privates mache ist es mir ziemlich egal ob der mehr Code erzeugt. Ich bekomme den Flash nicht mal halbvoll mit meiner Anwendung. Peter
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.