STM32F030 & Code grösse

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.

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.

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.

Was spricht gegen Keil oder IAR?

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