Blue Pill in der STM32 Cube-IDE
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.