Apoapsis 2019

CanSat-Team des Humboldt-Gymnasiums Vaterstetten

Embedded-Programmierung mit dem STM32

Wer unsere Social-Media-Kanäle und unsere Blogposts aufmerksam verfolgt, weiß, dass wir den STM32H743ZI von STMicroelectronics als Prozessor hernehmen möchten. Wie das genau aussehen soll, werden wir euch in diesem Blogpost erklären.

Der Chip

Den STM32H743ZI haben wir uns nicht nur wegen seines leicht einprägsamen Namens ausgesucht, sondern vor allem aufgrund seiner herausragenden Performance. Der Prozessor basiert auf dem ARM Cortex M7 und ist einem Arduino Nano weit überlegen: Mit 400 MHz (25 mal schneller) und 1 MByte RAM (500 mal mehr) wird es ein Leichtes sein, mehrere Messdaten sowie die Bilder gleichzeitig aufzuzeichnen.

Endlich kein C mehr!

Bei der Programmierung von Arduinos und generell im Embedded-Bereich ist C mit Abstand die am weitesten verbreitete Sprache. Doch C birgt einige Schwierigkeiten für Entwickler, wie zum Beispiel das Umgehen mit Pointern oder das Verhindern von Speicherzuordnungsfehlern (besser bekannt als Memory Allocation Error).

Deswegen haben wir uns entschieden, die Programmiersprache Rust zu verwenden. Das Mozilla-Projekt ist nicht nur modern und macht mehr Spaß; dank dem Ownership-Prinzip können keine Speicherzuordnungsfehler mehr auftreten, ohne Abstriche in der Performance zu machen, denn Rust kommt ohne Laufzeit-Garbage-Collector aus. Viele Fehler werden bei Rust bereits beim Kompilieren (und nicht erst zur Laufzeit) abgefangen, außerdem müssen wir uns nicht mit Pointern herumärgern.

Rust Embedded

Im Rust-Embedded-Bereich ist es zweckmäßig, einen sogenannten Hardware Abstraction Layer (HAL) für seinen Chip zu verwenden. Dieser schafft einheitliche Schnittstellen für übergeordnete Anwendungen – völlig unabhängig davon, welcher Prozessor eigentlich zu Grunde liegt. Dies ermöglicht es uns, später doch einen anderen Chip herzunehmen, ohne unsere CanSat-Software verwerfen zu müssen.

Konkret benötigen wir also eine Implementierung des embedded-hal-Projekts für den STM32H743ZI. Einige STM32-Chips werden zwar schon unterstützt, aber die STM32H7-Reihe ist noch nicht dabei. Also müssen wir das selber machen.

Zudem benötigen wir für die Sensoren und weiteren Komponenten, die wir mit dem STM ansteuern wollen, passende Treiber. Manche davon existieren schon, andere müssen wir ebenfalls selbst entwickeln.

Sobald wir das alles mithilfe der Spezifikationen, Datenblätter und Handbücher des Chips und der Sensoren erledigt haben, können wir mit diesen arbeiten und das eigentliche CanSat-Programm zum Sammeln und Speichern unserer Daten schreiben.

Unser Testaufbau des STM-Development-Boards mit einigen Sensoren.
Unser Testaufbau des STM-Development-Boards mit einigen Sensoren.

Eine Schwierigkeit ist allerdings noch, wie wir unser Programm auf den STM flashen werden. Denn da gibt es noch recht wenig Support aus der Open-Source-Community. Mit dem offiziellen Werkzeug-Bundle STM32Cube können wir zwar flashen, jedoch nicht über das Command-Line-Interface (CLI) debuggen. Dies könnte jedoch mit einer Development-Version von OpenOCD klappen, welche dem GNU Project Debugger (GDB) das Debuggen ermöglichen könnte.

Und wie weit sind wir?

Federführend bei der Software ist Henrik, der schon letztes Jahr diese Rolle inne hat. Außerdem beteiligt sich Johanna bei der Implementierung der Treiber. Momentan sind die beiden noch mit dem HAL beschäftigt: Die GPIO-Implementierung konnte mit ein paar Anpassungen aus einem anderen Rust-Projekt für den STM32H7 übernommen werden. Laut Datenblatt richtig implementiert ist die Reset and Clock Control (RCC), jedoch funktioniert diese noch nicht. Das ist relativ problematisch, da wir ohne funktionierende Clock im Prinzip gar nichts machen können. Sobald das gefixt ist, müssen noch I²C, SPI und UART implementiert werden, da diese für die Ansteurung der Sensoren benötigt werden. Die Fertigstellung des HAL und der benötigten Treiber sind der erste Meilenstein, den wir gerade anvisieren.

Die Erfahrung aus unserer letztjährigen Teilnahme zeigt aber auch, dass sich selten etwas so entwickelt, wie wir es uns anfangs vorgestellt haben. Gut möglich also, dass wir die Planung nochmals umwerfen und doch ein anderes System verwenden. Darüber werden wir euch aber wieder genauestens informieren!

Geschrieben am 12. April 2019