© Spirit Boom Cat/Shutterstock.com
Java am Microcontroller mit MicroEJ - Teil 2

Embedded-Benutzerschnittstellen mit Java


Die Möglichkeit, Java-Code auf einem Mikrocontroller auszuführen, hilft bei der Reduktion der Softwarekopplung. MicroEJ bringt allerdings auch einen reichhaltigen GUI-Stack mit.

Die Frage, ob sich Java zur Realisierung eines mit 400 kHz rödelnden Schaltreglers eignet, braucht man nicht wirklich zu diskutieren. Der Garbage Collector reicht aus, um die Echtzeiteigenschaften des Ausführungssystems irreparabel zu beschädigen.

Analog zur Frage, ob eine Tupolew 144 das einzig wahre Flugzeug ist (Antwort: nein, denken Sie an Frachtflüge), gibt es auch in der Welt der Mikrocontrollerprogrammierung eine Vielzahl von Aufgaben, die ohne Echtzeiteigenschaften auskommen. Ein Klassiker wäre die Anzeige reichhaltiger grafischer Oberflächen – gewöhnliche LCD-Displays sind mittlerweile nicht einmal mehr im Humidorbereich akzeptabel (Abb. 1).

hanna_microej_2_1.tif_fmt1.jpgAbb. 1: Produkte wie der Hygrosage vertreiben numerische bzw. alphanumerische LCDs aus ihren letzten Einsatzbereichen

GUI im Chaos

Die Entwicklung von Benutzerschnittstellen für Java-Programme ist seit jeher ein Marsch durch den Urwald – Dutzende von Standards konkurrieren um die Gunst des PT-Entwicklers. Bei der Arbeit in der MicroEJ-Welt ist die Situation insofern etwas einfacher, als es – eigentlich – nur zwei GUI-Systeme gibt. Erstens gibt es die MicroUI-Bibliothek. Hinter dem Akronym verbirgt sich der Begriff Micro User Interface. Es handelt sich dabei um einen „Zeichen-Primitiv-Stack“, der nebenbei auch für das Entgegennehmen von Button- und Touchscreen-Ereignissen und die Internationalisierung von Strings verantwortlich zeichnet. In der Theorie könnte ein Entwickler mit MicroUI Steuerelemente zusammenbauen.

Um uns diese (wenig befriedigende) Arbeit zu ersparen, gibt es zusätzlich die auf MicroUI basierenden Widget-Libraries. Sie stellen Dutzende vorgefertigte Steuerelemente zur Verfügung, mit denen der PT-Entwickler unbürokratisch Applikationen realisieren kann.

Erzeugung eines eigenen Projekts

Als erste Aufgabe wollen wir unseren STM32 zur Realisierung kleiner grafischer Spielereien einspannen. Hierzu wollen wir ein neues Projekt erzeugen, weshalb wir im MicroEJ SDK auf die Option File | New klicken. Das MicroEJ SDK bietet dort zwei Projektvorlagen an: einerseits ein MicroEJ Sandbox Application Project, andererseits ein MicroEJ Standalone Application Project.

Laut dem unter [1] bereitstehenden MicroEJ-Glossar kennt die Ausführungsumgebung vier Applikationstypen: Die Standalone Application ist eine Applikation, die direkt mit dem für die Plattform verantwortlichen C-Code verlinkt wird. Eine Systemapplikation ist dann eine Standalone Application, die allerdings durch statisches Linking verbunden wird und dadurch direkt Teil des Images ist. Sandboxed Applications unterscheiden sich davon insofern, als sie als Gast in einer Multi-Sandbox-Firmware leben. Kernelapplikationen sind für uns an dieser Stelle nicht weiter interessant.

Auch wenn sich Standalone-Applikationen gemäß den unter [2] bereitstehenden Anweisungen in eine Sandbox-Applikation umwandeln lassen, wollen wir hier direkt mit einer Sandbox-Vorlage arbeiten. Im ersten Schritt fragt MicroEJ dabei nach einem Projektnamen – der Autor vergibt SUSGUI1. Die Application-Felder werden automatisch bevölkert, im Feld Organisation dürfen Sie auf Wunsch den Paketnamen anpassen. Nach dem positiven Quittieren des Dialogs vergehen etwa 30 Sekunden, bevor das neue Projekt im Package Explorer aufscheint. MicroEJ Studio muss im Hintergrund diverse Housekeeping-Aufgaben erledigen.

Nach dem erfolgreichen Durchlaufen des Generatorassistenten stellen wir fest, dass wir ein komplett leeres Projekt erhalten haben. Ursache dafür ist, dass eine Applikation sowohl einen Background Service als auch eine mit einem Benutzer-Interface ausgestattete Activity realisieren darf. Unsere erste Amtshandlung besteht darin, die Datei module.ivy zu öffnen und nach dem folgenden Schema um einen Verweis auf die MicroUI-Bibliothek zu erweitern (Listing 1).

Listing 1

<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.library.wadapps" name="framework" rev="1.10.0" /> </dependencies>

Die MicroUI-Firmware wird in einem hochmodularen Verfahren ausgeliefert, um Entwicklern das maximale Reduzieren des Speicherverbrauchs zu ermöglichen. Das Einsparen von 10 kB mag auf dem Desktop egal sein – wenn es Ihnen im Embedded-Bereich das Nutzen der nächstkleineren Chipgröße ermöglicht, können die Gewinne insbesondere bei großen Fertigungsmengen jedoch enorm sein.

Wir wollen in den folgenden Schritten einen grafischen Applikationsdienst realisieren. Deshalb erzeugen wir eine neue Klasse, die wir im ersten Schritt von Activity ableiten. Der einige Zeit in Anspruch nehmende Generierungsprozess für die erforderlichen Member-Funktionen liefert dann eine nach dem Schema in Listing 2 aufgebaute Struktur, die Sie um den Konstruktor und das Zurückliefern eines Strings in der ID-Methode erweitern.

Listing 2

import ej.microui.MicroUI; import ej.wadapps.app.Activity; public class SUSActivity implements Activity { public SUSActivity() { MicroUI.start(); } @Override public String getID() { return "sus-activity"; }

Die Implementie...

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

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang