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.
Nehm die STM32CubeIDE (offiziell von ST) und ein Discoveryboard. Geht beides unter Linux.
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 ;)
:
Bearbeitet durch User
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!
Angehängte Dateien:
-
stmCube32Debugger.png
270 KB
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.
Angehängte Dateien:
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.
Angehängte Dateien:
-
VSC_PlatformIO_STM32.png
430 KB -
VSC_Peripherals.png
76 KB
Hallo Malte, so sieht VisualStudio Code mit PlatformIO aus.
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.