Guten Morgen zusammen -
Ausgangslage:
Ich habe ein größeres Projekt für AVR-Controller gebaut. Dieses kann per
Defines in verschiedenen Headern konfiguriert werden, und ist
hardwareabstrakt, d.h. funktioniert auf verschiedenen AVR-Controllern,
fürs Compilieren muss lediglich ein config file geändert, und im
AVR-Studio der entsprechende Zielcontroller eingestellt werden.
Frage:
Wie erreiche ich ähnliches für STM32?
Ich habe jetzt mit Eclipse CDT und STM32Cube mal zum testen Projekte
aufgesetzt, diese fußen aber ja fest auf dem entsprechenden Controller,
ein ändern im Nachgang scheint nicht ohne weiteres möglich, bzw. ist
eine menge aufwand..
Ich möchte eigentlich nicht für jede konfiguration ein eigenes Projekt
anlegen, das werden dann dutzende, wo bisher ein angepasstes header-file
genügte..
Jemand ne idee?
Danke..
Muss es denn Eclipse CDT oder STM32CubeIDE sein? Ich habe das gerade mal
mit Embedded Studio ausprobiert und das scheint problemlos zu
funktionieren weil ich dort alle Einstellungen beliebig pro
Konfiguration angeben kann.
https://www.segger.com/products/development-tools/embedded-studio/
Sieht dann in der Projektdatei quasi so aus:
> Wie erreiche ich ähnliches für STM32?
Professionelle Entwicklung findet immer mit Makefiles statt damit du
jederzeit wieder dein Projekt auschecken kannst und es binaer identisch
neu generieren kannst. Ohne das du dich fragen musst welche
Ecpliseversion hab ich diese Woche, welche droelfzig Unterversionen
wurden wie aus dem Netz gezogen und was ist naechste Woche anders.
Wenn das so ist dann kannst du selbstverstaendlich alles wie schon immer
als Parameter ans Makefile uebergeben und dabei alles Zaubern was du
willst.
Natuerlich kannst du trotzdem gerne Eclipse nutzen wenn du willst, du
sagt dem einfach das es bitte dein Makefile aufrufen soll.
Olaf
das geht, als Standard macht sich da gerade cmake breit. Das bietet gute
Möglichkeiten verschiedene Quellen für verschiedene Projekte zu
selektieren.
Das wird auch in einigen OS genutzt um aus dem selben Quelltext den Code
für verschiedene Targets zu erzeugen.
Johannes S. schrieb:> das geht, als Standard macht sich da gerade cmake breit
Wow, danke für den hinweis. Sieht aus als hätte ich das schon früher für
das projekt nutzen sollen, auch wenn es scheinbar wirklich mächtig ist..
wird wohl auch ne gute lernkurve haben
Walter T. schrieb:> Normalerweise müsste doch jede Build-Umgebung mehrere Targets erlauben.
gibt es, aber die mcu scheint da nicht austauschbar zu sein, nur
projektglobal.
Til S. schrieb:> Muss es denn Eclipse CDT oder STM32CubeIDE sein?
nein, das ist nicht gesetzt. Das embedded studio hatte ich mir demnächst
auch noch anschauen wollen..
dunno.. schrieb:> gibt es, aber die mcu scheint da nicht austauschbar zu sein, nur> projektglobal.
ja, cmake ist erstmal nicht einfach zu verstehen, und aufwändiges wie
HAL für verschiedene Serien unter einen Hut zu bringen ist nicht
einfach. So abstrakt ist der HAL allerdings nicht das da alles
gleichgemacht wird, was bei den vielen verschiedenen Features aber auch
kaum möglich ist.
Ich benutze schon lange Mbed, das hat einen höheren Abstraktionslevel
und ein C++ API. Als MCU bin ich damit nicht mal auf STM32 festgelegt,
auch die Cortex-M anderer Hersteller werden unterstützt.
Das API unterstützt nur die Standardschnittellen der MCU, für STM32 baut
es aber auch auf den HAL und so kann man CubeMX Code auch direkt
verwenden.
dunno.. schrieb:> Walter T. schrieb:>> Normalerweise müsste doch jede Build-Umgebung mehrere Targets erlauben.>> gibt es, aber die mcu scheint da nicht austauschbar zu sein, nur> projektglobal.
Das wundert mich. Bei allen Build-Umgebungen, die ich kenne (STM32Cube
gehört nicht dazu), kann man sogar für jedes Target einen anderen
Compiler und unterschiedliche Quelltextdateien auswählen.
Johannes S. schrieb:> das geht, als Standard macht sich da gerade cmake breit.
CMake nutze ich auch für alle embedded Projekte. Teilweise wird damit
dann auch noch ein PC Compiler angesteuert um Tests oder UI Simulationen
zu genererien.
Zusammen mit CLion als Entwicklungsumgebung ist das eine tolle Sache.
Allerding kostet CLion was weshalb auch sehr viele Leute den Visual
Studio Code Editor zusammen mit CMake benutzen.
Walter T. schrieb:> Bei allen Build-Umgebungen, die ich kenne (STM32Cube gehört nicht dazu),> kann man sogar für jedes Target einen anderen Compiler und> unterschiedliche Quelltextdateien auswählen.
Was nützt du denn da?
Mir geht's insbesondere um die Startup Codes, linkerskrips, memory
Bereiche, diese ganze Magie die da im Hintergrund erzeugt wird, damit
das hello world example überhaupt läuft.
Bei Eclipse CDT habe ich zum Wechsel der MCU ne Anleitung gefunden, das
sind zig Schritte, und dann auch nicht mehrere speicherbar..
total indiskutabel für Mal eben schnell ne andere config bauen..
Blume schrieb:> CMake nutze ich auch für alle embedded Projekte.
Hurra, dann sind wir ja schon zwei :)
Obwohl, ich bin noch bei VSCode, da trennen sich unsere Wege schon
wieder :)
Mbed hat ein Buildsystem, das ist komplett in Python gebaut. Das hat
diverse Nachteile:
- Laufzeit und Resourcen: Das läuft auch im Hintergrund für den Online
Compiler, wird also zeitweise von vielen genutzt. Praktischer ist
mittlerweile das Offline zu nutzen (was auch schon seit 10 Jahren geht),
und auch da ist die Laufzeit durch das gewachsene System ein Argument
geworden.
- Wartung: viele Sonderlocken im Python System machen es schwer
durchschaubar
- Konfigurierbarkeit: beim gewachsenen System wurde immer alles
kompiliert, Abhängigkeiten machten es schwer nur benötigte Module
einzubauen
Jetzt geht es zum Glück in Richtung cmake das alles dies im Fokus hat
und besser macht. Nur für die Konfiguration muss man dazu lernen. Vorher
hat das Buildsystem alles kompiliert was ihm vor Füsse kam, jetzt muss
man explizit alles angeben was wie kompiliert werden soll.
VSCode ist recht genial geworden bei git Unterstützung (ausser bei
verschachtelten git Repos), viel besser als sogar beim großen Bruder
VSStudio. Die CMake-Tools Extension hat aber viel Eigenleben, damit bin
ich noch nicht warm geworden. Ich weiss nicht ob die für Embedded bzw
Crosscompiling viel bringt oder wie man die dafür richtig konfiguriert,
Mbed erzeugt eine Startconfig oder konfiguriert bei Änderungen. Benutzt
hier jemand die VSCode CMake-Tools Extension?
Bei VSCode ist die Vielfalt der Erweiterungen Imposant und das Tempo mit
dem es weiterentwickelt wird.
Ein Mbed Programm übersetze ich mit 'mbed-tools compile -m
NUCLEO_STM32F103RB -t GCC_ARM', für ein anderes target wird bei -m
einfach ein anderes angegeben, ohne zu Würfeln oder andere Cores zu
installieren.
Johannes S. schrieb:> VSCode CMake-Tools Extension
ich glaube das nutzen tatsächlich viele. ein ehemaliger Auftaggeber von
mit hat auch zunächst mit CLion geliebäugelt und ist dann doch auf
VSCode geschwenkt. Dort wir mit CMAKE der IAR Compiler angesteuert.
Ich benutze CMake zwar ebenfalls, aber wie dieser Mist quasi
Industriestandard werden konnte ist mir unverständlich. Das größte
Problem ist dass es wie bei C++ ein veraltetes und ein modernes CMake
gibt, man es aber im Gegensatz zu C++ nicht geschaft hat das
entsprechend zu kommunizieren. Die Menge an Scheißdreck Code in der
freien Wildbahn is atemberaubend und es herrscht absolute Anarchie. Man
kann davon ausgehn dass etwa 1 von 10 angeblichn CMake Projekte das tut
was es soll... beim Rest darf man selbst Hand anlegen. Und nein, das
betrifft nicht nur Pimperlptojekte... ich sag nur GTest.
Dunno.. schrieb:> Walter T. schrieb:>> Bei allen Build-Umgebungen, die ich kenne (STM32Cube gehört nicht dazu),>> kann man sogar für jedes Target einen anderen Compiler und>> unterschiedliche Quelltextdateien auswählen.>> Was nützt du denn da?
Eine andere MCU/andere Plattform ist:
* evtl. anderer Compiler
* andere Build-Parameter und DEFINES
* ein paar anderen Quelltext-Dateien
Mehr steckt doch nicht dahinter. Wo liegt das Problem?
> Ich benutze CMake zwar ebenfalls, aber wie dieser Mist quasi> Industriestandard werden konnte ist mir unverständlich.
Alles nach dem klassischen make ist ein grosser Mist. Nicht weil make so
toll ist. Oh nein!
Aber heutzutage muss ja jeder Aushilfsprogrammierer gleich sein eigenes
neues System rausbringen. Natuerlich jedes Jahr zwei neue Versionen.
Selbstverstanedlich mit drei versteckten neuen Sprachen oder
Scriptsprachen unter der Haube. Alles MAXIMAL inkompatibel und
undurchschaubar. Bei jeder neuen Version einer Software das Risiko das
nichts mehr geht weil das gerade gehypte Buildsystem zu alt ist oder
eine falsche Ableitung. Aktualisiert man, so bekommt man gleich drei
alte Sachen auf der Platte nicht mehr uebersetzt.
Also dann doch lieber einmal das dicke Handbuch zu make gelesen und
fertig. Es ist ja nicht so das man da jede Woche dran muss....
Olaf
Dunno.. schrieb:> Mir geht's insbesondere um die Startup Codes, linkerskrips, memory> Bereiche, diese ganze Magie die da im Hintergrund erzeugt wird, damit> das hello world example überhaupt läuft.>> Bei Eclipse CDT habe ich zum Wechsel der MCU ne Anleitung gefunden, das> sind zig Schritte, und dann auch nicht mehrere speicherbar..
Wenn man mit Eclipse-Hausmitteln und dem fertigen Startup-Code
Linkerscripts etc. auskommen will kann man das ganze "Fleisch" in eine
Library auszulagern und für jede MCU ein eigenes "Programm"-Projekt
anlegen. Von dieser Library braucht man bei STM32 dann nur für jede
CPU-Architektur eine eigene build-config und nicht pro µC.
Da das alles aber schnell zu einer Menge an Permutationen führt und man
mal "auf die Schnelle" nicht in allen Projekten z.B. einen
Compiler-Parameter dazudefinieren kann ist das auf Dauer ein Krampf.
Dazu kommen so hilfreiche Features wie Prüfsummen über die eingestellte
Konfiguration die in die XML Dateien wandern und sich "von selbst"
ändern, wenn man das versioniert hat man dauernd unnötige "leere"
Änderungen wo nur die Prüfsumme anders ist in der Historie.
Man kann sich auch bei Projekten wie mbed oder micropython Anregungen
holen wie die mit dem Problem umgehen. Im Endeffekt schreibt dann jeder
wieder sein eigenes (meta-) Build-System.
Blume schrieb:> Dort wir mit CMAKE der IAR Compiler angesteuert.
Moin,
bei der genannten Kombination ist zu beachten, dass das Update auf CMake
3.21 für den Support des IAR Compilers, bzw. Linkers nicht gerade
förderlich war:
https://gitlab.kitware.com/cmake/cmake/-/issues/22425
In CMake 3.22 sollte der Fehler behoben sein.
Gruß,
Michael
Bei CMAKE ist bekannt, dass der IAR Linker kaum Funktionalität hat und
wollen daher direkt den besseren Linker nutzen.
Ich komme vom GCC/Binutils Linker und musste als Externer ein
Linkerscript für den IAR schreiben.
Das war der Grusel pur!
Es wurde jede menge Funktionalität vermisst und dann sortiert der Linker
noch das bss Segment vor dem data Segment was das binary sinnlos
aufgeblasen hat.
Eine wirkliche Sortiermöglichkeit existiert nicht.
Die "Doku" und der "Support" waren auch nicht hilfreich und die "Doku"
ist sehr knapp gehalten.
Die ganze IAR Doku ist kürzer als alleine die ld Doku.
Beispiele gibt es auch kaum.
Leute, nehmt den GCC und nicht den IAR!
Hallo,
beim STM HAL kannst du auch zwischen den Derivaten unterscheiden.
Es gibt im Code von STM zB sowas
1
#if defined(STM32F410Tx) || defined(STM32F410Cx)
2
...
So kannst du in deinen libs CPU abhängigen Code pflegen ...
Typischerweise werden die CPU defines im Makefile oder Projektfile durch
die CubeMx generiert.
Die CMSIS definiert auch ein paar Mechanismen für die unterschiedlichen
Devices:
https://arm-software.github.io/CMSIS_5/Core/html/templates_pg.html
in meiner system_stm32f4xx.c (die vom CubeMX ins Projekt kopiert wurde),
wird
Robert M. schrieb:> Da das alles aber schnell zu einer Menge an Permutationen führt und man> mal "auf die Schnelle" nicht in allen Projekten z.B. einen> Compiler-Parameter dazudefinieren kann ist das auf Dauer ein Krampf.
Das war auch mein Gefühl, wie es aussehen wird.
Aktuell ist die Wahl jetzt erstmal auf visualgdb gefallen, da kann
nämlich das Ziel jederzeit geändert werden, und die Eingewöhnung ist
minimal, da VS hier sowieso brot-und-butter ide ist...
Sollte das dann auf lange Sicht zu krampfig werden, muss halt wirklich
cmake Ran.
