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:
1 | <!DOCTYPE CrossStudio_Project_File> |
2 | <solution Name="Test" target="8" version="2"> |
3 | <project Name="Test"> |
4 | <configuration |
5 | LIBRARY_IO_TYPE="RTT" |
6 | Name="Common" |
7 | Placement="Flash" |
8 | arm_architecture="v7EM" |
9 | arm_assembler_variant="gcc" |
10 | arm_compiler_variant="SEGGER" |
11 | arm_core_type="Cortex-M4" |
12 | arm_endian="Little" |
13 | arm_fp_abi="SoftFP" |
14 | arm_fpu_type="FPv4-SP-D16" |
15 | ...
|
16 | ...
|
17 | />
|
18 | <folder Name="Application"> |
19 | <file file_name="main.c" /> |
20 | </folder> |
21 | <configuration |
22 | Name="STM32F407" |
23 | arm_target_device_name="STM32F407IG" /> |
24 | <configuration |
25 | Name="STM32F429" |
26 | arm_target_device_name="STM32F429II" /> |
27 | </solution> |
> 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
Normalerweise müsste doch jede Build-Umgebung mehrere Targets erlauben. Schon allein für Debug und Release.
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
Olaf schrieb: > Alles nach dem klassischen make ist ein grosser Mist dann hast du einfach nicht verstanden was cmake macht.
Johannes S. schrieb: > dann hast du einfach nicht verstanden was cmake macht. zum beispiel JSON Dateien auswerten um damit seine Configurationen zu bauen: https://cmake.org/cmake/help/v3.19/command/string.html#json
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!
iar-hater schrieb: > Leute, nehmt den GCC und nicht den IAR! Oder den SEGGER Linker? SCNR ;-) https://www.segger.com/products/development-tools/embedded-studio/technology/tools/segger-linker/ https://www.segger.com/news/segger-compiler-and-linker-now-available-for-licensing-by-toolchain-providers/
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
1 | #include "stm32f4xx.h" |
gemacht ... HTH, Adib.
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.
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.