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?
Angehängte Dateien:
-
cubeideproject.PNG
9,9 KB
>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?
Angehängte Dateien:
-
libraries.png
150 KB
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:
1 | Quelle Ziel |
2 | CMSIS/Include ProjectFolder/CMSIS/core |
3 | CMSIS/Device/ST/STM32Fxxx/Include ProjectFolder/CMSIS/device |
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.
Ich habe jetzt noch Nummern ins Bild gemalt, damit die Reihenfolge der Bedienung klar ist. Zufrieden?
> 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.
Angehängte Dateien:
-
IDE.png
240 KB
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.
Stefan F. schrieb: > Kann man durchaus machen, ist allerdings deutlich mühsamer. Unsinn, das snd 10 Klicks.
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
Danke, schaue ich mir an. Mir war deine Seite schon vorher einige Male aufgefallen und auch ein Grund mich endlich mal mit den STM32 zu beschäftigen.
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.