Unter Windows schreibe ich Programme für AVR-Controller mit dem "Programmer's Notepad 2" und compiliere sie mit der Toolchain "avr8-gnu-toolchain". Nun möchte ich eine Toolchain für STM32F-Controller, insbesondere den 103er. Welche Toolchain kann ich installieren? [Mod: Betreff angepasst]
:
Bearbeitet durch Moderator
Schau mal hier: https://www.mikrocontroller.net/articles/STM32#Programmierung Ich arbeite mit Atollic True Studio: http://www.st.com/content/st_com/en/about/media-center/press-item.html/c2839.html bzw. https://atollic.com/truestudio/
:
Bearbeitet durch Moderator
Beitrag #5414959 wurde von einem Moderator gelöscht.
Beitrag #5414974 wurde vom Autor gelöscht.
Beitrag #5414978 wurde von einem Moderator gelöscht.
Embedded Studio: https://www.segger.com/products/development-tools/embedded-studio/ Passendes Embedded Betriebssystem (ich weiß, wurde nicht nach gefragt, aber bei über 80 BSPs enthaltenen sollte für die gewünschte Hardware was passendes dabei sein. Dann hat man gleich ein funktionierendes Projekt und kann das embOS ja auch gerne raus schmeißen ;-) ) https://www.segger.com/downloads/embos/embOS_CortexM_EmbeddedStudio_Trial
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.
ARMer schrieb: > Welche Toolchain kann ich installieren? Die hier, das ist die offizielle: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
> 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.
Sempfdazugeber schrieb: >> Die hier, das ist die offizielle: > > Wenn schon ARM verlinkt wird, dann ist ARM-DS5 das offizielle Teil > von ARM. Er hat nach ner Toolchain gefragt und nicht nach ner IDE. Und gcc ist nun mal die mit großem Abstand am weitesten verbreitete Toolchain dafür (somit findet man überall Leute die sich damit auskennen und helfen können) und wird auch vom ARM offiziell unterstützt.
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.
W.S. schrieb: > Der Rat zu Keil und IAR hat einen Grund: die sind deutlich besser als > der entsprechende Gcc. > W.S. Benchmarks or gtfo.
W.S. schrieb: > Der Keil-MDK ... ist kein Compiler. Genauso wenig wie es > Den ARM-DS5 als Compiler gibt. W.S. schrieb: > Der Rat zu Keil und IAR hat einen Grund: die sind deutlich besser als > der entsprechende Gcc. "Besser" muss man schon irgendwie definieren. Der C++-Support bei den beiden war beispielsweise bis vor kurzem so desaströs, dass ARMs eigenes mbed-Framework - aus Rücksichtnahme auf Keil und IAR - komplett im völlig rückständigen C++03 geschrieben ist. Weitere "Features" des ARMCC wären der Zwang zu Windows sowie furchtbare Kompilierzeiten. Mit Version 6 des ARM Compilers sieht die Sache zwar schon deutlich besser aus aber es gibt meiner Meinung nach nichts was den gegenüber dem GCC jetzt so viel besser macht.
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.
Angehängte Dateien:
-
tree.png
30 KB
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?
Nase schrieb: > Du meinst so wie im Anhang? Er meint die Analyse zur Compile-Zeit, nicht zur Laufzeit. Außerdem ist das nur der Call-Tree, keine Stack-Analyse.
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. 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"
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/
Nop schrieb: > 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. Was für eine GCC-Version hast du denn im Einsatz? Bei mir gibt es mit -flto genau eine .su-Datei. Wenn deine .elf etwa foo.elf heißt, dann sollte es eine foo.elf.ltrans.ltrans0.su geben. Aus welchen .c-Dateien die jeweilige Funktion stammt, steht dann in der .su. Nutze den GCC 7.2.1 von Launchpad. Nop schrieb: > Siehe auch hier: > https://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/ 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 ist auch nicht so, dass der GCC jetzt voller Bugs wäre oder nur halbgar funktionieren würde. Der Artikel ist von 2010 vielleicht war es damals anders aber das interessiert jetzt auch nicht mehr. Hier im Forum jedenfalls sind 99,5% aller gemeldeten Compiler-Bugs eben keine solchen und das Problem sitzt in der Regel vor dem Bildschirm.
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.
W.S. schrieb: > 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. Schön daß der hier benutzt M3 seine Interrupt-Functionen nach C-Calling-Convention aufruft. Da hat der Compiler überhaupt kein Problem mit.
W.S. schrieb: > 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. Lassen wir doch mal ein paar Zahlen sprechen: https://devzone.nordicsemi.com/b/blog/posts/comparing-compilersides-for-development-with-nrf5x Die Unterschiede bei Code der für Größe optimiert ist (-Os) sind absolut zu vernachlässigen. Bei Code der für Geschwindigkeit optimiert ist liegen die Unterschiede vor allem in der Größe des Binary. Am signifikantesten ist wohl der Unterschied beim statischen RAM-Verbrauch, wobei ich da mal sehr stark die unterschiedlichen Standard-Libraries im Verdacht habe. Da kann natürlich jeder nach belieben die Newlib(-Nano) durch eine andere ersetzen, was ja durchaus auch in manchen GCC-IDEs von Segger über Atollic und Co. gemacht wird und dann natürlich auch die entsprechenden Effekte hat. Carl D. schrieb: > W.S. schrieb: >> 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. > > Schön daß der hier benutzt M3 seine Interrupt-Functionen nach > C-Calling-Convention aufruft. Da hat der Compiler überhaupt kein Problem > mit. So ist es. Wenn man denn unbedingt eine Funktion __svc(x) haben will, kann man sich ganz einfach eine zusammenbauen: https://falstaff.agner.ch/2013/02/18/cortex-m3-supervisor-call-svc-using-gcc/ W.S. schrieb: > 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 Es geht hier nicht um Robin Hood oder um Asterix und Obelix, sondern darum dass der GCC einfach ein sehr ordentlicher Compiler ist, der einem Keil durchaus ebenbürtig ist. 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.
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.
Nop schrieb: > 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. > Der 7er GCC steht momentan bei 7.3 Der wird "vermutlich" schon funktionieren.
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
W.S. schrieb: > 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. Hat das Projekt einen Namen?
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.