GCC für STM32F103

Atollic truestudio oder STM32 Workbench.

ARMer schrieb:
> Nun möchte ich eine Toolchain für STM32F-Controller, insbesondere den
> 103er. Welche Toolchain kann ich installieren?

In der Reihenfolge der Relevanz:

1. den Keil (32K Code frei)
ST hat da mit Keil und Segger ein paar Extrawürste gebraten, nützt dir 
vielleicht was.
Derzeit die MDK-ARM Version 5.25
https://www.keil.com/demo/eval/arm.htm

2. IAR (ebenso 32K Code frei)
Derzeit die Version 8.22
https://www.iar.com/iar-embedded-workbench/#!?currentTab=free-trials


3. GCC - was da an aktuellen Versionen vorhanden ist, mußt du selber 
herausfinden. Ich hatte vor Jahren die "yagarto" benutzt, aber die ist 
wohl mittlerweile ausgestorben.

Ähem.. nochwas: Toolchain und IDE sind zwei verschiedene Dinge. Aber bei 
Keil und IAR ist jeweils eine IDE mit dabei.

W.S.

W.S. schrieb:
> 1. den Keil (32K Code frei)
> ST hat da mit Keil und Segger ein paar Extrawürste gebraten, nützt dir
> vielleicht was.
> Derzeit die MDK-ARM Version 5.25

Und jamnert gerne, dass neuere Chips noch nicht unterstützt werden, weil 
sie nur ein kleines Entwickler-Team haben.

Privat verwende ich Truestudio, da Atollic inzwischen zu STM gehört.

> Die hier, das ist die offizielle:

Wenn schon ARM verlinkt wird, dann ist ARM-DS5 das offizielle Teil
von ARM.

Und da werkelt kein GCC.

Sempfdazugeber schrieb:
>> Die hier, das ist die offizielle:
>
> Wenn schon ARM verlinkt wird, dann ist ARM-DS5 das offizielle Teil
> von ARM.
>
> Und da werkelt kein GCC.

Der GCC ist schon auch offiziell:
"The GNU Embedded Toolchain for Arm is a ready-to-use, open source suite 
of tools for C, C++ and Assembly programming targeting Arm Cortex-M and 
Cortex-R family of processors. It includes the GNU Compiler (GCC) and is 
available free of charge directly from Arm for embedded software 
development on Windows, Linux and Mac OS X operating systems."

Zum Thema:
http://www.st.com/en/development-tools/stm32-ides.html?querycriteria=productId=LN1200

Hat ST nicht erst Atollic und damit das True Studio gekauft? Das ist 
jetzt glaube auch kostenlos und gut.

Bernd K. schrieb:
> Und gcc ist
> nun mal die mit großem Abstand am weitesten verbreitete Toolchain

Sag's mal lieber präzise: GCC als solcher - für Linux und Konsorten, 
sowie für viele andere Architekturen - ist weiter verbreitet als 
spezielle Compiler für ihre jeweiligen Architekturen. So herum.

Der Rat zu Keil und IAR hat einen Grund: die sind deutlich besser als 
der entsprechende Gcc.

STK500-Besitzer schrieb:
> Und jamnert gerne, dass neuere Chips noch nicht unterstützt werden, weil
> sie nur ein kleines Entwickler-Team haben.

Wer jammert denn da? Niemand. Der Keil-MDK funktioniert für alle 
ARM-Geschmacksrichtungen, für die er konzipiert ist. Den ARM-DS5 braucht 
man für einen Cortex M3 nicht. Aber wer will, kann sich ja davon die 
Community-Edition herunterladen...

W.S.

Ein Beispiel, wo Keil besser ist: Stack-Analyse. Das wirft einem Keil 
für jede Funktion inkl. Calltree aus, während GCC das nur pro Funktion 
ohne deren Calls kann - und nicht einmal das funktioniert zusammen mit 
FLTO.

Für Hobbygebastel ist das egal, aber nicht für professionelles Arbeiten. 
Eine ausgelassene Stackanalyse entspricht Verletzung der Sorgfaltpflicht 
und dürfte von daher fahrlässig bis grob fahrlässig sein. Das wird im 
Ernstfall teuer für so eine Pfuschbude, besonders wenn es zu 
Folgeschäden kommt.

Nop schrieb:
> Ein Beispiel, wo Keil besser ist: Stack-Analyse. Das wirft einem Keil
> für jede Funktion inkl. Calltree aus, während GCC das nur pro Funktion
> ohne deren Calls kann - und nicht einmal das funktioniert zusammen mit
> FLTO.

Du meinst so wie im Anhang?

Christopher J. schrieb:

> Ok, eine gute Stack-Analyse lasse ich mal als Vorteil gelten. Beim GCC
> geht das aber auch mit -flto, dann allerdings nur in Kombination mit
> -save-temps. Siehe dazu auch Johanns Antwort hier:
> Beitrag "Re: GCC -fstack-usage"

Gerade mal probiert: nein, geht nicht. Die .su-Files sind dann immer 
noch leer. Ist natürlich möglich, daß er das stattdessen irgendwo anders 
in irgendwelche temporären Dateien hinwirft, aber sorry, das ist als 
Feature zum realen Arbeiten unbrauchbar.

Wenn man den Frickelfaktor einrechnet und den mit üblichen Stundensätzen 
bepreist (also Brutto + AG-Anteil + Anteilig Miete, Verwaltung HR usw.), 
dann ist GCC schlicht zu teuer. GCC ist hingegen durchaus gut, wenn man 
kein Geld ausgeben kann oder will, aber Zeit hat.

Siehe auch hier: 
https://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/

Christopher J. schrieb:
> "Besser" muss man schon irgendwie definieren. D

Na denn: schnellerer und kompakterer Code. Wenn ich mich recht erinnere 
(ist ja schon ne Weile her) war der Code beim GCC selbst in der höchsten 
Optimierungsstufe noch immer rund 30% größer als beim Keil in Default.

Die Assembler-Notation ist ebenso grauselig und den Stress mit .thumb 
und .thumbfunc möchte man nicht noch mal erleben müssen, ist aber seit 
Cortex und Thumb2 wohl nicht mehr gar so signifikant. Ein Ähnliches gilt 
für Interrupt-Handler im zugehörigen Treiber. Das war ne klassische 
Krätze beim GCC.

Obendrein kann der GCC keine SVC's - aber da er sowas nicht kann, kennen 
sowas seine Benutzer auch nicht.

So, das waren mal ein paar Beispiele, es gibt aber noch mehr. Man muß 
kommerzielle Software nicht mögen, schließlich ist es für 
OpenSource-Fans weitaus wichtiger, daß man damit eine Art Robin Hood 
Gefühl oder Asterix&Obelix-Gefühl hat (Rebellion gegen das Kommerzielle) 
- auch wenn gerade beim GCC als Universal-Compiler die 
plattformspezifischen Dinge eher schlecht oder eben garnicht umgesetzt 
werden als bei einem plattformspezifischen Compiler wie eben dem Keil.

W.S.

Christopher J. schrieb:

> Was für eine GCC-Version hast du denn im Einsatz?

6.3. Den 7er GCC werde ich nicht verwenden, solange nicht das erste 
Update durch ist, und da es nur noch halbjährliche Releases gibt, dauert 
das noch bis Jahresmitte.

> Bei mir gibt es mit -flto genau eine .su-Datei.

Jedenfalls ist da nichts im Objektverzeichnis, wo die .su-Dateien landen 
sollten. Also, es sind .su-Dateien da, aber leer, sofern ich mit -flto 
compiliere.

Gut, -flto wäre aber ohnehin unbrauchbar, weil die Stackanalyse des GCC 
auch viel schlechter als bei Keil ist. Beim GCC muß man sich den 
Calltree selber zusammenfummeln, aber LTO kann einem den Calltree völlig 
umkrempeln. Insofern schützt ein fast unbrauchbares Feature des GCC 
automatisch vor der Anwendung eines anderen fast unbrauchbaren Features. 
;-)

> Das mit dem Support ist natürlich so eine Sache. Direkten Support von
> den GCC-Autoren wird man wohl nicht bekommen aber das hat doch nichts
> mit der Qualität des Compilers an sich zu tun.

Es hat aber was damit zu tun, wie schnell man Support bekommt, denn 
professionell ist Zeit gleichbedeutend mit Geld. Insbesondere, wenn man 
es nicht für akzeptabel hält, Firmencode ins Forum oder auf 
Stackoverflow zu posten.

Christopher J. schrieb:
> Ich kann einfach die Kommentare vom Typ
> "verzichte lieber auf drei viertel des Flash und nimm einen
> 32kB-limitierten Keil, der ist sooo viel besser" einfach nicht
> verstehen.

Ich auch nicht. Für professionelle Anwendung hat man eh eine richtige 
Lizenz, so daß keine Limitierung drin ist.

Aber für Hobby schaffe ich mir doch keinen Lock-In, bei dem ich früher 
oder später entweder eine Menge Geld ausgeben oder auf eine andere 
Toolchain umstellen muß. Die Gratis-Version würde ich nur zu dem Zweck 
installieren, zu dem sie auch gedacht ist - zur Evaluierung, ob ich die 
Lizenz kaufen will oder nicht. Wenn ich von vornherein angesichts des 
Preisniveaus schon entschieden habe, daß ich keine Lizenz kaufen will, 
brauche ich auch nichts zu evaluieren.

Carl D. schrieb:

> Der 7er GCC steht momentan bei 7.3

Die Baremetal-Version ist aber im Dezember 2017 als das erste Release 
aufgetaucht, und ich rechne eben damit, daß none-eabi Bugs hat, die 
Mainline nicht hat. Deswegen verwende ich keine none-eabi vor deren 
ersten Update und bleibe lieber bei der 6er. Beim Update von 5 auf 6 
habe ich das natürlich auch schon so gemacht.

Christopher J. schrieb:
> Die Unterschiede bei Code der für Größe optimiert ist (-Os) sind absolut
> zu vernachlässigen.

Wo hast du den DAS her? Einfach so trocken glaub ich dir kein Wort 
davon.

Meine Erfahrungen mit dem Gcc für ARM7TDMI sind zwar schon etwas älter, 
aber sie waren signifikant. Allerdings hab ich in den letzten Jahren den 
Gcc nicht wieder angefaßt, weil ich beruflich mit dem Keil arbeite.

Ach ja, ich hatte hier ja vor einiger Zeit mal ein kleines Projekt mit 
dem STM32F103C8T6 gepostet. Da ist die fertige Firmware auch im .bin 
Format drin (11508 Bytes). Wäre ja mal interessant, wenn jemand, der den 
Gcc benutzt, das Zeugs damit übersetzt. Einfach um mal zu sehen, wie 
groß die Binärdatei beim Gcc wird.

W.S.

W.S. schrieb:
> Christopher J. schrieb:
>> Die Unterschiede bei Code der für Größe optimiert ist (-Os) sind absolut
>> zu vernachlässigen.
>
> Wo hast du den DAS her? Einfach so trocken glaub ich dir kein Wort
> davon.

Die Quelle hat er doch gepostet.

Christopher J. schrieb:
> Lassen wir doch mal ein paar Zahlen sprechen:
> 
https://devzone.nordicsemi.com/b/blog/posts/comparing-compilersides-for-development-with-nrf5x