© Golubovy/Shutterstock.com
Java am Microcontroller mit MicroEJ – Teil 5

Hardwarezugriff mit EJ


Prozessrechner wie der Raspberry Pi oder die von Shenzhen Xunlong gefertigten OrangePi-Geräte haben sich im Bereich der MSR-Anwendungen fest etabliert. Möchte man umfangreiche Grafiken realisieren und benötigt keine Echtzeitperformance, so ist ein Desktop-Linux schon aufgrund der wesentlich bequemeren Programmierbarkeit meist die bessere Wahl.

Andererseits gilt auch, dass ein Prozessrechner ein vergleichsweise großes und schweres Element ist – Abbildung 1 stellt einen (kleinen) Shenzhen-Xunlong-Prozessrechner und ein komplettes System aus dem Unternehmen des Autors gegenüber.

hanna_microej_5_1.tif_fmt1.jpgAbb. 1: Die Verwendung von STM32-Prozessoren sorgt für wesentlich kleinere Systeme

Komplett ist die Situation allerdings erst dann, wenn wir unserem STM32 neben der GUI-Generierung auch die Möglichkeit zur Interaktion mit Hardware bieten. MicroEJ mag kein klassisches Echtzeitbetriebssystem sein, hat aber im Bereich Hardware einiges in petto – in diesem Artikel wollen wir uns die diesbezüglichen Möglichkeiten ansehen.

Reale Hardware verpflichtend erforderlich

Kamen unsere in den letzten Heften durchgeführten Experimente im Simulator zurecht, so müssen wir spätestens an dieser Stelle wieder zur Verwendung des STM32F7-Evaluations-Boards zurückkehren. Konfigurieren Sie das Board also wie in den vergangenen Artikeln besprochen.

Im Interesse der Bequemlichkeit wird der Autor auf das im zweiten Artikel verwendete Beispiel zurückgreifen – es enthält schon eine grundlegende Anzeige-Toolchain, die sich bereitwillig recyceln lässt.

Für die Interaktion mit der Hardware benötigen wir die Hal-Bibliothek. Öffnen Sie die zum Projekt gehörende Datei modules.ivy, und binden Sie das zusätzliches API nach folgendem Schema ein:

<dependencies> <dependency org="ej.api" name="edc" rev="1.2.3" conf="provided->*" /> <dependency org="ej.api" name="microui" rev="2.0.6"/> <dependency org="ej.api" name="hal" rev="1.0.4"/>

Als nächste Aufgabe müssen wir feststellen, über welche Id die GPIO-Ports unseres Evaluations-Boards von außen ansprechbar sind. In der Vergangenheit musste man als Entwickler an dieser Stelle normalerweise damit beginnen, das Datenblatt des Zielsystems zu studieren und unter Verwendung von Keil unter Nutzung des nativen API (oder sogar direkte Registerzugriffe) die notwendigen APIs realisieren.

Erfreulicherweise ist sich I2ST dessen bewusst, dass normale Java-Entwickler mit dieser Aufgabe mehr oder weniger stark überfordert sind – der Großteil der von I2ST heute bereitgestellten Plattformen bringt mehr oder weniger umfangreiche GPIO-Funktionalitäten mit.

Im Fall unseres STM32 ist die relevante Dokumentation unter [1] anzusprechen – besonders interessant ist die in Abbildung 2 gezeigte Tabelle: Die Plattformdokumentation informiert uns über die Zuordnung zwischen Konstanten und physikalischen Pins.

hanna_microej_5_2.tif_fmt1.jpgAbb. 2: Die Plattformdokumentation

Auffällig ist, dass die GPIO-Pins über mehrere Ports gleichermaßen ansprechbar sind. Besonders auffällig ist dies bei den Ports Arduino Analog und Arduino Digital – wer die Gestaltung des STMicroelectronics-Evaluationsboards studiert, stellt fest, dass die Arduino-Pins über verschiedene Ports realisiert werden.

Die Dokumentation von MicroEJ erweist sich im Bereich des Hardwarezugriffs – wie so oft – als primäres Hindernis. Bei der Arbeit mit den GPIO-Pins werden wir uns vor allem im Paket ej.hal.gpio.GPIO aufhalten. Wer es reflektiert, findet unter anderem folgende Methode:

public static void setMode(int port, int pin, Mode mode) { throw new RuntimeException(); }

Analog zum nativen API des STM32 gilt auch hier, dass die Identifikation von GPIO-Hardwareressourcen über zwei Werte erfolgt: einerseits die Id des Ports, andererseits die I des Pins. MicroEJ führt im Rahmen der Einrichtung grundlegende Plausibilitätschecks durch, Fehlschläge lösen meist eine Exception aus.

Unser Evaluations-Board führt vergleichsweise wenige Pins des Mikrocontroller nach außen. Der Autor wird in den folgenden Schritten aus Gründen der Bequemlichkeit mit dem Port Numero drei des digitalen Teils des Arduino-Ausgangs arbeiten. Da die Ansteuerung von Hardware idealerweise in einem eigenen Thread erfolgen sollte, legen wir hierzu eine neue Klasse an (Listing 1).

Listing 1

public class SUSGPIOThread extends Thread { @Override public void run() { GPIO.setMode(30, 3, Mode.DIGITAL_OUTPUT); while (1 == 1) { GPIO.setDigitalValue(30, 3, true); GPIO.setDigitalValue(30, 3, false); GPIO.setDigitalValue(30, 3, true); GPIO.setDigitalValue(30, 3, false); } } }

In der Arbeitermethode findet sich dabei keine Raketenwissenschaft. Am Beginn der Abarbeitung nutzen wir setMode, um den Port als digitalen Ausgang zu deklarieren. Danach geben wir die aus anderen Artikeln bekannte charakteristische Wellenform aus – die beiden unterschiedlich langen Wellentäler erlauben Rückschlüsse darüber, wie lange die Abarbeitung der while-Schleife benötigt.

Der eigentliche Start des Threads ist normaler Java-Code, der im Konstruktor der Klasse SUSDisplayable unterkommt (Listing 2).

Li...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang