Blue Pill in der STM32 Cube-IDE         


Elektronik-Labor  Projekte   


Leander hat mich auf die STM32 CubeIDE gebracht und mir die ersten Schritte gezeigt. Jetzt wollen wir uns gemeinsam reinarbeiten und alles dokumentieren. Diese kostenlose Entwicklungsumgebung bekommt man nach einer einfachen Registrierung unter https://www.st.com/en/development-tools/stm32cubeide.html. Die Installation dauert einige Zeit. Aber die Geduld lohnt sich.



Nun startet man ein neues STM32-Projekt. Dazu muss man zuerst den Zielprozessor auswählen, in diesem Fall den STM32F103C8.



Dann muss das Projekt einen Namen bekommen, in diesem Fall BluePill1.




Nach kurzer automatischer Vorbereitung einiger Projektdateien landet man in einer Übersicht alle Controller-Pinne. Dort kann man dann einstellen, welche Pinne man wie einsetzen möchte. Vorerst soll nur der Port PC13 als GPIO-Output eingerichtet werden.



In derselben Übersicht gibt es den wichtigen Punkt System Core/SYS/Debug. Da muss unbedingt Serial Wire ausgewählt werden, denn sonst trennt man gleich beim ersten Test die Verbindung zum Chip. Serial Wire ist ja die Schnittstelle, mit der der ST-Link V2 den Controller brennt und ausliest.



Unter System Core/RCC kann man einstellen, dass man den Quarz (Crystal/Ceramic Resonator) verwenden will. Und weil es so verführerisch war, habe ich auch den Master Clock Output angeklickt. Die 8 MHz kommen dann am Pin PA8 raus, ohne dass ich eine Zeile Code schreiben muss. 



Die Pin-Übersicht zeigt nun, welche Pinne belegt sind. PC13 habe ich selbst als Ausgang gewählt. PD0 und PD1 hängen am Quarz. PA13 und PA14 bilden die Programmierschnittstelle. Und PA8 ist der Ausgang für das 8MHz-Taktsignal.



Dann klickt man auf Manage configurations for the current project. Das ist das kleine Symbol links vom Hammer, vermutlich soll es ein Zahnrad mit Kurbel darstellen. Die IDE bereitet dann alle C-Dateien vor.



Entscheidend ist die Datei main.c. Wenn ich genau hinschaue, finde ich da Teile meiner Einstellungen wieder, z.B. dass ich den Quarz verwenden möchte. Das hat die IDE freundlicherweise für mich erledigt. Und dann sich Bereiche für den USER CODE ausgewiesen, an die ich mich halten sollte. Wenn ich nämlich später mal einen weiteren Ausgang haben möchte, komme ich  mit BluePill1.ioc wieder in die Pin-Übersicht, kann dort was ändern und dann wieder den Code generieren lassen. Meine eigenen Abschnitte werden dabei nicht angetastet.



In meinen erlaubten Bereich schreibe ich dann diesen Code:

  while (1)
  {
      HAL_GPIO_WritePin(GPIOC, GPIO_Pin_13, 1);
      HAL_Delay(200);
      HAL_GPIO_WritePin(GPIOC, GPIO_Pin_13, 0);
      HAL_Delay(200);
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
  }

HAL bedeutet Hardware Abstraction Layer und stellt eine Zwischenschicht dar, die mir das Leben erleichtern soll. Wenn ich meinen Code eingegeben habe, klicke ich auf den Hammer: Build ´Debug´ for project ´BluePill1´. Der Code wird damit übersetzt.



Dann wird der Debugger gestartet. Unter Run/Debug Configutations.../Debugger muss noch der ST-Link ausgewählt werden.



Nun kann man mit Run/Debug, oder mit dem kleinen grünen Käfer oder mit F11 das Programm starten. Man sieht, dass der ST-Link arbeitet, dann blinkt die grüne LED auf der BluePill-Platine einige Male, und dann bleibt alles stehen. Das liegt daran, dass der Debugger bei HAL_Init(); einen Breakpoint gesetzt hat. Mit Resume, F8 oder dem grünen Pfeil geht es weiter. Die grüne LED blinkt nun wie geplant vor sich hin. Und auch das Taktsignal mit 8 MHz kommt wie bestellt am Pin A8 raus.




Mit Run/Terminate kann man übrigens den Debugger anhalten. Die LED blinkt dann weiter. Und wenn ich das Programm für gelungen ansehe, kann ich das Ergebnis mit ST-Link Utility speichern. Das Programm heißt jetzt BluePill1Cube.hex. Zum Test habe ich den Chip einmal komplett gelöscht und das Programm dann wieder geladen. Es blinkt und blinkt und blinkt ....

So das war's, ganz schön viel Arbeit für das erste Blinken. Aber beim nächsten Test wird alles einfacher.



Elektronik-Labor  Projekte