Hallo Community, Ich hätte da mal ein paar Fragen zum STM32 und drumherum. Ich habe mir letzte Woche ein Nucleo-64 Board bestellt. Auf diesem ist ein STM32F446RE Mikrocontroller verbaut. Ich möchte erstmal ein paar Erfahrungen mit der MCU/STM32 allgemein sammeln. Ein konkretes Projekt welches ich jetzt unbedingt mit dem STM32 umsetzten möchte habe ich nicht. Bisher habe ich mich die letzten 5 Jahre nur mit den ATMegas und ATTinys von Atmel beschäftigt. Was mich besonderes an den STM32 interessiert ist der DAC, CAN und die teils hohen Geschwindigkeiten die sich mit SPI erreichen lassen. Als IDE verwende ich die von ST zur Verfügung gestellte STM32CubeMX IDE. Die graphische Konfigurationsoberfläche ist ganz nett, aber auf Dauer könnte ich mich damit glaubig nicht anfreunden. Das mich die Software dann zwingt in vorgegeben Bereichen mein Code zuschreiben, naja ist nicht so meins. Mal eine Frage an alle die von AVR/PIC auf STM32 umgestiegen sind oder beides machen. Wie habt ihr euch in den STM32 "eingearbeitet"? Gibt es da gute Tutorial deutsch/englisch, ist mir beides recht, oder Bücher? Habe auch hier im Forum diverse Beiträge als auch Artikel durchgelesen zum STM32 aber irgendwie habe ich nicht so richtig das passende gefunden. Habe mir auch von ST das STM32CubeF4 Packet runtergeladen da sind ja ein Haufen an Beispielcodes drin. Aber zum Beispiel diesen Interrupt Handler raff ich irgendwie gar nicht trotz Codebeispiel. Die Datenblätter habe ich mir schonmal in Ruhe angeschaut. Sind doch sehr komplex, aber gut dafür kann der STM auch viel. Was ich ein bisschen vermisse sind die Codebeispiele wie bei den AVR Datenblätter. Eine andere Frage die ich habe wäre die HAL Library. Da scheinen sich ja irgendwie so ein bisschen die Geister zu trennen. Die einen Nutzen es nur, die anderen nicht und manche machen beides. Verwendet ihr die HAL Library? Oder sprecht ihr die Register direkt an? Was mir wohl direkt aufgefallen ist das ein simples Blink Programm was nur eine LED ein und ausschalte mit 1000ms Delay braucht schon viel Speicher (~11kB Flash) ohne HAL ist es deutlich weniger (~2kB) naja die MCU hat ja 512kB da sollte das jetzt nicht die größte Rolle spielen. Bei 180MHz auf den die CPU rennt machen wahrscheinlich ein paar Takte mehr oder weniger für eine Operation auch kein so großen Unterschied mehr. Hab beides ausprobiert. Diese Strukturen mit GPIOTypdef... etc.. gefallen mir ganz gut. Die LED die auf den Nucleo Board verbaut ist ein und auszuschalten war mit der HAL Library kein Problem, auch beim versuch die Register direkt zu nehmen hat es zwar ein bisschen länger gedauert bis ich die Register der GPIOs verstanden habe, und bis ich mal die Clock von GPIOA eingeschaltet bekomme habe ... , aber am Ende hat auch das funktioniert. Jedoch sah das beim USART schon wieder anderes aus da bin ich mit den Register gescheitert genauer gesagt die Baudrate festzulegen. Mfg
Beitrag #6752407 wurde vom Autor gelöscht.
Felix N. schrieb: > Jedoch sah das beim USART schon wieder anderes aus da bin ich mit den > Register gescheitert genauer gesagt die Baudrate festzulegen. Bist ja schon recht weit vorgedrungen. Mein Rat: verwende CubeMX, auf Dauer ist das schneller und besser, und generiere deinen Code nicht auf HAL-Basis sondern auf LL-Basis. Das ist einstellbar, nur nicht so offensichtlich dass es einem gleich ins Auge sticht (LL --> Low Level Driver). Alles was du an Register-Manipulationen machen möchtest kannst du entweder mit LL-Calls durchführen oder in den LL-Libs "spionieren" wie man auf die Register zugreift und selbst Code daraus ableiten. So kommst du z.B. auch leicht zum eigenen UART-Driver.
Für ein kleines sparsames Blinky würde ich einen 555 in SMD nehmen. Bei Ethernet, SDC, Grafikdisplays, USB, RTOS fängt der Spaß mit Cortex-M an. Und sogar ein OS kann man sich da leisten.
Felix N. schrieb: > Das mich die Software > dann zwingt in vorgegeben Bereichen mein Code zuschreiben, naja ist > nicht so meins. Tut sie nicht, mein Code ist absolut getrennt von dem was CubeMX generiert. Die meisten Handler und callbacks sind weak definiert und du kannst sie bei dir einfach neu definieren und ansonsten muss ich in der main.c nur zwei Funktionen bei mir einbinden und das ist persistent, wenn man es an die richtige Stelle schreibt. Was die Nutzung von Cube/HAL angeht schließe ich mich dem Vorredner an. In meinem Fall habe ich es mit recht vielen verschiedenen Serien von ST zu tun, da will man nicht immer alles von 0 an machen. Und ganz ehrlich was den Overhead angeht ist der für die meisten Leute egal, weil die µC schnell genug sind und der höhere Speicherverbraucht ist auch egal, die haben mehr als genug. Die Zeiten von Atmega 8-bittern mit null Speicher ist vorbei.... Auch wenn hier einige harneckige User existieren, die nicht einsehen wollen, das es gerade im Hobby Bereich absolut egal ist und man einfach einen entsprechend µC mit viel Speicher kaufen kann. Die arbeiten aber vermutlich auch noch mit 10GB HDDs.
beo bachta schrieb: > Mein Rat: verwende CubeMX, auf Dauer ist das schneller und besser, > und generiere deinen Code nicht auf HAL-Basis sondern auf LL-Basis. > Das ist einstellbar, nur nicht so offensichtlich dass es einem > gleich ins Auge sticht (LL --> Low Level Driver). Hallo! Mit CubeMX meinst du jetzt den graphischen Konfigurator für Pins oder so? Ich habe mal gerade nachgeschaut ich kann es unter Advanced zwischen HAL und LL umschalten. Schaue ich mir mal genauer an. Lässt du den Code zB. für SPI von CubeMX generieren also SPIX auswählen Full-Duplex Master oder schreibst du dir das selber? beo bachta schrieb: > So kommst du z.B. auch leicht zum eigenen > UART-Driver. Ah ok. Ja ich habe bei meinem Versuch am Ende etwas gemogelt. Habe in der entsprechenden HAL Datei die Baudkalkulation rausgesucht und sie mit automatisch Generierter Baudrate ausgeben lassen hab den Wert dann ins Register geladen und dann tat der USART nach "Register" auch wie von HAL generiert. Kevin M. schrieb: > Tut sie nicht, mein Code ist absolut getrennt von dem was CubeMX > generiert. Die meisten Handler und callbacks sind weak definiert und du > kannst sie bei dir einfach neu definieren und ansonsten muss ich in der > main.c nur zwei Funktionen bei mir einbinden und das ist persistent, > wenn man es an die richtige Stelle schreibt. Am Anfang wusste ich das nicht hab mein Code nicht in USER CODE BEGIN und END geschrieben. Code generiert. Alles was ich gemacht habe war weg. Hat mich in dem Moment schon etwas aufgeregt. Das meinte ich die Software zwingt mich zwischen USER CODE BEGIN .. END zuschreiben. Oder meinen wir beide jetzt unterschiedliche Dinge? Kevin M. schrieb: > Und ganz ehrlich > was den Overhead angeht ist der für die meisten Leute egal, weil die µC > schnell genug sind und der höhere Speicherverbraucht ist auch egal, die > haben mehr als genug. Hatte ich ja auch geschrieben das es bei 512Kbytes an Flash und 128kBytes an RAM nicht so wirklich drauf ankommt. Kevin M. schrieb: > Die Zeiten von Atmega 8-bittern mit null Speicher > ist vorbei.... Bis jetzt passte immer irgendwie alles drauf, mein Blick ging irgendwie immer als erstes nach dem Kompilieren auf den Speicherverbrauch. Mein größtes Projekt bis jetzt ist mein Aquarium Steuergerät läuft auf einem ATMega2560 mit externen 56kB SRAM. Dort sind im Moment 123kBytes an Flash und 5kB an RAM belegt(Heap etwa 3-4kB). Mfg
Felix N. schrieb: > Lässt du den Code > zB. für SPI von CubeMX generieren also SPIX auswählen Full-Duplex Master > oder schreibst du dir das selber? Wenn man das einmal selbst gemacht hat fällt es einem sehr leicht das für andere (STM-) Controller umzuschreiben oder gleich ohne Änderungen weiterzuverwenden. Also ja, so etwas stricke ich mir selber und gewinne ein paar Taktzyklen dabei, wenn auch nicht viel. Denn viele LL-Calls werden "ge-inlined" oder vom Compiler so optimiert als wären sie Inline-Code. Dagegen bin ich aber so "faul" und nutze die vergleichweise komfortablen LL-Calls zur Initialisierung von Peripherie. Dabei lohnt es sich nicht selbst zu optimieren.
Felix N. schrieb: > Das meinte ich die > Software zwingt mich zwischen USER CODE BEGIN .. END zuschreiben. Oder > meinen wir beide jetzt unterschiedliche Dinge? Ja irgendwie muss der Code Generator ja wohl erkennen was er überschreiben kann und was nicht. Wenn du deinen Code aber sinnvoll aufbaust hast du alles von dir geschriebene in seperaten dateien und musst zwischen USER CODE BEGIN .. END nur deine Loop und Main einfügen.
Felix N. schrieb: > Ich habe mir > letzte Woche ein Nucleo-64 Board bestellt. Auf diesem ist ein > STM32F446RE Mikrocontroller verbaut. Gute Wahl für den Einstieg! Felix N. schrieb: > Als IDE verwende ich die von ST zur Verfügung gestellte STM32CubeMX IDE. > Die graphische Konfigurationsoberfläche ist ganz nett, aber auf Dauer > könnte ich mich damit glaubig nicht anfreunden. Das mich die Software > dann zwingt in vorgegeben Bereichen mein Code zuschreiben, naja ist > nicht so meins. Dazu zwingt dich niemand! Du kannst deinen Code problemlos in eigene .c und .h-Files schreiben. Der generierte Code nimmt dir einfach sehr viel Arbeit für die Initialisierung ab (aber auch nicht mehr!), und das ist gut so! Felix N. schrieb: > Was ich ein > bisschen vermisse sind die Codebeispiele wie bei den AVR Datenblätter. Es gibt in den HAL-Sourcen u.A. jede Menge Beispiele, und es gibt die Application-Notes. Außerdem findet man von ST auf YT jede Menge Education-Videos zu dem Thema. Felix N. schrieb: > Mal eine Frage an alle die von AVR/PIC auf STM32 umgestiegen sind oder > beides machen. Wie habt ihr euch in den STM32 "eingearbeitet"? Genau so, wie du! CubeMX ist eine enorme Hilfe für den Einstieg, aber das generiert nicht deine Anwendung, sondern nur die immer wiederkehrenden Initialisierungs-Funktionen. Wenn du die Peripherie effektiv nutzen und verstehen willst, musst du trotzdem Datenblätter und AppNotes studieren. Ich würde auf CubeMX nur sehr ungern verzichten, Felix N. schrieb: > Aber zum Beispiel diesen > Interrupt Handler raff ich irgendwie gar nicht trotz Codebeispiel. Gerade das wird durch die diversen Callbak-Funktionen enorm erleichtert. Felix N. schrieb: > Was mir wohl direkt aufgefallen ist das ein simples Blink Programm was > nur eine LED ein und ausschalte mit 1000ms Delay braucht schon viel > Speicher (~11kB Flash) ohne HAL ist es deutlich weniger (~2kB) Ja und? Sobald u etwas mehr als ein Bliky schreibst, wirst du diesen Code so oder so brauchen. Felix N. schrieb: > auch beim > versuch die Register direkt zu nehmen hat es zwar ein bisschen länger > gedauert bis ich die Register der GPIOs verstanden habe, und bis ich mal > die Clock von GPIOA eingeschaltet bekomme habe ... , aber am Ende hat > auch das funktioniert. Und warum tust du dir das an? Das sind "wiederkehrende Aufgaben", die CubeMX dir auf nahezu perfekte Weise abnimmt, und der Overhead durch die HAL-Funktionen ist in den allermeisten Fällen vernachlässigbar. Klar, enthält auch CubeMX noch einzelne Fehler, aber inzw. hat HAL eine "Reife" erreicht mit der man bereits sehr gut leben kann. Würdest du das selber schreiben, wären da ganz sicher sehr viel mehr Fehler drin. Felix N. schrieb: > Jedoch sah das beim USART schon wieder anderes aus da bin ich mit den > Register gescheitert genauer gesagt die Baudrate festzulegen. Dafür gilt das genauso. Über huartx.Instance->xxx kannst du direkt auf die Register zugreifen (obwohl das im Fall der Baudrate vollkommen unnötig ist, so lange du die nicht im laufenden Betrieb ändern willst) Ich häng dir mal nen Code für UART mit HAL an, der auch einige Interrupt-Callbacks enthält. Alles kein Hexenwerk!
:
Bearbeitet durch User
beo bachta schrieb: > Also ja, so etwas stricke ich mir > selber und gewinne ein paar Taktzyklen dabei, wenn auch nicht > viel. Denn viele LL-Calls werden "ge-inlined" oder vom Compiler > so optimiert als wären sie Inline-Code. Muss sagen der Unterschied zwischen HAL und LL ist mir noch nicht wirklich klar geworden. Ich habe in CubeMX mal von HAL auf LL gestellt und den Code neu erstellen lassen die Funktionsaufrufe heißen nun anderes und benötigten Teilweise auch Argumente wo HAL keine Benötigt hat. Kevin M. schrieb: > Wenn du deinen Code aber sinnvoll > aufbaust hast du alles von dir geschriebene in seperaten dateien und > musst zwischen USER CODE BEGIN .. END nur deine Loop und Main einfügen. Harry L. schrieb: > Du kannst deinen Code problemlos in eigene .c und .h-Files schreiben. Ah ihr meint das also so das es dann einmal die "normal" main.c/h wo auch die richtige main(void) drin steht gibt. Und ich erstelle mir dann meine c/h Dateien zB. system.c/h und dort gibt mache ich mir so zusagen eine zweite "main" auf wo ich dann alles reinschreibe Initialisiere etc.. Und dann nur einmal kurz in der richtigen main die beiden Funktionen aufrufe? Sprich
1 | //STM Stuff |
2 | //User begin |
3 | my_initStuff(); |
4 | //User end |
5 | |
6 | while(1) .. |
7 | //User begin |
8 | myLoopStuf(); |
9 | //User end |
Harry L. schrieb: > Es gibt in den HAL-Sourcen u.A. jede Menge Beispiele, und es gibt die > Application-Notes. Meinst du das "Description of STM32F4 HAL and low-layer drivers" Dokument? Mit so knapp 2100 Seiten? Harry L. schrieb: > Und warum tust du dir das an? Ich wollte es nur ausprobieren ob es so auch geht. Bis jetzt bin ich das gewohnt. Ins Datenblatt reinzuschauen welches Register das ist und welche Bits gesetzt werden müssen. Bzw. zum Teil kenne ich manche Register auch schon auswendig für die ATMegas. Und zumal habe ich irgendwo, in einem anderen Forum, gelesen das man die Register NICHT direkt ansprechen soll weil HAL noch irgendwie? eine Art Fehlerbehandlung drin hat, konnte des bzgl. aber nix finden. Außer die Statuscodes die HAL zurück gibt, zB beim init von Strukturen. Harry L. schrieb: > Wenn du die Peripherie effektiv nutzen und verstehen willst, musst du > trotzdem Datenblätter und AppNotes studieren Ja das ist klar. ST bietet ja einige Datenblätter an für den Controller. So wie ich das sehe brauche ich aber nur 2 Daten einmal das Spezifikationsdatenblatt wo Pinout und Blockdiagramm drin stehen und einmal das Reference Datenblatt wo die ganzen Register beschrieben sind. Zusätzlich dann noch die Dokumentation zu HAL. Harry L. schrieb: > Dafür gilt das genauso. > Über huartx.Instance->xxx kannst du direkt auf die Register zugreifen Ah okay. Gut zu wissen. Harry L. schrieb: > Ich häng dir mal nen Code für UART mit HAL an, der auch einige > Interrupt-Callbacks enthält. Cool. Erstmal danke dafür! Habs mir mal heute Nacht grob angeschaut. Muss gestehen so auf den ersten Blick verstehe ich nicht wirklich was da ab geht. Dieses FIFO ist mir fremd scheint aber wenn ich das noch richtig im Sinne habe was mit den DMA Controller zutun haben? Mfg
Ich bin der Meinung, dass man am Anfang versuchen sollte, die Peripherie selbst mittels bare metal zu initialisieren. Der Grund dafür ist, dass man ein wesentlich besseres Verständnis für den STM32 bekommt, wie die jeweilige Peripherie funktioniert und welche Bits in welche Register was bewirken. Felix hat es ja bereits selbst erlebt, dass er bei der Initialisierung eines GPIOs bereits ein wenig ins Schwitzen gekommen ist. Und das ist gut so, denn es ist im ersten Moment nicht trivial, bedarf ein gründliches Durchlesen des Datenblatts/Ref Manuals und man bekommt ein gutes Verständnis für die IDE und die Debugfunktion. WENN man das verstanden hat, kann man für spätere Anwendungen dann HAL oder LL verwenden (ich selbst tendiere eher für LL), um das Rad nicht immer wieder neu erfinden zu müssen. Ich selbst bin ebenfalls in den Anfängen mit dem STM32 und schreibe ausschließlich bare metal. Es hat mich letztens 6 Stunden gekostet, den DAC mit DMA zum Laufen zu bringen. Die Frustration in den 6 Stunden war groß, das Erfolgserlebnis und die Freude nach 6 Stunden war aber größer :) Für den Einstieg in bare metal empfehle ich einen Kurs auf Udemy, der wirklich gut ins Details geht (es gibt dort oft Angebote, wo der Kurs ca 10Eur kostet): https://www.udemy.com/course/mastering-microcontroller-with-peripheral-driver-development/
Als ich den kleinen STM32F100 auf dem DiscoveryVL bekommen habe, gab es HAL noch nicht und ich habe deswegen mit SPL und CMSIS geschrieben. Das war nun auch nicht so schlimm. Allerdings hatte ich ein konkretes Projekt, das schon auf AVR8 und XMega lief und habe das auf den F100 portiert. Das war sicher eine gute Schule.
Felix N. schrieb: > Harry L. schrieb: >> Ich häng dir mal nen Code für UART mit HAL an, der auch einige >> Interrupt-Callbacks enthält. > > Cool. Erstmal danke dafür! Habs mir mal heute Nacht grob angeschaut. > Muss gestehen so auf den ersten Blick verstehe ich nicht wirklich was da > ab geht. Mir geht es genauso. Direkt programmiert (und hinreichend kommentiert) hat man mehr Transparenz und weniger Geschwätzigkeit. Wie Du siehst (Beispiel für USART2 beim G431 im Anhang), ist die Baudrate supersimpel einzustellen. Für den Einstieg finde ich es angenehm, per CubeMX den Takt zu konfigurieren. Mehr nicht! Das HAL-Zeugs kann man ignorieren. Von main() aus geht es zu den eigenen Routinen, die die Register direkt ansprechen. Als IDE für den Einstieg empfehle ich die Demoversion EWARM von IAR. Das Projekt wird direkt von CubeMX erstellt. Mit der IDE läßt sich sehr gut auch auf Registerebene debuggen. Während das Programm läuft, kann man Portpins aktivieren, Timer umkonfigurieren, sehen was in RX-Puffern steht, wie die DMA-Flags aussehen und ggf. triggern, ... Mit 32 kB Code kommt man schon recht weit und kann die Peripherie gut antesten. Für größere Projekte kann man auf eine andere, kostenlose IDE umsteigen. Da sind die Geschmäcker sehr unterscheidlich.
Felix N. schrieb: > Muss sagen der Unterschied zwischen HAL und LL ist mir noch nicht > wirklich klar geworden. LL spart in erster Linie Platz für sehr kleine MCUs, und geht auf Kosten der Portierbarkeit. So lange du das nicht wirklich brauchst laß erst einmal die Finger davon! Felix N. schrieb: > Und dann nur einmal kurz in der richtigen main die beiden > Funktionen aufrufe? Sprich > //STM Stuff > //User begin > my_initStuff(); > //User end > while(1) .. > //User begin > myLoopStuf(); > //User end Genau so! Felix N. schrieb: > Harry L. schrieb: >> Es gibt in den HAL-Sourcen u.A. jede Menge Beispiele, und es gibt die >> Application-Notes. > > Meinst du das "Description of STM32F4 HAL and low-layer drivers" > Dokument? Mit so knapp 2100 Seiten? Jain. Cube MX hat ja für dich bereits die erforderlichen HAL-Sourcen für deine MCU heruntergeladen, und in dem Source-Tree auf deiner Festplatte befinden sich bereits auch Beispielprojekte. Felix N. schrieb: > auf den ersten Blick verstehe ich nicht wirklich was da > ab geht. Dieses FIFO ist Das Konzept eines FiFo sollte schon bekannt sein, und das ist vollkommen Architektur-unabhängig. Der Code in fifo.c/.h hat rein gar nichts mit HAL zu tun und würde 1:1 so auch auf einem AVR laufen. Der interessante Teil steckt in serial.c/.h Felix N. schrieb: > wenn ich das noch > richtig im Sinne habe was mit den DMA Controller zutun haben? Bei asynchroner Übertragung (UART) macht ein DMA in den seltensten Fällen Sinn. Als Anfänger solltest du die DMAs erst einmal beiseite lassen. Was ich dir dringend empfehle ist dieses Dokument: https://www.st.com/resource/en/user_manual/dm00105879-description-of-stm32f4-hal-and-ll-drivers-stmicroelectronics.pdf Ja, das ist sehr groß, aber das ist wichtig zum Nachschlagen, und nicht um das linear zu lesen.
:
Bearbeitet durch User
Felix N. schrieb: > Wie habt ihr es gemacht? Ich habe meine Anfänge dort dokumentiert: http://stefanfrings.de/stm32/index.html > Verwendet ihr die HAL Library? Selten, die ist mir nicht geheuer. Der Code ist für mich nur schwer nachvollziehbar und manchmal fehlerhaft. Die Hal kann aber dabei hilfreich sein, wiederverwendbaren Code zu schreiben. Für meine wenigen Hobbyprojekte ist das relativ uninteressant. Wenn ich etwas wiederverwende, dann eher Treiber für externe Hardware wie z.B. Displays. Dafür brauche ich keine HAL.
Felix N. schrieb: > Als IDE verwende ich die von ST zur Verfügung gestellte STM32CubeMX IDE. Und zum Essen benutze ich einen Göffel. Spaß beiseite. Du hast da zwei Begriffe zusammen gemixt: * STM32CubeIDE (https://www.st.com/en/development-tools/stm32cubeide.html) * STM32CubeMX (https://www.st.com/en/development-tools/stm32cubemx.html) Wobei die Cube IDE das Cube MX inzwischen beinhaltet. Deswegen heißt sie aber nicht STM32CubeMXIDE - obwohl der name passend wäre.
Angehängte Dateien:
-
dma_fifo.png
36 KB
Alex -. schrieb: > Ich bin der Meinung, dass man am Anfang versuchen sollte, die Peripherie > selbst mittels bare metal zu initialisieren. Also die Register direkt ansprechen ohne HAL/LL? Oder was muss ich unter "Bare Metal" verstehen? Harry L. schrieb: > So lange du das nicht wirklich brauchst laß erst einmal die Finger > davon! Okay. Harry L. schrieb: > Das Konzept eines FiFo sollte schon bekannt sein First In First Out. Warteschlagenprinzip. Kenne ich schon. Hatte ich im Datenblatt bei dem STM32 in Kombination mit den DMA Controller in Form als "Stream" gesehen(Siehe Anhang). Daher fiel mir das direkt ein. Harry L. schrieb: > Als Anfänger solltest du die DMAs erst einmal beiseite lassen. Hatte ich auch vor. Harry L. schrieb: > Ja, das ist sehr groß, aber das ist wichtig zum Nachschlagen, und nicht > um das linear zu lesen. Ja genau dieses Dokument habe ich mit den 2100 Seiten gemeint. Das habe ich schon auf meiner Platte. Stefan ⛄ F. schrieb: > Ich habe meine Anfänge dort dokumentiert: > http://stefanfrings.de/stm32/index.html Ah interessant. Werde ich mir mal anschauen. Danke. Du hast jetzt das ganze für den F3 CPU gemacht. Lässt sich das vom Grundprinzip auch auf den F4 CPU anwenden? Mfg
Felix N. schrieb: > Lässt sich das vom Grundprinzip auch auf > den F4 CPU anwenden? Selbstverständlich. Allerdings schadet es sicher nicht, RM0090 (die Hardware Referenz für die F4) dabei zu haben. Für die Alternate Function Pins ist auch das Datenblatt zum speziellen Chip nützlich.
:
Bearbeitet durch User
Felix N. schrieb: >> Ich bin der Meinung, dass man am Anfang versuchen sollte, die Peripherie >> selbst mittels bare metal zu initialisieren. > Also die Register direkt ansprechen ohne HAL/LL? Ja, das bedeutet der Begriff. Würde ich auch für den Anfang empfehlen. Man versteht danach viel besser, was die HAL eigentlich macht und welche Fähigkeiten/Einschränkungen der Chip hast.
Felix N. schrieb: > Lässt sich das vom Grundprinzip auch auf den F4 CPU anwenden? Jede F-Serie ist in Details anders. Ich befürchte, dass der F4 dem F1 ähnlicher sein könnte als dem F3 weil die F3 Serie neuer ist. Aber das fragen wir besser mal die Experten die den F4 wirklich kennen. Wer weiß es genauer? Die USB Implementerung auf meiner Homepage funktioniert auf dem F4 jedenfalls nicht, das weiß ich mit Sicherheit.
naja, einige Dinge sind nicht unbedingt intuitiv, wie ADC über Timer triggern. Dafür gibt es aber auch einige gute App Notes und YT Videos von ST oder anderen. Das Schema mit HAL ist einfacher, es wird üblicherweise immer eine Struktur mit den gewünschen Einstellungen gefüllt und dann an eine Funktion übergeben. Diese kümmert sich dann darum das alles nötige und in der richtigen Reihenfolge gesetzt wird. Bei LL muss man sich selber zusammensuchen, ist wie geschrieben wurde etwas sparsamer weil der Zwischenschritt über die Struktur entfällt, aber nicht gerade leserlicher. ARM CM Code ist erstmal grösser, das hat viele Gründe: längere Instruktionen durch grösseren Adressraum, grosse Interrupt Vector table, C/C++ Library newlib ist umfangreicher, die Peripherie ist komplexer und möchte erst Clock und Power konfiguriert haben und sicher noch einige Gründe mehr. Dafür kann man mit den CM aber auch große und komplexe Systeme bauen. Und CubeMX ist nicht nur zum Code generieren, es fängt schon mit der Auswahl eines µC über die parametrische Suche an. Dann kann man damit sehr schön die Resourcen planen um die Pins möglichst vorteilhaft auf die Platine zu bekommen. Die komplexe Takteinstellung eines H7 möchte man auch nicht zu Fuss machen. Der Strombedarf des Controllers und die Batterielaufzeit wird berechnet wenn gewünscht. Cube generiert dazu auf Knopfdruck eine schöne Doku mit dieser Konfiguration. Dazu kann man noch PlugIns installieren für weitere komplexe Aufgaben. Und das meiste für Nüsse. Da man nörgeln wie man will, ich keinen anderen Hersteller der sowas bietet und auch wenn da noch der eine oder Fehler drin ist, es wird trotzdem auch massig professionell eingesetzt. Wenn man nicht 1 Projekt in 3 Jahren hat sondern 3 dicke Brocken in 1 Jahr, dann ist das eine sehr große Hilfe.
Stefan ⛄ F. schrieb: > Die USB Implementerung auf meiner Homepage funktioniert auf dem F4 > jedenfalls nicht, das weiß ich mit Sicherheit. Der F4 hat auch oft mehrere USB Engines, die alle ihre Eigenarten haben. Es hat hier etwas gedauert, aber ich habe auf dem F429 dann beide USB Ports zum laufen gekriegt, der eine macht ein CDC Device und der andere einen MSC Host. War schon ein wenig Tipperei, läuft aber problemlos gleichzeitig. Wie gesagt, gibt es zwischen BareMetal und HAL ja auch beliebige Abstufungen. SPL und CMSIS ist nur eine davon und bei mir im Moment die bevorzugte.
Felix N. schrieb: > Ich möchte erstmal ein paar Erfahrungen mit der MCU/STM32 allgemein > sammeln. Ein konkretes Projekt welches ich jetzt unbedingt mit dem STM32 > umsetzten möchte habe ich nicht. Dann lies einfach das Referenzmanual und das Datenblatt zum Chip und die Manuals zum CPU-Typ von Arm. Das reicht für's erste. Anschließend kannst du deine Erfahrungen sammeln beim Installieren und Ausprobieren von Toolchains (Arm/Keil, IAR, GCC) Der dritte Schritt ist dann das Programmieren einer Firmware in den chipinternen Flash. Entweder per Bootlader oder per JTAG/SWD. W.S.
Ich würde für die ersten Schritte auch Bare Metal Programmierung empfehlen. So versteht man die Zusammenhänge, was man alles initialisieren muss damit der Chip erst einmal grundlegende Funktionen ausführt. Neben dem was Stefan auf seiner Webseite erklärt habe ich mir hier 2 oder 3 Kurse zu verschiedenen Themen (jeder war unter 10 Dollar) gebucht, der erklärt wie man sich die benötigten Informationen aus dem Datasheet und dem Referenz Manual herausholt und zu Fuß die entsprechenden Bits in den Registern setzt. Das hat meinem Verständnis sehr geholfen: https://study.embeddedexpert.io/ Initialisierungen mache ich heute über CubeMX (geht schneller und man sieht Abhängigkeiten), aber ich weiss nun im allgemeinen was dort passiert.
Guten Abend und nochmal Hallo an alle, Ich wollte mich noch mal zum Abschluss zum Wort melden. Erstmal vielen lieben dank an euch allen für die nützlichen Tipps rund um den STM32. In der Zwischenzeit war ich auch nicht ganz untätig und habe mein erstes kleines STM32 Programm auf Register Basis fertig gestellt, es ist zwar nicht sonderlich nützlich aber es reicht zum Üben. Es ist ein 8 Bit Binärzähler welcher den aktuellen Wert einer 8 Bit Variable auf 8 LEDs ausgibt. Mit einem Poti und dem ADC kann man die Zählgeschwindigkeit einstellen. Und mit einem Taster kann man den Zähler anhalten und wieder starten(Ohne Interrupt). Mittlerweile habe ich die GPIOs den USART und den ADC in Betrieb nehmen können. Bei dem ADC wäre ich gestern fast verzweifelt weil er einfach nicht laufen wollte und die Anwendung ewig gehangen hat um auf das Ende der Messung zu warten. Bis ich dann irgendwann festgestellt habe, mit einem Beispielcode aus dem Internet das ich versehentlich den ADC1 versucht habe im AHB2ENR Register zu aktivieren anstatt im APB2ENR Register **kopfschüttel**. Danach funktionierte auch er. Ich habe auf YouTube ein Youtuber gefunden der mehrere Tutorials über den STM32 gemacht hat/macht ohne HAL auf Registerbasis. Ich verlinke ihn hier mal vielleicht gibt es ja irgendwann noch jemand der an meiner Stelle ist und eventuell sowas sucht. Die Videos sind auf Englisch. Er erklärt alles auch am Datenblatt was gesetzt werden muss und so weiter mit anschließen testen des Programms. https://www.youtube.com/channel/UCkdqtSMnhYuMsJkyHOxiPZQ Praktischerweise nutzt er auch das Nucleo-64 F446RE Board mit dem STM32F446RE wie ich. Zum Abschluss hätte ich nochmal eine Frage was den ADC und die Referenzspannung angeht: Der STM32F446RE hat ja internen Temperatursensor an ADC1 Kanal 18. Im Datenblatt ist beschrieben wie man in aktiviert und ausließt. Ich habe das versucht und das hat auch geklappt. Nur glaube ich das die Referenzspannung des ADCs zu hoch ist. Wenn ich in Auslese bekomme ich bei einer 12 Bit Auflösung ein Wert von um die 940. Wenn ich das bei 3,3V in eine Spannung umwandele bekomme ich etwa um die 0,757V(757mV). Laut Datenblatt liegt die Ausgegeben Spannung bei 25 °C bei 0,76V(760mV). Ich habe etwa 25,8°C in meiner Bude. Passt in etwa. Nur wenn ich den Chip kalt mache mit Kältespray auf -10°C dann ändert sich der ADC Wert schon auf 898. Wenn ich mein Finger draufhalte etwa auf 945. Und da der Sensor laut Datenblatt ja ein Slope von 25mV je Grad hat ändert sich die Spannung ja nur minimal pro Grad. Nur lässt sich das ganze kaum wirklich umrechnen da der Unterschied so gering ist. Ich konnte nix finden wie beim AVR das man den ADC bei 1,1V oder 2,56V Referenzspannung betrieben wird. Wenn ich das richtig verstanden habe ist VREF=VDDA? Also müsste ich um den Sensor auszulesen die Spannung extern ändern? Mfg
Ein extra Pin für AREF ist beim STM32 gehäuseabhängig. Kleine Gehäuse bieten meist nur AREF=VDDA, grössere Gehäuse haben einen Pin für AREF. Dazu brauchst du das technische Datenblatt deiner Chipausführung.
Matthias S. schrieb: > Dazu brauchst du das technische Datenblatt deiner Chipausführung. Im Pinout des Chips steht drin: Pin 12: VSSA/VREF- Pin 13: VDDA/VREF+ Also hat der STM32 kein intern erzeugte Referenzspannung wie beim AVR? Mfg
Felix N. schrieb: > Also hat der STM32 kein intern erzeugte Referenzspannung wie beim AVR? Doch manche haben einen Vrefint. Der ist aber nur an einen ADC Eingang schaltbar zum Nachmessen. (Durchaus etwas gewöhnungsbedürftig wenn man aus der AVR Ecke kommt) Siehe F446 RefMan Seite 356 Figure 69. Single ADC block diagram
Felix N. schrieb: > In der Zwischenzeit war ich auch nicht ganz untätig und habe mein erstes > kleines STM32 Programm auf Register Basis fertig gestellt, es ist zwar > nicht sonderlich nützlich aber es reicht zum Üben. Ich finde es gut, daß Du Dir die Register näher ansiehst. Zwar für einen anderen Controller (F3) aber doch sinnvolle Beispiele, wie man die Peripherie ansprechen kann: http://www.pomad.fr/node/17 Einfach mal durchblättern und inspirieren lassen.
Der Umstieg von AVR nach STM32 ist ja auch ein Umstieg nach Cortex-M. Deshalb sollte man sich auch mit der Cortex-M Architektur vertraut machen. Ein paar Sachen sind zumindest nicht ganz intuitiv, https://wiki.segger.com/Arm_Cortex-M_interrupts. Dazu gibt es viele gute Sachen im Netz, ich persönlich empfehle aber die Bücher von Joseph Yiu, "The definitive guide to arm cortex processors". Falls Interesse besteht könnte ich evtl. auch mal Abends so eine Mini Schulung per Discord oder ähnliches anbieten. Da könnte man sich über so ein paar Cortex-M Sachen unterhalten. Ist jetzt nur eine spontane Idee.
Til S. schrieb: > ich persönlich empfehle aber die > Bücher von Joseph Yiu, "The definitive guide to arm cortex processors". Ohne dieses Buch (am besten in Papierform) geht eigentlich garnichts ;-)
Til S. schrieb: > Deshalb sollte man sich auch mit der Cortex-M Architektur vertraut > machen. Guter Hinweis. Leider ist es für einen Anfänger schwer, die Grenzen zwischen Cortex-M und dem STM "Aufsatz" zu erkennen, insbesondere weil Cortex-M viele Details als "herstellerspezifisch" offen lässt bzw. mehrere Varianten anbietet. Zudem kann man sich nicht mit einem Cortex-M vertraut machen, ohne sich gleichzeitig mit den Eigenarten der ST Architektur auseinander setzen zu müssen. Das fiel zumindest mir anfangs schwer.
Mw E. schrieb: > Doch manche haben einen Vrefint. > Der ist aber nur an einen ADC Eingang schaltbar zum Nachmessen. Hallo, Ja das habe ich wohl im Datenblatt gesehen. Der ADC Kanal für VRefInt wird mit dem Temperatursensor aktiviert. Mw E. schrieb: > (Durchaus etwas gewöhnungsbedürftig wenn man aus der AVR Ecke kommt) Was genau muss ich darunter verstehen. Wenn ich die Interne Referenzspannung nur messen kann aber nicht wirklich verwenden wozu ist sie dann da? Kalibrierung des ADCs über Temperatur? Genauigkeit? m.n. schrieb: > Einfach mal durchblättern und inspirieren lassen. Werde ich mir anschauen. Danke! :) Til S. schrieb: > Der Umstieg von AVR nach STM32 ist ja auch ein Umstieg nach Cortex-M. Ich habe mir das alles deutlich schlimmer vorgestellt. Und habe lange Zeit bevor ich mir das Board geholt überlegt ob ich mich wirklich mit dem STM32 auseinander setzten will. Aber jetzt es geht eigentlich, dachte der Einstieg wäre eine einzige Katastrophe . Die C Programmierung ist und bleibt ja die gleiche. Klar die Register heißen anderes sind von den Bits breiter. Manchmal komisch Beschrieben im Datenblatt. Aber sonst, ging es bisher eigentlich. Und bisher habe ich im bei den AVR Chips nur I2C, SPI, ADC, USART, Interrupts, Timer sowie PWM genutzt. Das meiste habe ich jetzt schon auf dem STM32 ans laufen bekommen. Klar der STM32 hat natürlich noch vieles mehr als meine AVRs wie DMA, CAN, I2S etc... wenn ich es mal brauche ist es auf jeden fall da. Til S. schrieb: > Dazu gibt es viele gute Sachen im Netz, ich persönlich empfehle aber die > Bücher von Joseph Yiu, "The definitive guide to arm cortex processors" Ah ok. Schaue ich mir mal an ob das was für mich ist. Stefan ⛄ F. schrieb: > Leider ist es für einen Anfänger schwer, die Grenzen zwischen Cortex-M > und dem STM "Aufsatz" zu erkennen, insbesondere weil Cortex-M viele > Details als "herstellerspezifisch" offen lässt bzw. mehrere Varianten > anbietet. Ich frag jetzt einfach mal so doof. Cortex M4 ist doch nur der Prozessor des Mikrocontrollers oder? Alles anderes kann man doch als Peripherie bezeichnen oder nicht? Also ganz grob gesagt Cortex M4 kommt von ARM der Reset ist ST? Weiß jemand zufällig wo man solche ST Controller beziehen kann? Der STM32F446RE welcher ja jetzt auch auf den Nuleco-64 Board verbaut ist, ist weder bei reichelt noch conrad erhältlich. Wenn ich mal irgendwann ein Projekt mit einem STM32 uC mache wäre das dann meine erste Wahl da ich dann mit dem schon erste Erfahrungen habe. Mfg
Felix N. schrieb: > Cortex M4 ist doch nur der Prozessor > des Mikrocontrollers oder? Ich denke, dazu gehört auch der Interrupt-Controller und die Debugging Einheit. > Also ganz grob gesagt Cortex M4 kommt von ARM der Reset ist ST? Bei USB ist mir aufgefallen, dass ST diesen Block wiederum von einer anderen Firma dazu gekauft hat. Es würde mich nicht wundern, wenn der ganze Chip aus Blöcken anderer Hersteller zusammen gestoppelt ist. So wirkt er nämlich auf mich, egal auf welche konkrete L oder F-Serie man da nun schaut. > Weiß jemand zufällig wo man solche ST Controller beziehen kann? Fast alle Modelle sind seit Monaten überall ausverkauft. Zur Zeit hat man gar nicht die Freiheit, den am besten passenden Controller zu wählen, sondern man muss nehmen was man kriegen kann - koste er was er wolle.
Felix N. schrieb: > Als IDE verwende ich die von ST zur Verfügung gestellte STM32CubeMX IDE. > Die graphische Konfigurationsoberfläche ist ganz nett, aber auf Dauer > könnte ich mich damit glaubig nicht anfreunden. Das mich die Software > dann zwingt in vorgegeben Bereichen mein Code zuschreiben, naja ist > nicht so meins. Muss man nicht machen ... STM32CubeMX ist ganz nett, um ein Framework zu erzeugen, aber dann muss man sich nicht an die Bereiche halten, wenn man nicht vor hat, peripherietechnisch etwas zu ändern und das Framework neu über das bestehende zu erzeugen. Ich lösch den kram immer alles raus. Mittlerweile hab ich mich halbwegs mit HAL angefreundet, weil ich eher Pragmatiker als Idealist bin und es naja schon funktioniert. Als IDE benutze ich aber die IDE von STMicro nicht mehr - bzw hab ich noch nie. Erst lange Zeit Eclipse mit GnuARM-Plugin (Die IDE von STMicro ist quasi das gleiche), jetzt einfach Visual Studio Code. Bei beidem funktionierte Debuggen wunderbar, vscode erscheint mir aber schlanker.
:
Bearbeitet durch User
Felix N. schrieb: > Weiß jemand zufällig wo man solche ST Controller beziehen kann? Der > STM32F446RE welcher ja jetzt auch auf den Nuleco-64 Board verbaut ist, > ist weder bei reichelt noch conrad erhältlich. Wie Stefan F. bereits geschrieben hat ist die Verfügbarkeit der STM32 aktuell eine "Herausforderung", prinzipiell gibt es aber die Kekse (auch für Privatpersonen und in Kleinmengen) z.B. bei Digikey oder Mouser: https://www.digikey.de/ https://www.mouser.de/ Gruß, Michael
Bei tme.eu bekommt man die z.B. auch. Es gibt soviel Varianten der STM32 da wird man eher bei den Distributoren fündig. Einige ‚Standardtypen‘ wie F407 findet man auch bei AliExpress.
Michael F. schrieb: > prinzipiell gibt es aber die Kekse Es sind nur noch Krümel ;-) @TO Wenn Du beim F446 bleiben möchtest, ist es derzeit geschickt, ein komplettes Nucleo-Board zu verwenden. Die sind noch verfügbar und auch für Grobmotoriker gut zu bestücken. Notfalls lötet man sich den Chip herunter. Ansonsten gibt es so viele andere Controller von ganz klein und schnell (STM32G431, TQFP32, 170 MHz, FPU) und ganz groß und ganz schnell (H7xx, 550 MHz, DFPU), daß Du je nach Anwendung eine bessere Auswahl treffen solltest. Für mich wäre der F446 im TQFP64 weder Baum noch Borke. Johannes S. schrieb: > Einige ‚Standardtypen‘ > wie F407 findet man auch bei AliExpress. Oder auch hier: https://lcsc.com/products/ST-Microelectronics_474.html?q=stm32f407 zu einem völlig überzogenem Preis.
Felix N. schrieb: > Ich frag jetzt einfach mal so doof. Cortex M4 ist doch nur der Prozessor > des Mikrocontrollers oder? Alles anderes kann man doch als Peripherie > bezeichnen oder nicht? Also ganz grob gesagt Cortex M4 kommt von ARM der > Reset ist ST? Im Prinzip ja. Der gesamte Core inkl. Interrupt Controller, FPU, MPU, Debug Logik, etc. kommt von ARM und die Chiphersteller packen dann ihre Peripherie und Speicher dazu. Jetzt sind noch viele Core Features "implementation defined", d.h. ein paar Eigenschaften kann der Chiphersteller noch konfigurieren, z.B. ob eine FPU drin ist oder nicht. Aber natürlich keine Regel ohne Ausnahme. Es gibt dann doch wieder Device bei denen z.B. nicht die ARM MPU implementiert ist sondern der Chiphersteller stattdessen was eigenes reinpackt (wieso auch immer). So zum Beispiel beim NXP K66. Bei ARM7/ARM9 war es noch so das der Interrupt Controller nicht von ARM kam und jeder Chiphersteller sich was eigenes ausdenken musste. Aus z.B. RTOS Sicht ist Cortex-M super weil ein RTOS Core und Compiler spezifisch ist. D.h. wenn man ein RTOS für Cortex-M hat läuft das im Prinzip auf jedem Cortex-M unabhängig vom Chiphersteller.
Stefan ⛄ F. schrieb: > Bei USB ist mir aufgefallen, dass ST diesen Block wiederum von einer > anderen Firma dazu gekauft hat. Es würde mich nicht wundern, wenn der > ganze Chip aus Blöcken anderer Hersteller zusammen gestoppelt ist. So > wirkt er nämlich auf mich, egal auf welche konkrete L oder F-Serie man > da nun schaut. Da ist so ziemlich alles verbastelt. Da sind ganz viele Synopsis IPs drin (USB etc.) Der CAN FD Kern bei den großen STMs ist ein Bosch M_CAN usw. Das ist absolut gängige Praxis bei jedem Hersteller. Felix N. schrieb: > Was genau muss ich darunter verstehen. Wenn ich die Interne > Referenzspannung nur messen kann aber nicht wirklich verwenden wozu ist > sie dann da? Kalibrierung des ADCs über Temperatur? Genauigkeit? Du kannst die interne Referenz messen und dadurch rückrechnen, wie groß deine VREF des ADCs ist. Damit kannst du dann wieder deine anderen Kanäle nachrechnen. Die interne Referenz des STMs ist aber nicht so der Burner. Bzw. der ADC ist eigentlich ziemlich gut, wird aber durch die Referenz recht stark verhunzt. Wenn man eine gute externe Referenz nutzt (vorausgesetzt, der VREF-Pin ist vorhanden), dann lassen sich sehr gute Ergebnisse und auch Rausch-Performance mit dem ADC erreichen.
Anfangen mit STM32? Ich habe mir das nackteste Breakoutboard mit STM32 geholt, einen ST-Link Programmer und dann habe ich mit Datenblatt und GNU Toolchain losgelegt. Da ist doch nichts dabei.
Cyblord -. schrieb: > Anfangen mit STM32? Ich habe mir das nackteste Breakoutboard mit STM32 > geholt,... Ja, so geht es. Immerhin heißt die Überschrift "Anfang mit STM32" und nicht "Mit welcher IDE spielt es sich am schönsten". Mir geht es regelmäßig gegen den Strich, wenn ich hier so etwas ähnliches lesen muß wie "Ich will mit µC annfangen, welche IDE muß ich mir herunterladen?" - die Leute behaupten, sich mit einem µC befassen zu wollen und meinen, sich zuvörderst mit einem PC-Programm befassen zu wollen. W.S.
W.S. schrieb: > die Leute behaupten, sich mit einem µC befassen zu > wollen und meinen, sich zuvörderst mit einem PC-Programm befassen zu > wollen. Und wenn sie dann man ein Build Script benutzen sollen, fangen sie schon an zu meckern.
Allerdings kann man für STM32 auch einfach STM32 Workbench nutzen. Da hat man Eclipse, GNU Tools und trotzdem ist alles schon eingerichtet. StdPeriph und HAL lädt das Ding bei Bedarf auch gleich. Diese Hürde ist wirklich nicht hoch. Das Problem ist nicht der STM32 sondern die Leute die schon mit AVR und PIC niemals richtig angefangen haben. Die nur mit BASCOM oder Arduino konditioniert sind jetzt plötzlich auf STM32 umsteigen wollen. Da fehlt diese Vorgehensweise völlig. Eigentlich müssten die mit einem AVR nochmal ganz von vorne anfangen.
:
Bearbeitet durch User
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.