Hallo zusammen,
ich suche für mein Wiedereinstiegsprojekt in die Mikrocontrollerwelt ein
paar Infos zu meinem Vorhaben:
- kleine µC-Boards sollen Taster einlesen und Relais schalten
(Standardkram Homeautomation)
- Verwendung eines aktuellen µCs (STM32?), der in 10 Jahren nicht
komplett tot ist. (was Arm-basiertes?)
- freier/offener Compiler (also wohl gcc)
- die Entwicklung soll unter Linux/Ubuntu laufen
- halbwegs komfortables debuggen (also kein printf-debugging) => GDB +
STLink?
- als Entwicklungsumgebung würde ich z.B. VisualStudio Code nehmen
(läuft das gut mit STM32 + GDB?)
Soweit wären das meine ersten Anforderungen/Gedanken.
Ob ich jetzt irgendein Framework (Arduino...) oder bare-metal
programmieren will, weiß ich noch nicht.
Es gibt da einen STM32-Arduino Port. Ist das inzwischen alles so
ausgereift, dass das 24/7 sauber läuft - auch wenn man ein paar 3rd
party libs einbindet?
Ich würde mal mit einem STM32F103 (BluePill) starten und mich dann
weitertasten.
Ich verfolg(t)e seit ~10Jahren die Bastler-Community nicht mehr so
richtig. Es hat sich für mich also einiges getan.
So, jetzt könnt ihr mich bitte mit positiven Erfahrungen und
Google-Begriffen bewerfen. :-)
Es geht mir also mehr um die Einschätzung, was man heute so einsetzt, wo
gute Erfahrungen bestehen und was Zukunft hat.
Danke,
Axel.
Axel schrieb:> - als Entwicklungsumgebung würde ich z.B. VisualStudio Code nehmen
Warum nicht die STM32CubeIDE? Die ist genau dafür gemacht und da passt
alles genau zusammen für genau diesen Einsatzzweck.
Axel schrieb:> - kleine µC-Boards sollen Taster einlesen und Relais schalten> (Standardkram Homeautomation)
Ok, passt doch.
> - Verwendung eines aktuellen µCs (STM32?), der in 10 Jahren nicht> komplett tot ist. (was Arm-basiertes?)
Meines Wissens, sind die meisten STM32 ARM-Basiert. Wie definierst du
komplett tot? ;)
> - freier/offener Compiler (also wohl gcc)
Wähle ich auch imme für meine privaten Projekte. Auch beruflich nutze
ich GCC sehr oft.
> - die Entwicklung soll unter Linux/Ubuntu laufen
Ok
> - halbwegs komfortables debuggen (also kein printf-debugging) => GDB +> STLink?
STLink kenne ich zu wenig. Hab mir einen Segger gegönnt, sind aber teure
Dinger. Obwohl es heute glaub ich eine Education Edition gibt.
Zu STLink und GDB findest du auf Google und Youtube viele Tutorials.
> - als Entwicklungsumgebung würde ich z.B. VisualStudio Code nehmen> (läuft das gut mit STM32 + GDB?)
VSCode benutze ich inzwischen auch immer häufiger, habe aber noch zu
wenig Erfahurngen gemacht mit dem Debuggen. Aber bisher hatte ich keine
unlösebare Hindernisse. Entwickeln ansich funktioniert sehr gut und
bequem. Vorallem in kombination mit CMake finde ich es sehr praktisch.
Die schon erwähnte STM32CubeIDE kenne ich selbst nicht. Bisher habe ich
viel gutes gehört, natürlich auch von eingen Problemen mitbekommen. Aber
wo hat man die schon nicht. Von mir ausgesehen ist die Wahl der IDE eine
Geschmackssache.
Arduino finde ich persönlich uninteressant. Für Anfänger oder als mittel
zum Zweck hört es sich aber ganz praktisch an. Aber du hörst dich
weniger wie ein Anfänger an ;)
Axel schrieb:> als Entwicklungsumgebung würde ich z.B. VisualStudio Code nehmen> (läuft das gut mit STM32 + GDB?)
Auf der Arbeit setze ich auch nur noch vscode ein. Mit den beiden
Erweiterungen "Cortex-Debug" und "C/C++" hab ich alles erfolgreich zum
Entwickeln und Debuggen mit meinem J-Link zum laufen bekommen. Auch ein
Nucleo-Board mit dem integrierten ST-Link hat zum Debuggen ohne Probleme
funktioniert.
Schau dir diese Infos an: http://stefanfrings.de/stm32/index.html
Die Blue-Pill Boards sind problematisch da offenbar überwiegend
schlechte Fälschungen verkauft werden. Bei RobotDyn bekommst du mit
Sicherheit originale, aber da kannst du dann gleich die neueren
STM32F303 Boards im selben Format verwenden.
Für den Start würde ich allerdings dringend zu einem Nucleo oder
Discovery Board raten, denn da ist der Programmieradapter schon drauf
und es gibt keine Probleme mit gefälschten Chips, Designfehlern und
Bestückungsfehlern. Am Anfang ist es ungemein hilfreich, eine Hardware
zu haben, die garantiert in Ordnung ist und wo einfach nur noch das USB
Kabel dran stecken muss.
Axel schrieb:> - Verwendung eines aktuellen µCs (STM32?), der in 10 Jahren nicht> komplett tot ist. (was Arm-basiertes?)> Ich würde mal mit einem STM32F103 (BluePill) starten und mich dann> weitertasten.
Vielleicht kann man den STM32F103 auch in 10 Jahren noch kaufen (ala
LM317, CD4011...), aber er ist heute schon völlig veraltet. Das war STs
erster Versuch und man merkt es. Die nächste Generation war schon
deutlich besser, dann kamen die STM32L0 und L4 und dann die G0 und G4.
Daneben gibt es noch größere, aber die sind dann wirklich
überdimensioniert.
> Es geht mir also mehr um die Einschätzung, was man heute so einsetzt
Mit "man" meinst du doch nicht die Millionen Fliegen?
> - freier/offener Compiler (also wohl gcc)
gcc ist der offizielle ARM-Compiler¹. Für Neugierige gibt es noch
llvm/clang, ein moderneres Konzept und Frontend mit evt. nicht so
ausgereiftem Backend.
> - halbwegs komfortables debuggen (also kein printf-debugging) => GDB +> STLink?
wer GDB mag: Black Magic Probe² ist nach Leistung und Preis ein
Mittelding zwischen STLink und Segger.
1)
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads
oder, nicht ganz so offiziell, aber aktuell:
https://www.archlinux.org/packages/community/x86_64/arm-none-eabi-gcc/
2) https://1bitsquared.de/
Ich hab vor kurzem begonnen mit https://platformio.org herumzuspielen
und bin davon begeistert. So wie ich das verstanden habe ist das ein
Plugin (?) für VS Code, das Support für viele verschiedene
Mikrocontroller(-Boards) bereitstellt mit Toolchain, Framework und
Debugger. Das Setup hat für mich völlig schmerzfrei funktioniert und ich
konnte schnell das erste Erfolgserlebnis verbuchen.
M. T. schrieb:> Ich hab vor kurzem begonnen mit https://platformio.org> herumzuspielen> und bin davon begeistert. So wie ich das verstanden habe ist das ein> Plugin (?) für VS Code, das Support für viele verschiedene> Mikrocontroller(-Boards) bereitstellt mit Toolchain, Framework und> Debugger. Das Setup hat für mich völlig schmerzfrei funktioniert und ich> konnte schnell das erste Erfolgserlebnis verbuchen.
Also:
1. Du bist begeister von Platformio und damit herumzuspielen
2. Du hast "verstanden", daß es ein Plugin (?) für VS Code ist
3. Setup war Schmerzfrei, aka lief top
Kann es sein, daß es nur Werbun ist? Alles zusammen ergibt keinen
logischen Zusammenhang.
Hä? schrieb:> Kann es sein, daß es nur Werbun ist?
Das nennst du Werbung? In jedem Thread zu dem Thema wird mindestens
fünfmal CubeIDE empfohlen. Das ist Atollic Studio, und da wurde vor ein
paar Jahren hier noch ganz anders drüber geurteilt. Jetzt von ST
gekauft, Konkurrenz Unterstützung rausgeworfen und alles ist gut...
PlattformIO ist da deutlich mehr Multi Kulti. Genau wie Mbed das
ebenfalls sehr gut unter Linux verwendet kann. Auch sehr flexibel in
VSCode inclusive debugger zu benutzen.
Hallo zusammen,
ich habe mich jetzt für VisualStudio Code + PlatformIO entschieden. Die
Installation dauerte nur wenige Minuten. Das erste Testprojekt (Counter
hochzählen + LED blinken) war schnell angelegt/auto-generiert. Dann
musste ich noch 99-platformio-udev.rules ausführen, sonst ist ein
Runterladen wegen Zugriffsrechten (Linux) nicht möglich. Nach 30min war
alles fertig.
Ich hatte ein Watchfenster, Disassembly, Breakpoints, Prozessorregister
- alles was man so braucht. Nicht super-komfortabel-highend, aber
scheinbar solide. Ob da ein Makesystem dahintersteckt, oder ob das was
ganz anderes ist, muss ich mir noch anschauen.
Mein Evalboard hat einen STM32F103 bestückt, dazu ein ST-LinkV2. Ob es
bei dem F103 bleibt, oder ob ich auf neuere Derivate umsteige, muss ich
noch klären. Danke für den Hinweis auf neuere...
Warum nicht STM32CubeIDE? Ich möchte mich möglichst wenig an jemanden
binden. Wenn der Hersteller keine Lust mehr hat, muss ich mich neu
umsehen.
PlatformIO scheint eine freie breite Unterstützung zu haben. Und für
meine Zwecke ausreichend zu sein. (Ich brauche z.B. nicht unbedingt eine
grafische Konfiguration der Portpins...).
> Meines Wissens, sind die meisten STM32 ARM-Basiert. Wie definierst du> komplett tot? ;)
Genau, auf ARM setzen, da diese die besten Zukunftsaussichten haben. Tot
sind heute z.B. alle 16bitter.
Danke für alle Tipps, die das Thema aus verschiedenen Richtungen
beleuchteten!
Jetzt würde mich mal interessieren, wie die Peripherie beim VisualStudio
Code + PlatformIO angezeigt wird. Ich hatte den Thread auch verfolgt, da
ich nach einer Debugmöglichkeit von STM32s unter Linux gesucht und
gestern die STM32CubeIDE zum Laufen gebracht hab. Mein Hauptproblem war
dass ich nicht unnötig Tools von ST Verwenden wollte sondern möglichst
viel aus dem Debian Repository. Am Ende funktioniert es jetzt mit
openocd:
openocd -f /usr/share/openocd/scripts/interface/stlink-v2-1.cfg -f
/usr/share/openocd/scripts/target/stm32f0x.cfg
Und die Einstellung im CubeIDE ist sich remote auf den von openocd
bereitgestellten GDB Server zu verbinden, die Debug Probe ist ein
ST-Link von einem Nucleo64. Das ist schon echt komfortabler als printf
debugging auf einem AVR. Aufgrund der höheren Komplexität der STM32 aber
IMHO auch notwendiger.
Malte _. schrieb:> Und die Einstellung im CubeIDE ist sich remote auf den von openocd> bereitgestellten GDB Server zu verbinden,
Warum stellst du nicht einfach in der IDE ein, dass sie OpenOCD starten
soll? Sie enthält nämlich bereits beides, GDB und OpenOCD.
Malte _. schrieb:> Mein Hauptproblem war> dass ich nicht unnötig Tools von> ST Verwenden wollte sondern möglichst viel aus dem Debian Repository.
Ganz ehrlich: Damit machst du dir das Leben nur unnötig schwer.
Sämtliche IDEs installiert man besser außerhalb der Linux Distribution,
so wie es der Anbieter vorgesehen hat. Dann hast du nämich nicht nur die
aktuelle Version, sondern auch die vorgesehene Verzeichnisstruktur. So
bekommt man viel besser Support.
Der mitgelieferte ST-Link GDB bietet den Vorteil, dass er Trace Messages
innerhalb der IDE anzeigen kann. OpenOCD kann sie nur in eine Datei
schreiben.
