Category: CMake

Experimente mit STM32 BluePill und libopencm3

Heute habe ich an einem Resturlaubstag mal ein bisschen mit meiner STM32 BluePill experimentiert.

Leider hat es einiges länger gedauert, als ich dachte.

Zunächst habe ich mir aktuelle Versionen von OpenOCD und den freien ST-Link Tools gebaut und installiert. Das funktionierte auch ohne Probleme.

Die ST-Link Tools bringen sogar eine GUI mit GTK3 mit. Leider kann das Tool nur Binärdateien auslesen und programmieren, aber es ist immerhin etwas bedienerfreundlicher als die Kommandozeilenvariante.

Danach habe ich mal die libopencm3 compiliert. Das ging auch gut, aber es gibt leider keine Installationsoption. Also muss man in die Projekte das jeweilige Verzeichnis entsprechend reinverdrahten.

Ich habe auch die offiziellen Beispiele mal übersetzt. Zumindest das Systicker Blink, USB HID und USB COM Port Beispiel für STM32L1 habe ich mit meiner BluePill zum Laufen bekommen.

Danach habe ich mir die Infrastruktur für eigene Projekte bauen wollen und bin beinahe gescheitert. Aus einigen Quellen musste ich mir Teile zusammenklauen, aber ich kann jetzt über CMake entsprechende Projekte aufsetzen, die die libopencm3 benutzen.

Das ganze habe ich im Visual Studio Code aufgesetzt und wollte dann die Debugerweiterung für Cortex-M benutzen und bin wieder gescheitert.

Nach langem Puzzeln habe ich gemerkt, daß mein gdb zu alt ist. Dann musste ich mir erstmal eine aktuelle Version bootstrappen.
Kurzentschlossen wollte ich die offizielle ARM Toolchain installieren, aber das waren 0,5GB Download. Das war mir doch zu riesig, also habe ich einen offiziellen gdb runtergeladen und mit einer kleinen Anleitung auch gebaut.

Mit dieser gdb Version konnte ich dann aber tatsächlich debuggen und mit .svd File auch die Peripherieregister anschauen.

Gelernte Punkte habe ich gleich mal in einer Wissenssammlung aufgeschrieben. Die werde ich vermutlich zukünftig noch erweitern und ggfs ergänzen.

Eigentlich wollte ich noch ein Beispiel mit Segger RTT ausprobieren, bin aber nicht mehr soweit gekommen.

STM32 HAL Library für die “Blue pill”

Seit einiger Zeit kann man die sogenannte “Blue Pill” kaufen. Dies sind Mikrocontroller aus der STM32 Familie mit Cortex Kern, konkret STM32F103C8 mit Cortex M3, die auf einem schönen klassischen DIL-Träger aufgelötet sind mit Pinheader und Micro-USB zur Stromversorgung ausgerüstet sind. Dadurch passt alles in ein Steckbrett und kann auch als Arduino betrieben werden.

Ich habe mir ein paar Exemplare beschafft und möchte diese natürlich mehr oder minder “bare metal” benutzen, ähnlich wie ich das im Beruf auch tue. Dort arbeite ich seit gut 7 Jahren ebenfalls mit STM32 Controllern.

ST Microelectronics stellt eine recht gute Bibliothek zum Ansprechen der Controllerperipherie zur Verfügung. Damit man diese nicht immer mit jedem noch so kleinen Projekt von Null auf übersetzen muss, habe ich mir mit CMake ein kleines Framework geschrieben, welches die Library für den konkreten Controller der “Blue Pill” als Binary übersetzt.

Ausprobiert habe ich die Library noch nicht, aber es baut und linkt. Eigentlich müsste das schon reichen, das .a File wird im neuen Projekt referenziert und der Includepfade zu der Headern der HAL Library mitangegeben.

Der Anwender muss ggfs. die STM32 Header für den Controller in seinem Projekt referenzieren, denn einige Headerfiles der HAL Library ziehen die controllerspezifischen Header nochmal rein.

Näheres und technische Updates gibt es auf der Projektablage bei Github:
https://github.com/simonsunnyboy/stm32hal_bluepill

Ich habe den heute aktuellen Stand der HAL Library eingebunden, speziell den vom CubeMX angelegten, STM32Cube_FW_F1_V1.8.0.

Crosscompiling für Atari ST mit gcc und CMake

Mit dem richtigen CMake File kann man auch für den Atari ST komfortabel mit PC Tools entwickeln.

Benötigt werden

  1. Crosscompiler und -toolchain mit gcc und zugehörigen Tools für Atari ST (z.B. hier: http://vincent.riviere.free.fr/soft/m68k-atari-mint/)
  2. CMake (http://cmake.org/)
  3. IDE für das Host System (ich verwende CMake mit Ausgabe von Makefiles und einem Projekt für die Code::Blocks IDE unter Linux)

Eine einfache CMakeLists.txt sieht dann wie folgt aus:

#
# Experimental File to build a basic file with custom startup code and without MiNTLib
# Version 17.7.2014
#
cmake_minimum_required(VERSION 2.8)
# disable strange gcc assumptions
set(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
set(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS "")
# select Atari ST cross compiler
set(CMAKE_C_COMPILER m68k-atari-mint-gcc)
set(CMAKE_ASM_COMPILER m68k-atari-mint-as)
set(CMAKE_C_FLAGS "-m68000 -O3 -fomit-frame-pointer -Wall -mshort -nostdlib -std=c99")
set(CMAKE_EXE_LINKER_FLAGS  "${CMAKE_C_FLAGS} ${PROJECT_SOURCE_DIR}/startup.S" )
add_executable(stlow1.tos
 main.c
 )
#
# Experimental File to build a basic file with custom startup code and without MiNTLib
# Version 17.7.2014
#
cmake_minimum_required(VERSION 2.8)
# disable strange gcc assumptions
set(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS “”)
set(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS “”)
# select Atari ST cross compiler
set(CMAKE_C_COMPILER m68k-atari-mint-gcc)
set(CMAKE_ASM_COMPILER m68k-atari-mint-as)
set(CMAKE_C_FLAGS “-m68000 -O3 -fomit-frame-pointer -Wall -mshort -nostdlib -std=c99”)
set(CMAKE_EXE_LINKER_FLAGS  “${CMAKE_C_FLAGS} ${PROJECT_SOURCE_DIR}/startup.S” )
add_executable(stlow1.tos
main.c

Dabei ergeben sich folgende Eigenschaften:

  • Code für Atari ST mit 68000er ohne FPU
  • int ist short, d.h. 16.bit (aber statt int ist eh stdint.h zu verwenden)
  • MinTLib wird nicht verwendet (d.h. keine Standard C Libraryfunktionen, aber die TOS Bindings sind da und voll funktionsfähig, ausserdem wird das Binary schön klein)
  • eigener Startupcode (hier von Markus Fröschle geklaut und um den Initcode von Leonard/Oxygene ergänzt)

Letztere sind für mich als Spiele und Demoentwickler interessant, da ich nicht immer 70K unixoide Library  dazulinken möchte.
Die Compilerflags kann man natürlich ggfs für den  Atari Falcon 030 oder die Firebee passend modifizieren.

Fehlt nur noch ein passendes Projekt, der erzeugte Code mit reinem C ist übrigens nah dran an handgeschriebenem Assembler. Nur echte ST Codingcracks werden besseren Assemblercode schreiben können als das, was hier ein relativ aktueller gcc erzeugt.

Vielen Dank an Vincent Riviere für die Toolchain und Markus Fröschle für praktisches Knowhow, ohne die Mintlib kleine effiziente Executables für den ST zu erzeugen.

CMake Toolchaindefinition für GP2X Wiz

Ich hatte schon vor längerer Zeit eine Toolchaindefinition zur Verwendung des GP2X Wiz GNU Crosscompilers mit CMake geschrieben. Diese möchte ich natürlich öffentlich zugänglich machen.

Damit kann man Projekte, die CMake (Was ist CMake?) verwenden, einfacher für den GP2X Wiz übersetzen.

Verwendet wird die Toolchaindefinition mit CMake wie folgt:

cmake -DCMAKE_TOOLCHAIN_FILE=../Toolchain-GP2XWiz.cmake ..
cmake -DCMAKE_TOOLCHAIN_FILE=Toolchain-GP2XWiz.cmake <Pfad zur CMakeLists.txt>

Download