Der STM32-Thread

Der chaotische Hauptfaden

Moderatoren: Sven, TDI, Heaterman, Finger, duese, Marsupilami72

Antworten
berferd
Beiträge: 1211
Registriert: Mi 3. Apr 2019, 23:45

Der STM32-Thread

Beitrag von berferd »

Hallo zusammen, nachdem es einen Atmel/Arduino-Thread gibt, muss wohl auch ein STM32-Thread her.

Aktuell arbeite ich mich mal in den STM32 (Nucleo F401RE) ein. Entwickeln möchte ich unter Linux.
Ich arbeite bisher sehr gerne mit Makefile-basierten Umgebungen, mit gdb usw... also eher Kommandozeilig.

Wie steige setze ich die Umgebung am saubersten auf? Wichtig ist mir: möglichst Single Step Build, über Kommandozeile auslösbar. Meinetwegen auch eine GUI, aber der Build soll möglichst auch ohne anstoßbar sein. Für meine Atmels habe ich da bisher immer "make" und "make program" gemacht, das ist recht elegant und schlank.

Es gibt da die STM32CubeIDE, die mir aber ziemlich überladen scheint. Wenn schon der Hauptbildschirm wie eine Webseite mit Facebook- und Instagram- und Wiki-Links loslegt, und schon das "Projekt-Anlegen" Fenster nicht richtig gerendert wird (Text ragt am Rand raus und daher nicht lesbar, Fenster ist nicht größer zu ziehen)... :roll:

Die Makefile-Beispiele, die ich bisher gefunden habe, arbeiten entweder ohne HAL (ich denke es ist wohl sinnvoll, die zu nutzen) oder sind relativ grottig (keine saubere Trennung von BSP-Files, HAL-Files und Projekt-Files.. wir kippen einfach alles in das Projektverzeichnis und bauen dann), haben die Dependencies nicht sauber, oder sind einfach nur Shell-Scripte ohne mit hardcoded Pfaden und ohne jede Fehlerprüfung.

Was ist da die sauberste Lösung für Linux? Wenns sein muss auch mit der GUI, ich will da nicht zu verbohrt sein. Grade die Config des STM32 scheint ja recht komplex zu sein, evtl. ist da doch die Konfiguration via GUI angebracht, anstatt da die Register wie beim Atmel einzeln zusammenzufischen, und bzgl Debugging hat eine integrierte GUI ja auch Vorteile.
Nehme ich da die STM32CubeIDE? Muss man bestimmte Sachen beachten, gibts Fallstricke?
Benutzeravatar
Fritzler
Beiträge: 12119
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der STM32-Thread

Beitrag von Fritzler »

berferd hat geschrieben: Mo 27. Mär 2023, 13:02 ich denke es ist wohl sinnvoll, die zu nutzen
Nein, genau das Gegenteil ist der Fall.
Der "HAL" ist ein verbuggter und aufgeblasener obfuscation layer.
Da wird kaum was abstrahiert, zB beim DMA musste immernoch die Channel Nummern reinwerfen anstatt zu sagen "DMA für UART2 bitte", danke für nix.

Was du nutzen kannst sind die CMSIS Headerfiles für die Register- und Bitdefinitionen, die will man nich wirklich selber reinhacken.
Die kannste aus einem erstellten Projekt des STM32 Cube rausziehen (nicht IDE).

Ein makefile mit make und make programm is ja shcnell geschrieben, das nutzt man dann eben imemr weiter.

Ansonsten kauf dir zum Debuggen den J-Link EDU, dann kannste Segger Ozone nutzen.
Das gibts auch für Linux.

Die Config sieht nur im HAL obfuscation layer kompliziert aus.
Es gibt nen Taktbaum mit ein paar Einstellungen für die Taktquelle und PLL, das wars.
Bevor eine Peripherie genutzt werden kann muss im Taktregister der Takt für diese eingestellt werden.
berferd
Beiträge: 1211
Registriert: Mi 3. Apr 2019, 23:45

Re: Der STM32-Thread

Beitrag von berferd »

Gut, dann lasse ich den HAL weg. Ich erinner mich dunkel da schon mal was gehört zu haben.
Zum Flashen wirds wohl openocd mit einem STLink-Klon, den habe ich schon. Bzw auf dem Eval-Board ist ja schon ein entsprechendes Interface (über USB angebunden) dabei.
nux
Beiträge: 66
Registriert: So 31. Jul 2016, 12:53

Re: Der STM32-Thread

Beitrag von nux »

Es gibt noch die STM32LL, die Low Level Library, welche bei einigen Kollegen gerne mal verwendet wird.
Insgesamt leichtgewichtiger und näher an der Hardware als die HAL.

Bei manchen Nucleo Boards kann man den ST-Link auf einen J-Link umflashen:
https://www.segger.com/products/debug-p ... -on-board/

Bei dem STM32CubeMX finde ich persönlich für die Inbetriebnahme der Elektronik die Clock Configuration ganz spannend und hilfreich.

Gruß nux.
Benutzeravatar
Fritzler
Beiträge: 12119
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der STM32-Thread

Beitrag von Fritzler »

nux hat geschrieben: Di 28. Mär 2023, 13:45 Bei dem STM32CubeMX finde ich persönlich für die Inbetriebnahme der Elektronik die Clock Configuration ganz spannend und hilfreich.
Sowie um überhaupt den passenden STM32 zu finden und dann gucken an welchen Pin welche Funktion ankommt.
Aber bloß niemals auf Code genererieren klicken von nicht funktionierenden makefiles bis zum falschen Takt kann da alles passieren :mrgreen:

Die LL ist meist nur eine Funktion welche ein Registerzugriff wrapped.
Das kann man auch gleich selber machen.
berferd
Beiträge: 1211
Registriert: Mi 3. Apr 2019, 23:45

Re: Der STM32-Thread

Beitrag von berferd »

Ich habe es via Makefiles zum Bauen bekommen. Zielführend war diese Seite hier: https://avrs.fi/arm/ dort gibts ein entsprechendes Makefile und Vorgehen, wie man sein Projekt-Verzeichnis anlegt.

Allerdings muss ich mich in Kürze auch mal an Komplexeres ranwagen, und da komme ich um die HAL wohl voraussichtlich nicht rum, es da auch um FS-Treiber usw geht.
Idee daher: mit Beispielprojekten aus dem STM32CubeF4-Paket anfangen.
Was empfiehlt sich dafür? STM32CubeIDE? STM32CubeCLT? Oder ist das reine Geschmackssache?
Benutzeravatar
Fritzler
Beiträge: 12119
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der STM32-Thread

Beitrag von Fritzler »

Der HAL nutzt den elmChan Fat32FS Treiber.
Nur haben die Sp*ck*en den nicht Original gelassen, sondern hier und da etwas verändert.

Nimm lieber das Original, das ist auch sehr gut erklärt wie man das einbaut und nutzt:
http://elm-chan.org/fsw/ff/00index_e.html
berferd
Beiträge: 1211
Registriert: Mi 3. Apr 2019, 23:45

Re: Der STM32-Thread

Beitrag von berferd »

Wenns nur der wäre.. u.a. brauche ich auch USB-Host-Code... :roll: Das alles selber neu zu schreiben dürfte etwas umfangreich werden.
Aber ich behalte das mal im Hinterkopf, dass ich den FAT-Teil ggf. selber neu aufsetze.
Benutzeravatar
Fritzler
Beiträge: 12119
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der STM32-Thread

Beitrag von Fritzler »

ja beim USB Horst brauchste leider ein Stückchen HAL.
Das aber so verbuggt, dass sich der STM32 gerne mal aufhängt wenn man dne USb Stick zu langsam reinsteckt :roll:
berferd
Beiträge: 1211
Registriert: Mi 3. Apr 2019, 23:45

Re: Der STM32-Thread

Beitrag von berferd »

Hurra, auf sowas baut man doch gerne auf :lol:
Das klingt ja alles eher nach "STM32 vermeiden" ... gibts da sinnvollere Alternativen?
Benutzeravatar
Fritzler
Beiträge: 12119
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der STM32-Thread

Beitrag von Fritzler »

Eigentlich nur den HAL.
Datenblätter und die Chips sind recht gut.

Die beileigende Software von Atmel/Microchip ARM Prozessoren is mindestens genauso Müll.
Dafür sind die Datenblätter bei Atmel/Microchip ARM Prozessoren fürn Poppes.
Der DMA hat Prioritäten steht in der Einleitung des Kapitels, dann steht da aber nich ob ID0 oder ID15 die höchste Prio is, das darfste dann selber per Experiment rausfinden...
Benutzeravatar
zauberkopf
Beiträge: 8898
Registriert: So 11. Aug 2013, 15:33
Wohnort: gefährliches Halbwissen

Re: Der STM32-Thread

Beitrag von zauberkopf »

ja beim USB Horst brauchste leider ein Stückchen HAL.
Das aber so verbuggt, dass sich der STM32 gerne mal aufhängt wenn man dne USb Stick zu langsam reinsteckt :roll:
Oh... mir schwarnt böses...
Das gleiche geht mir hier bei einem anderen Controller unter Threat X tierisch auf den Sack.

Ich fange schon langsam an, mich in die USB-Scheisse hineinzuarbeiten.
Virtex7
Beiträge: 2368
Registriert: Di 13. Aug 2013, 21:50
Wohnort: Erlangen

Re: Der STM32-Thread

Beitrag von Virtex7 »

vielleicht nicht unbedingt beliebt, aber wenn es das cube IDE nicht gäbe, würde ich immernoch stm32 kategorisch vermeiden.
Ich hab so etwa vor 8-10 Jahren schonmal versucht, mit den DIngern was zu machen, es ist so grandios gescheitert. Alles nach Datenblatt, wie beim Atmel avr auch.
check ich nicht.. :?

-> cube IDE funktioniert mit dem gekauften stlinkv2 und die Pins tun was sie sollen.. meist zumindest.
Aber ohne das wöre ich stumpf aufgeschmissen.

Also vielleicht auch mal ein Herz für HW Leute. Ohne Arduino und CubeIDE und wie sie alle heißen (und kostenlos sind und NICHT KACK KEIL), wäre mir das Thema versperrt.
Benutzeravatar
zauberkopf
Beiträge: 8898
Registriert: So 11. Aug 2013, 15:33
Wohnort: gefährliches Halbwissen

Re: Der STM32-Thread

Beitrag von zauberkopf »

Naja... also ich habe damals mit 8051 angefangen, mit den Hilfsmitteln : Buch, Epromprogrammer und Epromsimulator.
AVR mit Programmer.. wobei ich sagen muss : Der Bootloader vom Arduino war schon gut.
Herangetastet habe ich mich weniger mit Datenblatt, sondern mit Buch und einfachen beispielen.
Dann klappts auch auf kommandozeilenebene.

Für quick and dirty, nehme ich heute Rasperry Pico unter Python.

Zurrück zur kommandozeilenebene.
Das schöne an make ist, das man aus einem Projekte per parameter verschiedene Versionen ganz einfach erzeugen kann.
z.B. ne Debug version, und dann die endgültige..
Oder noch ne Testversion dazwischenschieben.
Wenn man make nicht hat, muss man im Programmcode irgendwelche Inlcudes etc.. auskommentiereren...
Und wenn ne Versionsverwaltung dahintersteht, wirds dann spassig.

Auch hat man nicht immer volle kontrolle über das Projekt.
z.B. wenn vor 5 Jahren was geschrieben hat, das läuft.. und danach von der IDE immer fleißg updates gezogen hat... mit den ganzen libs... kann es später gut sein,
das nach 5 Jahren plötzlich nicht mehr compiliert.

Deswegen packe ich den dazugehörigen Rotz immer mit in den Projektordner.
Antworten