Hallo zuammen, ich habe soeben zum ersten Mal mit CubeIDE eine Konfiguration für ein Projekt auf dem STM32F103RB(nucleo) erstellt. In "CubeMX" konfiguriert habe ich zunächst mal: RCC intern 1x SPI 1x USART 3 LED Output Pins, mit den User Namen "LED1","LED2" und "LED3" Alles soweit so gut. Nun möchte ich einfach mal die LED's anschalten. Soweit ich das verstanden habe, müsste ja der Code dafür in der main.c in den Block USER3 (while-Loop innerhalb der main-Funktion) eingefügt werden...oder ? Aber wie setze ich da den Output Pin der LED1 auf High ? z.B. LED1_Pin = 1; funktioniert nicht. Gibt ne Fehlermeldung beim Build: ../Core/Src/main.c:103:13: error: lvalue required as left operand of assignment Soweit ich das in der main.h sehen kann, wurden die drei Pins aber entsprechend benannt: /* Private defines -----------------------------------------------------------*/ #define LED1_Pin GPIO_PIN_1 #define LED1_GPIO_Port GPIOC #define LED2_Pin GPIO_PIN_2 #define LED2_GPIO_Port GPIOC #define LED3_Pin GPIO_PIN_3 #define LED3_GPIO_Port GPIOC Ansonsten finde ich noch ne Menge verschachtelter "stm32f1xx_hal" Header Files, die diverse typedefs oder defines enthalten....da komme ich aber nicht so recht weiter.... Kann mir da jemand weiterhelfen ?
1 | // LED On
|
2 | HAL_GPIO_WritePin(LED1_GPIO_Port,LED1_Pin,GPIO_PIN_SET); |
3 | HAL_Delay(500); |
4 | |
5 | // LED Off
|
6 | HAL_GPIO_WritePin(LED1_GPIO_Port,LED1_Pin,GPIO_PIN_RESET); |
7 | HAL_Delay(500); |
Es gibt dazu eine Doku, die du lesen solltest. In Kapitel 20 werden die GPIO Funktionen beschrieben. https://www.st.com/resource/en/user_manual/dm00154093-description-of-stm32f1-hal-and-lowlayer-drivers-stmicroelectronics.pdf Aber vorher solltest du das Reference Manual des Mikrocontrollers lesen, das ist nämlich die Grundlage dafür. Sonst verstehst du nur Bahnhof. https://www.st.com/resource/en/reference_manual/CD00171190-.pdf Das ist eine Menge Lesestoff. Wir sehen uns in 6 Monaten wieder 😀 > LED1_Pin = 1; Das ist kein gültiges C. kann es sein, dass du die Programmiersprache auch noch lernen musst? Falls ja, dann mache das am Besten ohne Mikrocontroller auf einem PC mit Tastatur, Bildschirm und Debugger (z.B. mit der Qt Creator IDE).
Stefan ⛄ F. schrieb: >> LED1_Pin = 1; > > Das ist kein gültiges C. Doch. Aber es ist "Arduinisch"-C.
aduinist schrieb: >>> LED1_Pin = 1; >> >> Das ist kein gültiges C. > > Doch. Aber es ist "Arduinisch"-C. nein, eher Mbed :) Arduino ist bei gpio prozedural und hat erst den modernen Kram wie SPI oder I2C als Klasse eingebaut.
Stefan ⛄ F. schrieb: >> LED1_Pin = 1; > > Das ist kein gültiges C. Doch, das ist grundsätzlich eine völlig korrekte Anweisung in C und C-artigen Programmiersprachen. Wäre LED1_Pin eine normale Variable, gäbe es auch kein Problem. Bei dem STM32CubeMX-Kram ist es jedoch eine Konstante. Und natürlich wäre es auch möglich, LED1_Pin als Makro zu definieren, so wie in vielen anderen Ökosystemen üblich, z.B. als
1 | #define LED1_Pin *((uint32_t *)0x12345678UL)
|
In in C++ könnte man die Peripheriezugriffe ggf. auch in überladenen Operatoren verstecken.
Andreas S. schrieb: > Und natürlich wäre es auch möglich, LED1_Pin als Makro zu definieren, so > wie in vielen anderen Ökosystemen üblich CubeMX erzeugt Makros. Auschnitt aus einer main.h:
1 | /* Private defines -----------------------------------------------------------*/ |
2 | #define D_SDA_Pin GPIO_PIN_1 |
3 | #define D_SDA_GPIO_Port GPIOC |
4 | #define D_BLK_Pin GPIO_PIN_2 |
5 | #define D_BLK_GPIO_Port GPIOA |
:
Bearbeitet durch User
Andreas S. schrieb: > Doch, das ist grundsätzlich eine völlig korrekte Anweisung in C und > C-artigen Programmiersprachen. Wäre LED1_Pin eine normale Variable, gäbe > es auch kein Problem. LED1_Pin ist aber eine Zahl. Man kann einer Zahl nichts zuweisen.
Danke für die Rückmeldungen. Doch doch, ich habe durchaus schon ein bisschen mit C programmiert, bin aber noch lange nicht routiniert unterwegs oder gar allumfassend ausgebildet... Stefan ⛄ F. schrieb: > Das ist eine Menge Lesestoff. Wir sehen uns in 6 Monaten wieder 😀 Ja, genau....! ;o)))) Stefan ⛄ F. schrieb: > Aber vorher solltest du das Reference Manual des Mikrocontrollers lesen, > das ist nämlich die Grundlage dafür. Sonst verstehst du nur Bahnhof. Bin über einen guten Onlinekurs grundsätzlich schon ein bisschen vertraut mit dem Coden von Drivern und APIs auf Basis des Reference Manuals... Bin nur durch die ganzen "verschachtelten" Header-Files mit all den Makros, typedefs etc. nicht mehr ganz durchgestiegen, wie ich den Pin denn nun ansprechen kann...und auch HAL-Treiber hab ich noch nicht geschrieben... Stefan ⛄ F. schrieb: > // LED On > HAL_GPIO_WritePin(LED1_GPIO_Port,LED1_Pin,GPIO_PIN_SET); > HAL_Delay(500); > // LED Off > HAL_GPIO_WritePin(LED1_GPIO_Port,LED1_Pin,GPIO_PIN_RESET); > HAL_Delay(500); Aber damit komme ich jetzt schon gut weiter ! Danke !
Nach 6 Monaten Referenzmanual, ARM-Referenz, usw. kannst du dann noch weitere 6 Monate fuer die HAL-Doku einplanen.
Genau deswegen verzichte ich lieber auf die HAL. Das Thema "wiederverwendbarer Code" ist für mich irrelevant, insbesondere wenn dies bedeutet, dass ich mich mit ST verheiraten muss.
Stefan ⛄ F. schrieb: > Genau deswegen verzichte ich lieber auf die HAL. Das Thema > "wiederverwendbarer Code" ist für mich irrelevant, insbesondere wenn > dies bedeutet, dass ich mich mit ST verheiraten muss. Ja....so langsam verstehe ich, was Du meinst....das ganze Cube-Ding macht es dann doch nicht wirklich übersichtlicher oder einfacher....;-/ Dennoch kurz ne Anschlussfrage.... Ich versuche, über den UART MIDI Daten zu senden. Wenn ich das eben im Moment auch wieder über HAL mache, muss ich ja entsprechend HAL_UART_Transmit() verwenden. In einem Probebeispiel mit char message[30]= "Hello from CubeMX\r\n"; // im Konfigurationsblock und HAL_UART_Transmit(&huart1,(uint8_t*)message,30,100); // in main() vor der while-Schleife funktioniert das wunderbar (kann ich auch an TX mit meinem Logic Analyzer entsprechend auslesen). Jetzt möchte ich aber ja keinen String in Form eines char-Arrays mehr senden sondern die drei Bytes Daten für MIDI (Statusbyte, Datenbyte1, Datenbyte2).... Wenn ich aber nun statt des char message[30] Arrays die drei uint8_t Variablen uint8_t status = 0x91; uint8_t data1 = 0x45; uint8_t data2 = 0x7f; definiere, und diese dann entsprechend versenden möchte mit HAL_UART_Transmit(&huart1,(uint8_t*)status,4,10); HAL_UART_Transmit(&huart1,(uint8_t*)data1,4,10); HAL_UART_Transmit(&huart1,(uint8_t*)data2,4,10); (die Werte 4 für Size und 10 für Timeout habe ich mal willkürlich so gewählt) bekomme ich vom Compiler Fehlermeldungen wie: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] Jetzt habe ich alles mögliche im Kreis ausprobiert, um den Compiler "zufriedenzustellen".....;-) Aber ich komme nicht auf den Fehler... Please help !!! ;-) Und noch ganz allgmein gefragt: Wenn ich diesen MIDI-Dreierpack an Bytes senden möchte, ist da mein Ansatz mit den drei getrennten Zeilen richtig ? Oder wie geht das kompakter? Mir ist noch nicht klar, ob ich in der MIDI Spezifikation bestimmte Timeout-Abstände zwischen den einzelnen Bytes halten muss, und wenn ja, wie groß die sein müssten....
Uli A. schrieb: > char message[30]= "Hello from CubeMX\r\n"; // im Konfigurationsblock > > und > > HAL_UART_Transmit(&huart1,(uint8_t*)message,30,100); Das ist schon mal Käse, so lange du Text übertragen willst. So wäre es korrekt:
1 | HAL_UART_Transmit(&huart1,(uint8_t*)message,strlen(messge),100); |
Uli A. schrieb: > Wenn ich aber nun statt des char message[30] Arrays die drei uint8_t > Variablen > > uint8_t status = 0x91; > uint8_t data1 = 0x45; > uint8_t data2 = 0x7f; Das ist kein Array, sondern das sind 3 unabhängige Variablen. Das wäre ein Array:
1 | uint8_t data[3]; |
So ein Array kannst du dann auch am Stück versenden:
1 | HAL_UART_Transmit(&huart1, &data, sizeof(data), 100); |
Für deine 3-Byte-Message würde sich allerdings eher eine Structur anbieten. z.B. so:
1 | struct message {
|
2 | uint8_t status; |
3 | uint8_t data[2]; |
4 | }; |
:
Bearbeitet durch User
Harry L. schrieb: > Das ist kein Array, sondern das sind 3 unabhängige Variablen. Genau. Hatte ich ja auch geschrieben....;-) Uli A. schrieb: > statt des char message[30] Arrays die drei uint8_t > Variablen > > uint8_t status = 0x91; > uint8_t data1 = 0x45; > uint8_t data2 = 0x7f; Aber davon abgesehen.....danke für Deine Erklärungen mit den Arrays, aber die eigentlichen Fragen hast Du damit nicht berührt....;-)
Uli A. schrieb: > Ja....so langsam verstehe ich, was Du meinst....das ganze Cube-Ding > macht es dann doch nicht wirklich übersichtlicher oder einfacher....;-/ Zumindest die Konfiguration der Taktversorgung wird durch CubeMx erheblich vereinfacht. Aber wenn man den Dreh einmal heraus hat, ist es in neuen Projekten nur noch ein bisschen Copy-Paste und ggf. Anpassung. Und dann gibt es da noch größere Anteile, zum Beispiel die USB Codes. Die schreibt keiner mal eben schnell neu. Dennoch ist es mir im Rahmen meines Hobbies lieber, auf die HAL zu verzichten. Für mich ist das undurchschaubarer Code der übrigens auch einige male fehlerhaft war. Ohne Fremde Hilfe (aus diesem Forum) hätte ich die Fehler wahrscheinlich nie finden und beheben können. Ich verstehe aber warum die das so strukturiert haben. Für jeden µC wird nur genau der Teil ausgetauscht, der nötig ist. Es geht um maximale Wiederverwendbarkeit von Code. Man bezahlt mit Bedarf an schnelleren und größeren Mikrocontrollern und einer starken Bindung an die Marke. Das ist nicht unbedingt schlimm, wenn man weiß, worauf man sich einlässt.
Danke Stefan für Deine Ausführungen...klar, das war natürlich auch mein Beweggrund als Anfänger, mich für CubeIDE zu entscheiden - es ist verlockend, eine vollintegrierte Arbeitsumgebung zu haben, und beim anfänglichen Beschäftigen mit dem Thema erschien mir die schier unübersichtliche Zahl an Arbeitsschritten alleine bei der Konfiguration der IDEs und der Compiler - also BEVOR man überhaupt anfangen kann zu arbeiten ;-) - als echter Abtörner....und dennoch wollte ich ja für mein Projekt von Arduino weg zu einer etwas "professionelleren" Herangehensweise und Plattform. Ich denke nach meinen Einblicken der letzten Monate schon noch, dass STM32 insgesamt ein gutes System für meine Art von Anwendungen liefert. Aber man muss natürlich immer auch bestimmte spezifische Schwachstellen kennen- und einschätzen lernen...das ist ja auch bei jeder anderen Hard- und Software so....und da bin ich gerade angekommen... Nebenbei gefragt: Was ist denn Deine aktuelle Entwicklungsumgebung, die Dich gut und effizient arbeiten lässt, ohne eine "Bindung an die Marke" ST ? Und nochmal kurz zum Thema....könnest Du mir vielleicht noch mal zu meiner UART/MIDI Übertragungsfrage weiterhelfen ? Ein einfaches Beispiel für die Übertragung eines "MIDI-Blocks" über den UART mit HAL_UART_Transmit() würde mir schon reichen...;-) LG
Uli A. schrieb: > Was ist denn Deine aktuelle Entwicklungsumgebung, die > Dich gut und effizient arbeiten lässt, ohne eine "Bindung an die Marke" > ST ? Ich benutze die Cube IDE, weil sie kostenlos ist. Davor hatte ich die "System Workbench for STM32" verwendet, als es die Cube IDE noch nicht gab. Die ersten Versionen der Cube IDE konnten noch keine Projekte ohne HAL erzeugen, das ist aber inzwischen möglich. Beide IDE's binden mich an ST. Dafür ist da aber alles drin was man braucht. Ich habe einmal versucht mein heiß geliebtes Qt Creator zu benutzen, bin da aber am Debugger gescheitert. Letztendlich ist die IDE nur ein Werkzeug. Für andere Controller benutze ich andere IDE. Die Idee "eine IDE für alles" ist sowieso langfristig nicht haltbar. > Und nochmal kurz zum Thema....könnest Du mir vielleicht noch mal zu > meiner UART/MIDI Übertragungsfrage weiterhelfen ? Nein, das ist nicht mein Fachbereich. > Ein einfaches Beispiel ... mit HAL_UART_Transmit() Das erst recht nicht. Ich habe die Hal nur für einen LED Blinker und ein "Hello World!" über USB benutzt. Also nur ganz kurze Anfänger-Experimente. Und dann habe ich beschlossen, sie nicht mehr zu verwenden.
Stefan ⛄ F. schrieb: > Die ersten Versionen der Cube IDE konnten noch > keine Projekte ohne HAL erzeugen, das ist aber inzwischen möglich. Interessant.....wie kann ich das einstellen ?
>> Die ersten Versionen der Cube IDE konnten noch >> keine Projekte ohne HAL erzeugen, das ist aber inzwischen möglich. Uli A. schrieb: > Interessant.....wie kann ich das einstellen ? http://stefanfrings.de/stm32/cube_ide.html#projekt
Ok. Hab mir das mal genauer angeschaut....cool...ist ja quasi "Hal light"...;-)
Bedenke dass die CMSIS header für alle ARM Controller existieren, aber die Makros SET_BIT(), CLEAR_BIT(), usw. hat ST hinzugefügt. Man kann sie vermutlich für andere Controller ggf. kopieren.
Stefan ⛄ F. schrieb: > Bedenke dass die CMSIS header für alle ARM Controller existieren, > aber > die Makros SET_BIT(), CLEAR_BIT(), usw. hat ST hinzugefügt. Man kann sie > vermutlich für andere Controller ggf. kopieren. Danke für den Hinweis. Muss mich da jetzt mal ganz neu orientieren bzw. entscheiden, wie ich grundsätzlich weiter vorgehe...aber immerhin gibt es ja direkt von ST ne recht gute Anleitung für CMSIS inklusive Anwendungsbeispielen....falls noch jemand daran interessiert ist, hier der Link: https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32-standard-peripheral-libraries/stsw-stm32062.html#documentation Ist zwar für F2xx ausgeschrieben, aber das Prinzip wird natürlich deutlich. Seltsamerweise gibt es das Dokument nicht ausdrücklich genauso für die F1 und F4's....da muss man natürlich ggfs. ein bisschen was anpassen...auch das ist aber in dem Dokument erklärt... Ansonsten gibt es für F1 online dazu das Paket hier: https://my.st.com/content/my_st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32-standard-peripheral-libraries/stsw-stm32054.license=1617895331513.product=STSW-STM32054.version=3.5.0.html Darüber ist auch eine Online-Dokumentation abrufbar...
Uli A. schrieb: > aber immerhin gibt > es ja direkt von ST ne recht gute Anleitung für CMSIS inklusive > Anwendungsbeispielen....falls noch jemand daran interessiert ist, hier > der Link: > https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32-standard-peripheral-libraries/stsw-stm32062.html#documentation Da verwechselst du was. Diese Anleitung ist für die alte SPL, die war mal vor der HAL aktuell. CMSIS ist ARM Standard. CMSIS-Core enthält nur Strukturen und #defines für die Registeradressen. Darauf aufbauend gibt es noch ein paar andere CMSIS Bibliotheken die aber Geld kosten. Die Hal baut auf CMSIS-Core auf. Ob die alte SPL auch darauf aufbaut, weiß ich nicht.
Stefan ⛄ F. schrieb: > Da verwechselst du was. Diese Anleitung ist für die alte SPL, die war > mal vor der HAL aktuell. Verstehe. Danke für die Richtigstellung...
Stefan ⛄ F. schrieb: > Die Hal baut auf CMSIS-Core auf. Ob die alte SPL auch darauf aufbaut, > weiß ich nicht. Hab mir die Beschreibung im Dokument UM1850 nochmal ein bisschen angesehen....da ist ja neben HAL auch alternativ die abgespeckte Lowlayer(LL)-Variante beschrieben....hast Du damit schon gearbeitet ? Und wenn ja, weißt Du, ob es eine Möglichkeit gibt, Cube so zu konfigurieren, dass der generierte Code bzw. die generierten Header- und C-Files nicht auf HAL aufgebaut werden sondern auf LL ? Das könnte ja ggfs. ein interessanter Mittelweg sein...
Uli A. schrieb: > Stefan ⛄ F. schrieb: >> Die Hal baut auf CMSIS-Core auf. Ob die alte SPL auch darauf aufbaut, >> weiß ich nicht. > > Hab mir die Beschreibung im Dokument UM1850 nochmal ein bisschen > angesehen....da ist ja neben HAL auch alternativ die abgespeckte > Lowlayer(LL)-Variante beschrieben....hast Du damit schon gearbeitet ? > > Und wenn ja, weißt Du, ob es eine Möglichkeit gibt, Cube so zu > konfigurieren, dass der generierte Code bzw. die generierten Header- und > C-Files nicht auf HAL aufgebaut werden sondern auf LL ? > > Das könnte ja ggfs. ein interessanter Mittelweg sein... Wenn du an HAL scheiterst, wirst du dir an LL erst Recht die Zähne ausbeissen. Sorry, aber, wenn ich deinen Code von Oben sehe, und den Thread verfolge, verfestigt sich bei mir der Eindruck, daß weder HAL noch LL oder CMSIS dein Problem ist, sondern der Mangel an grundsätzliche C-Kenntnissen. Solange das so ist, wirst du mit KEINEM Framework erfolgreich sein.
Uli A. schrieb: > Und wenn ja, weißt Du, ob es eine Möglichkeit gibt, Cube so zu > konfigurieren, dass der generierte Code bzw. die generierten Header- und > C-Files nicht auf HAL aufgebaut werden sondern auf LL ? Meinst Du das? STM32CubeMX => Project Manager => Advanced Settings => im "Driver Selector" von HAL auf LL umstellen Scheint aber nicht für alle Peripherals möglich zu sein, da bei einem gerade geöffneten Beispiel für einen H7 stellenweise nur "HAL" als einzige Option möglich ist. Gruß, Michael
> mit KEINEM Framework erfolgreich sein Er kann ja "bare metal" mit den in der CMSIS verfuegbaren Headerfiles schon mal anfangen. Vorteil: Er braucht "nur" das Referenzmanual des Controllers und das ARM-Referenzmanual lesen (und verstehen). Fuer GPIOs, Timer, SPI, I2C, ADCs und DACs reicht das ja allemal. Wenn etwas nicht wie gewuenscht funktioniert, kann er sich Details des Registerumgangs in den Beispielen der alten STM32 Standardlibrary ansehen. Was landet wo in welcher Reihenfolge, und welche Bedingungen werden geprueft.
... schrieb: > Er kann ja "bare metal" mit den in der CMSIS verfuegbaren > Headerfiles schon mal anfangen. > Vorteil: Er braucht "nur" das Referenzmanual des Controllers > und das ARM-Referenzmanual lesen (und verstehen). > Fuer GPIOs, Timer, SPI, I2C, ADCs und DACs reicht das ja allemal. > > Wenn etwas nicht wie gewuenscht funktioniert, kann er sich > Details des Registerumgangs in den Beispielen der alten > STM32 Standardlibrary ansehen. > Was landet wo in welcher Reihenfolge, und welche Bedingungen > werden geprueft. Ja, so in die Richtung denke ich auch gerade...ich muss halt mal einen möglichst sinnvollen Weg einschlagen, um mein Projekt irgendwann in realisierbare Bahnen zu bekommen....und ich habe ja schon mit Baremetal Programmierung begonnen....dachte nur, ich könnte das etwas einfacher kombinieren mit einer Art Grundsetup in Cube - aber das entpuppt sich ja eher als nur anders geartetes aber eben nicht gerade kleineres Lernfeld...
Harry L. schrieb: > Wenn du an HAL scheiterst, wirst du dir an LL erst Recht die Zähne > ausbeissen. Warum siehst Du das so ? Kannst Du mir das erklären ? Kommentare wie Harry L. schrieb: > Solange das so ist, wirst du mit KEINEM Framework erfolgreich sein. sind wenig hilfreich, wenn sie auch in der Sache (noch viele Wissenslücken bei mir) teilweise zutreffend sind.
Michael F. schrieb: > Meinst Du das? > > STM32CubeMX => Project Manager => Advanced Settings => im "Driver > Selector" von HAL auf LL umstellen Ja, genau...danke, hatte ich noch nicht gefunden. Michael F. schrieb: > Scheint aber nicht für alle Peripherals möglich zu sein, da bei einem > gerade geöffneten Beispiel für einen H7 stellenweise nur "HAL" als > einzige Option möglich ist. Hmmm....das kann ich jetzt bei mir nicht feststellen...bei welcher Einstellung genau ist bei Dir nur HAL einstellbar ? Zumindest klappt bei mir alles bisher ausprobierte, wie GPIO RCC USART SPI I2C .... Sind bei mir alle auf LL umstellbar - sowohl als ganze Kategorie (z.B. USART) als auch die einzelnen Items unabhängig voneinander (z.B. nur USART1 als LL und USART2 auf HAL
Uli A. schrieb: > Harry L. schrieb: >> Wenn du an HAL scheiterst, wirst du dir an LL erst Recht die Zähne >> ausbeissen. > > Warum siehst Du das so ? Kannst Du mir das erklären ? > Weil der Umgang mit LL sehr viel anspruchsvoller als HAL ist, und du nicht einmal sattelfest bei der Nutzung von Pointern und Strukturen bist. > Kommentare wie > > Harry L. schrieb: >> Solange das so ist, wirst du mit KEINEM Framework erfolgreich sein. > > sind wenig hilfreich, wenn sie auch in der Sache (noch viele > Wissenslücken bei mir) teilweise zutreffend sind. Du magst das ja als wenig hilfreich empfinden, aber C ist nun mal die Grundvoraussetzung um mit HAL & Co. überhaupt was Sinnvolles anzustellen, und bei dir ist nunmal nicht HAL das was dich ausbremst. Das kannst du nicht überspringen - ob dir das gefällt oder nicht.
:
Bearbeitet durch User
Uli A. schrieb: > Hmmm....das kann ich jetzt bei mir nicht feststellen...bei welcher > Einstellung genau ist bei Dir nur HAL einstellbar ? Mit einem STM32H753 als Target ist z.B. bei ETH, SDMMC oder FMC nur HAL verfügbar. Bei den von Dir genannten Peripherals ist sowohl HAL als auch LL möglich. Gruß, Michael
Uli A. schrieb: > Hab mir die Beschreibung im Dokument UM1850 nochmal ein bisschen > angesehen....da ist ja neben HAL auch alternativ die abgespeckte > Lowlayer(LL)-Variante beschrieben....hast Du damit schon gearbeitet ? Nein. Hier wurde mal diskutiert, dass sie schlanker und hardwarenäher sei, allerdings nicht für alle STM32 Modelle verfügbar. Uli A. schrieb: > Und wenn ja, weißt Du, ob es eine Möglichkeit gibt, Cube so zu > konfigurieren, dass der generierte Code bzw. die generierten Header- und > C-Files nicht auf HAL aufgebaut werden sondern auf LL ? Bei den Modellen wo es geht, bietet die IDE das irgendwo in diesem Code-Generator Dialog an.
Wenn du dich mal durchs Datenblatt und Referenzmanual gearbeitet haettest, und die Register mit Hilfe des Headerfiles gesetzt und geprueft haettest, waere die Initialisierung und Ansteuerung von Controllertaktsystem und GPIOs schon lange fertig und erledigt. Statt dessen wird wieder nur ueber weitere "Hilfsmittel" diskutiert. Das wird dich kaum weiterbringen...
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.