Guten Tag,
ich verfolge gerade ein Tutorial, welches das programmieren der STM32
mit der CMSIS erklärt.
Dort wird beschrieben, wie ich ein Projekt erstellen kann:
http://stefanfrings.de/stm32/cube_ide.html
Leider existieren die Verzeichnisse
ProjectFolder/CMSIS/core
ProjectFolder/CMSIS/device
bei mir nicht (wie man auch dem Screenshot entnehmen kann).
Ich habe über File->New->Other->ST->STM32 das Arbeitsprojekt erstellt,
die MCU ausgewählt (ich musste einen auswählen, weil ich sonst nicht auf
Next clicken konnte) und als "Target Project Type" "Empty" angegeben.
Was mache ich falsch?
>Ich habe über File->New->Other->ST->STM32 das Arbeitsprojekt erstellt,>die MCU ausgewählt (ich musste einen auswählen, weil ich sonst nicht auf>Next clicken konnte) und als "Target Project Type" "Empty" angegeben.>Was mache ich falsch?
Falls das alles ist was du bis hier hin gemacht hast, ist deine
Aufmerksamkeitsspanne der Knackpunkt, lese erstmal das Tutorial zu Ende:
Du musst die CMSIS-Bibliothek selbst hinzufügen, so wie es im Tutorial
weiter unten sehr sehr seeeehr ausführlich beschrieben wird.
> ist deine Aufmerksamkeitsspanne der Knackpunkt
Aha, interessant. Vielleicht war meine Frage auch nicht klar genug
gestellt, dass sie für jeden verständlich ist.
Wo ist dort beschrieben, dass die Ordner selbst hinzugefügt werden
sollen und nicht auto-generiert werden? Zumal die HAL Library darauf
aufbaut? Im Tutorial ist kein Datum angegeben und auch keine
Versionsnummer. Vielleicht ändert sich Software mit der Zeit? Immerhin
wurde der Schritt auch nicht erwähnt, in der die MCU ausgewählt werden
muss (soviel zu deinem sehr ausführlich - füg noch ein paar "e"s hinzu.
Lässt dich schlauer aussehen)? Muss man echt so degeneriert auf eine
einfache Frage antworten?
Quaser schrieb:> Wo ist dort beschrieben, dass die Ordner selbst hinzugefügt werden> sollen und nicht auto-generiert werden?
Lege mit dem Assistenten der IDE (File/New/Other.../ST/STM32 Project)
ein Arbeitsprojekt mit dem "Target Project Type" "Empty" an.
Kopiere aus dem CMSIS Paket für alle STM32 die folgenden Verzeichnisse
in dein Projekt:
In der Datei stm32f3xx.h (oder so ähnlich) sollst du unter dem Kommentar
"Uncomment the line below according to the target STM32 device" die zu
deinem Mikrocontroller passende Zeile aktivieren.
Füge die beiden CMSIS Verzeichnisse zur Projektkonfiguration hinzu:
* Gehe im Project Menü auf Properties.
* Gehe nach C/C++ Build Settings Tool Settings / MCU GCC Compiler
/ Include paths
Kann man das wirklich übersehen, nachdem man den ersten Satz bereits
gefunden und nachvollzogen hat?
Quaser schrieb:> Zumal die HAL Library darauf aufbaut?
Du hast ja ein "Empty" Projekt erstellt, also ohne Bibliotheken. Ein
Projekt nur mit CMSIS kann die IDE halt nicht erstellen. ST will mit der
IDE die HAL bewerben.
> Vielleicht ändert sich Software mit der Zeit?
Das tut sie, auch das habe ich auf der selben Webseite deutlich
geschrieben. Wenn du etwas stabiles willst, wo sich die Details nicht
alle paar Monate ändern, dann verwende die System Workbench for STM32.
Wenn man das neueste vom neuesten benutzt, muss man damit rechnen, dass
die meisten Anleitungen nicht 100% passen. Gerade bei der Cube IDE ist
das ein Thema. Diese Anleitung habe ich seit der ersten Erstellung
mehrfach ändern müssen.
> Immerhin wurde der Schritt auch nicht erwähnt, in der die MCU> ausgewählt werden muss
Ja mei, das ergibt sich von selbst, weil man sonst in dem Assistenten
nicht weiter kommt. Vor dem Pinkeln solltest du auch die Klobrille hoch
klappen. Das muss man auch nicht auf ein Schild schreiben, oder doch?
> Muss man echt so degeneriert auf eine einfache Frage antworten?
Das ist der übliche Tonfall hier. Wer Schwächen offenbart macht sich
selbst zum Opfer. Das ist fies, aber so ist es hier halt.
Nur um alle möglichen Missverständnisse zu vermeiden:
"CMSIS Paket für alle STM32" ist auf der Webseite ein Link auf eine ZIP
Datei. Da sind die Dateien ("Quelle") drin, die du kopieren musst.
> Muss man echt so degeneriert auf eine> einfache Frage antworten?
Das hast du wohl in den falschen Hals bekommen >:) In meiner Antwort
waren doch alle für deine Fragestellung relevanten Informationen
enthalten.
Was haltet ihr von der entgegengesetzten Richtung?
Ein normales CubeIDE HAL Projekt erzeugen und daraus alles was HAL ist
entfernen, auch die .ioc.
Eine neue main.c und main.h erstellen ohne HAL irgendwie zu nutzen.
Klingt nach viel Arbeit, ist es aber nicht.
Hat den Vorteil das alles einschliesslich Debug funktioniert.
Das als Vorlage Projekt speichern und einfach immer wieder kopieren.
pegel schrieb:> Was haltet ihr von der entgegengesetzten Richtung?>> Ein normales CubeIDE HAL Projekt erzeugen und daraus alles was HAL ist> entfernen, auch die .ioc.>> Eine neue main.c und main.h erstellen ohne HAL irgendwie zu nutzen.>> Klingt nach viel Arbeit, ist es aber nicht.> Hat den Vorteil das alles einschliesslich Debug funktioniert.>> Das als Vorlage Projekt speichern und einfach immer wieder kopieren.
Habe ich auch gemacht. Habe ein altes F103 CooCox Projekt von mir mit
SPL V3.5.0 in TS importiert und kompiliert und läuft ohne HAL wie es
soll. HAL ist nicht unumgänglich notwendig.
pegel schrieb:> Was haltet ihr von der entgegengesetzten Richtung?> Ein normales CubeIDE HAL Projekt erzeugen und daraus alles was HAL ist> entfernen, auch die .ioc.
Kann man durchaus machen, ist allerdings deutlich mühsamer.
> Das als Vorlage Projekt speichern und einfach immer wieder kopieren.
Gute Idee.
Hänge meine Frage gleich mal hier an:
Beschäftige mich erst seit einigen Tagen mit dem STM32 (konkret mit dem
F303RET6 Nucleo Board).
Ist der HAL als Ebene dazwischen wirklich so gruslig?
Ich fand den Lernfortschritt recht angenehm, habe in den Tagen mit GPIO,
ADC, einem Timer, einem Timer-Interrupt und dem UART über den virtuellen
COM-Port experimentiert und kam recht gut voran. Und ich fand es
zumindest in der Phase recht angenehm noch nicht gleich jeden
Registereintrag per Hand überlegen und vornehmen zu müssen.
Bläht der HAL den Speicherbedarf unnötig auf und/oder verlangsamt er die
Verarbeitung ohne dass der Compiler vieles davon im Vorfeld erledigen
kann?
Danke für eure Tips.
Wenn es überhaupt 10 Klicks sind. Ich spiele es mal durch. Wir nehmen
mal an, wir haben gerade ein neues STM32CubeMX Projekt angelegt für den
STM32F407VGT6.
1. Code in der .io Datei erzeugen (Generate Code).
2. .io Datei löschen
3. Folgende Dateien löschen: main.h, stm32f4xx_hal_conf.h,
stm32f4xx_hal_msp.c, system_stm32f4xx.c
4. HAL Ordner löschen
5. Überall "#include "main.h"" entfernen (Übersetzen zeigt die include
Orte als Fehler an)
6. "HAL_IncTick();" aus "SysTick_Handler" entfernen. Übersetzen zeigt
den Ort als Fehler an.
7. Aus der .s-Startup Datei "bl SystemInit" entfernen.
8. "USE_HAL_DRIVER" auf den Settings (Preprocessor) entfernen.
9. HAL Include Path entfernen.
Thats it.
Lutz S. schrieb:> Bläht der HAL den Speicherbedarf unnötig auf und/oder verlangsamt er die> Verarbeitung ohne dass der Compiler vieles davon im Vorfeld erledigen> kann?
Der HAL verhindert, dass du den Controller wirklich durchdringst und
ggf. mal auf ein Problem stößt, welches sich auf Registerebene wirklich
gut individuell lösen lässt, im HAL jedoch nicht möglich oder
ersichtlich ist.
Zusätzlich hat der HAL genau wie jede andere Software auch Fehler.
Lutz S. schrieb:> Ist der HAL als Ebene dazwischen wirklich so gruslig?
Meine ersten zwei Projekte mit zwei unterschiedlichen STM32 Modellen
scheiterten an Bugs in der HAL. Und der erste Eindruck zählt. Ich habe
meinen Knacks weg.
Dennoch habe ich in dem Jahr danach noch mehrmals die HAL verwendet, und
bin prompt auf zwei weitere Bugs gestoßen. Dank der Hilfe hier im Netz
wurden die Fehler gefunden und korrigiert. Doch ich fühle mich wohler,
wenn ich meine Programme ohne fremde Hilfe durchschaue.
Wegen der Erlebnisse mit den Bugs ist die HAL für mich unattraktiv.
Das Einzige, weswegen ich sie noch verwenden würde wäre der USB Treiber,
allerdings hat da das Forenmitglied W.S eine wesentlich kompaktere und
durchschaubare Lösung veröffentlicht, mit der ich sehr gut zurecht
komme.
Deswegen ist die HAL für mich vollkommen uninteressant geworden.
> ich fand es zumindest in der Phase recht angenehm noch nicht gleich> jeden Registereintrag per Hand überlegen und vornehmen zu müssen.
Genau das würde ich vermissen.
Lutz S. schrieb:> Bläht der HAL den Speicherbedarf unnötig auf und/oder verlangsamt er die> Verarbeitung ohne dass der Compiler vieles davon im Vorfeld erledigen> kann?
Kommt drauf an. Wenn du die HAL nur zur einmaligen Initialisierung der
Peripherie verendest und genug Speicher frei hast, kann Dir das
Aufblähen egal sein. Auf jeden Fall ist es nicht so schlimm, die
digitalWrite() von Arduino.
"Ein Hello World!" auf der USB-CDC Schnittstelle eines STM32F3 kostet
mit HAL 20 kB Flash und 5 kB RAM. Mit dem USB treiber von W.S sind es
nur 5,2 kB Flash und 600 Bytes RAM.
Falls du dir das anschauen möchtest:
http://stefanfrings.de/stm32/stm32f3.html#usb
cubeideproject.PNG
(9,9 KB)
