Wer vielleicht auch wie der Autor in den frühen 1980er Jahren mit dem Home-Computing eingestiegen ist und auch damals bereits gerne mit Elektronik gebastelt und programmiert hat, wird sich bestimmt auch über die kleinen preiswerten Minicomputer gefreut haben, die seit einiger Zeit auf dem Markt sind.
Ursprünglich war der Raspberry Pi (RPi), der im Jahr 2012 auf den Markt kam, als Lehrplattform für digitale Elektronik auf Basis der Sprache Python konzipiert (daher das “Pi“ Namen, „Python interpreter“). Der Python interpreter sollt ursprünglich fest eingebaut sein, aber am Ende wurde es dann doch eine sehr offene Architektur und so hat sich um dieses Gerät sehr schnell eine recht große Community gebildet.
Bis heute wurden bereits mehr als 5 Millionen Stück verkauft. Dieser hohe Verbreitungsgrad und die damit verbundene sehr breite Unterstützung machen den Einstieg ins digitale Experimentieren sehr leicht und vor allem preiswert: Ein aktueller Raspberry Pi 2 Model B mit Gehäuse, Netzteil, WLAN-Stick und SD-Karte liegt bei 70-80 Euro.
Auch Java-Entwickler kommen hier inzwischen voll auf ihre Kosten, denn seit geraumer Zeit bringt Oracle regelmäßig parallel zu den „normalen“ JDK 8 Builds jeweils ein JDK 8 for ARM , dass speziell für ARM basierte Plattformen, wie den Raspberry Pi gedacht ist.
Anfangs wurde die Unterstützung von JavaFX für den Einsatz von grafischen Elementen explizit von Oracle beworben. Mit dem aktuellen „Update 33“-Release wurde aber „klamm und heimlich“ JavaFX aus den offiziellen Builds ausgeklammert und dem OpenJDK Projekt übergeben. Johan Vos (Gluon) hat glücklicherweise gleich ein Paket zusammengestellt, dass vom „javafxports“-Repository herunterladen und extrahieren werden kann. Die darin verpackten Bibliotheken lassen sich einfach in entsprechende Verzeichnisse eines installierten ARM-JDKs von Oracle kopieren. Damit steht JavaFX für Embedded wieder zur Verfügung.
Bisher waren die Gestaltungsmöglichkeiten von JavaFX-Oberflächen auf dem RPi Aufgrund eingeschränkter Leistung überschaubar. Vor kurzem ist jedoch der Raspberry Pi 2 mit QuadCore Prozessor und 1GB RAM erschienenen und damit wird es wieder interessanter, UIs für den RPi zu entwickeln:
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
YouTube immer entsperren
Da JavaFX als Besonderheit direkt im Framebuffer läuft, ist kein laufender X-Server erforderlich und es können deutlich Ressourcen gespart werden.
Dieser Artikel zeigt exemplarisch, wie sich Eingangs- und Ausgangszustände eines Raspberry Pi über eine JavaFX basierte Touch-Oberfläche manipulieren und visualisieren lassen.
NetBeans 8
NetBeans 8 hält für Internet-of-Things-Java-Entwickler ein sehr beachtenswertes Feature bereit, das bereits in der Standardinstallation voll integriert zur Verfügung steht:
die Möglichkeit, direkt aus der IDE ein Projekt auf ein Embedded Device, wie einen Raspberry Pi einzurichten und dort remote auszuführen. Dabei kann das Projekt auch im Debug-Modus ausführt oder mit dem Profiler zur Laufzeit überwacht werden.
Vorausgesetzt auf dem entfernten Gerät läuft ein SSH-Dienst, kann eine neue Plattform vom Typ „Remote Java Standard Edition“ erstellt werden. Hier sind dann im folgenden Dialog Informationen wie Adresse des Gerätes, Login Credentials und Pfad zum zu benutzenden JRE/JDK hinterlegt. Danach kann diese in den Projekteinstellungen diese dann als Zielplattform ausgewählt und dann das Projekt laufen gelassen werden.
Abbildung 1:
Remote Platform in NetBeans 8.0.2
Dabei wird das Programm mit allen Abhängigkeiten lokal gebaut, per SCP übertragen und remote via SSHExec ausgeführt. Die Ausgaben von stdout und stderr werden schließlich in die Konsole von NetBeans umgeleitet. Das Remote-Deployment dient nicht nur zur entfernten Ausführung sondern kann eben auch als Auslieferung verstanden werden, denn die Applikation wird anschließend nicht vom RPi gelöscht.
Besonders betont sei hier noch das Setzen von „sudo“ als „Exec Prefix“ Property. Diese Einstellung sorgt dafür, dass das Java-Programm mit „Root“-Rechten auf dem entfernten Gerät ausgeführt wird. Wenn keine anderweitigen Gruppen- und Rechteumstellungen auf dem Raspberry Pi einrichtet werden sollen, ist dies unbedingt nötig, um auf die GPIO-Schnittstelle zugreifen zu dürfen.
Da all diese Schritte ANT basiert sind, kann hier leider nicht auf Maven-Repositories zugegriffen werden. Es ist also erforderlich, Bibliotheken und Abhängigkeiten manuell mit NetBeans-Bordmitteln zu verwalten.
GPIO und Pi4J
Zunächst ein Blick auf die General Purpose Input/Output (GPIO) Schnittstelle des Raspberry Pi. Sie ist das IO-Interface des RPi deren Funktionen sich sehr leicht mit wiringPi (eine C basierte API von Gordon Henderson (@drogon)) nutzen lassen. Praktischer Weise gibt es mit Pi4J eine Java API, das genau auf wiringPi aufsetzt und dieses auch noch passend automatisch mitbringt.
Der GPIO-Header steht im Mittelpunkt der ausgehenden und eingehenden Kommunikation. Beim Modell B können insgesamt 17 Pins zum I/O angefordert werden: 8 Pins GPIO Pins, 2 Pins vom I2C Interface, 5 Pins Serial Peripheral Interface, 2 Pins Serial UART (+ 4 weitere via P5 Connector (nur Rev. 2.0)). Das neuere Modell B+ hält noch weitere 9 GPIOs bereit.
Pi4J unterstützt alle RPi Modelle vom einfachem I/O über PWM und SPI bis I2C bleiben keine Wünsche offen.
Pi4J als Bibliothek einrichten
Zunächst lädt und entpackt man ein aktuelles Build, z.B. den Pi4J 1.0 Release Candidate von der Pi4J Site. Anschließend kann dann in NetBeans eine Bibliothek eingerichtet werden.
Beispiel-Projekt
Für das folgende Beispiel-Projekt „8 Kanal I/O Interface mit JavaFX basierter Touch-Oberfläche“ werden folgende Bauteil benötigt:
- Raspberry Pi (B oder B+)
- Breakout-Kit
- Zwei Breadboards
- Steckverbinder
- 7“ Touch-Display von Chalk-Elec [10]
- Acht LEDs
- Acht 330 Ω Vorwiderstände
- Acht Taster
Abbildung 2:
Schaltungsaufbau der 8 Kanal I/O Steckplatine
Die Zustände für die Ausgänge werden über ToggleButtons der grafischen Oberfläche manipuliert, die Eingänge über Taster getriggert und die Zustände in beiden Fällen an der UI angezeigt. Der I/O-Modus (Eingang/Ausgang) kann jeweils pro Kanal zur Laufzeit umgeschaltet werden (Abbildung 3 bis 5).
Zum besseren Testen der Oberflache kann zudem der GPIO Controller wahlweise aktiviert oder deaktiviert werden. Außerdem darf ein „Exit“-Button nicht vergessen werden: JavaFX kann direkt aus der Konsole den FrameBuffer übernehmen und die Anwendung kann dann nicht ohne Weiteres beendet werden (CTRL-D ist wirkungslos, weil JavaFX Keyboard-Events abfängt).
Abbildung 3:
Das JavaFX UI zum 8 Kanal I/O
Abbildung 4:
Über das UI kann zum Beispiel auch der I/O Modus pro Kanal (IN/OUT) gewählt werden
Abbildung 5:
Ein Kanal der Schaltung wird in der UI durch eine Spalteneinheit repräsentiert
Für die UI soll die eigentliche GPIO Kommunikation transparent sein. Daher werden alle Zustände über einen JavaFX-Properties-Adapter gekapselt. Diese Zwischenschicht bildet die Verbindung von UI und einer Einheit, die über Pi4J das GPIO Interface anspricht.
Abbildung 5:
Die Architektur des Datenflusses vom Taster zur UI und zurück
Etwas gekürzter Auszug der Klasse GpioAdapter.java (es wurde der Code zu Kanal 1-7 ausgeblendet):
Etwas gekürzter Auszug der Klasse IOBoard.java (der Gpio-UI-Controller, (es wurde der Code zu Kanal 1-7 ausgeblendet):
Der Code des Projektes (RaspiGPIOControllerFX) kann via BitBucket bezogen werden.
Zudem gibt es noch folgende YouTube Videos zum Thema NetBeans Remote Deployment, die auch für den Oracle Virtual Developer Day verwendet wurden:
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
YouTube immer entsperren
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
YouTube immer entsperren
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
YouTube immer entsperren
Weitere Links zum Thema:
Die Printversion dieses Artikels ist in der JavaAktuell 04-2015 erschienen.
JavaOne 2014:
James Gosling, Robots, the Raspberry Pi, and Small Devices [UGF8907] (NetBeans Day)
(James Gosling, Jose Pereda, Shai Almog, Johannes Weigend, Jens Deters)
Debugging and Profiling Robots with James Gosling [CON6699] (James Gosling, Mark, Heckler, Jose Pereda, Geertjan Wielenga, Jens Deters)
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Blog-Autor*in
Jens Deters
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.