Die Ausführung von Hochsprachen auf Mikrocontrollern trägt - seit jeher - zu einer Reduktion der Code-Koppelung in der Gesamtlösung bei. Mit Kaluma steht eine Runtime zur Verfügung, die auf die Bedürfnisse von Ebenezer Uptons Mikrocontrollerfamilie optimiert ist.
In diesem Artikel werden wir Experimente mit der Architektur und der Runtime durchführen, um mehr über Handling und internen Aufbau der Engine zu erfahren. Grundkenntnisse im Bereich der Mikrocontrollerhardware werden dabei als gegeben vorausgesetzt.
Auswahl der Zielarchitektur.
Der RP2040 wird - Drittanbieterboards wollen wir an dieser Stelle ignorieren - vor allem in zwei Varianten angeboten. Einerseits gibt es den alleinstehenden Raspberry Pi Pico, während sein später ausgelieferter und mit einem Infineon-WLAN-Modul ausgestattete Kollege Raspberry Pi Pico W mittlerweile ebenfalls gut verfügbar ist. Zum Zeitpunkt der Drucklegung dieses Artikels gilt dabei, dass Kaluma in Version 1.0 nur den „klassischen“ Pico unterstützt. Unterstützung für die WLAN-fähige Variante ist - siehe Abbildung - erst für die derzeit noch als Beta vorliegende Version 1.1 geplant.
Bildquelle: https://kalumajs.org/download/.
Von der Architektur
Nach dem Ende der (für die Javascript-Performance-Steigerung primär verantwortlichen) Browserkriege hat sich Node.JS und die diversen Projekte als quasi Standard für alles, was da Javascript interpretiert, herauskristallisiert. Im Fall von Kaluma gilt dabei, dass die eigentliche Javascript-Intelligenz durch das quelloffene Projekt JerryScript gestellt wird. Der Code der Runtime findet sich dann auf GitHub unter https://github.com/kaluma-project/kaluma und steht unter der Apache-Lizenz. Im Bereich der auf dem Mikrocontroller zur Ausführung gelangenden Software setzt man auf einen zweigleisigen Approach: Im ersten Schritt wird die in Form einer .UF2-Datei vorliegende Javascript-Runtime auf den Controller geladen. Sie kommuniziert danach über einen simulierten seriellen Port mit einer Node.JS-Anwendung, und legt die auszuführenden Javascript-Dateien im Remanentspeicher des Controllers ab. Dieser auf den ersten Blick pedantisch klingende Hinweis ist von wichtiger Bedeutung: Tötet eine Javascript-Datei die Runtime und blockiert die Kommunikation mit der Mater-Anwendung, so gilt, dass ein „reines“ Deployen der Runtime nicht zur Wiederherstellung eines funktionsfähigen Zustands ausreicht. Stattdessen ist unbedingt auch die Nutzung der unter der URL https://github.com/dwelch67/raspberrypi-pico/blob/main/flash_nuke.uf2 bereitstehenden Flash Nuke erforderlich; das Deployment der anderen .UF2 -Datei darf erst danach erfolgen. Apropos Deployment: Auf Seiten der Workstation ist die Installation des Pakets kaluma/cli erforderlich. Je nach Konfiguration Ihres Systems ist dazu eine der beiden folgenden Befehle zu verwenden:
1 |
|
2 |
|
Analyse der inneren Architektur der Runtime.
Im nächsten Schritt bietet es sich an, folgendes Programm zur Ausführung zu bringen. Es enthält eine Endlosschleife, die permanent eine Rechteckwelle am GPIO-Pin ausgibt:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
Speichern Sie den Javascript-Code in einer mehr oder weniger beliebigen Textdatei, und erledigen Sie die Auslieferung nach folgendem Schema über die Node.JS-Companionapplikation:
An einem angeschlossenen Digitalspeicheroszilloskop ist dann die gezeigte Wellenform zu sehen.
Bildquelle: Autor.
Die erfolgreiche Ausgabe der Wellenform informiert uns darüber, dass der Zugriff auf die Hardware in Kaluma synchron implementiert ist. Problematisch ist allerdings, dass eine Endlosschleife keine Rechenzeit an das Betriebssystem bzw. die zugrunde liegende Infrastruktur abtritt. Bei Annahme von kooperativem Multitasking gilt dann, dass die Kommunikation mit der CLI-Applikation nicht mehr möglich ist. Diese Annahme ist dadurch bestätigbar, dass die Ausführung des nächsten Flashbefehls scheitert – unter https://youtu.be/g9WbyE8tHYs findet sich ein Video, das dies en Detail demonstriert. Eine funktionsfähige Variante des Programms würde nach folgendem Schema auf SetInterval setzen:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
Zu beachten ist allerdings, dass die von dieser Variante ausgegebene Wellenform wesentlich langsamer ist.
Interaktion mit Hardware
Die Durchführung von Bit Banging-Experimenten erlaubt interessante Rückschlüsse auf die Architektur des zugrunde liegenden Systems. In der Praxis gilt aber, dass Hardware-Zugriff heute - normalerweise - über die diversen im Controller implementierten Hardware-Peripheriegeräte erfolgt, die die verschiedenen Bus-Protokolle ohne permanente Überwachung des Hauptprozessors umsetzen. Die Kaluma-Ausführungsumgebung implementiert schon zum Zeitpunkt der Drucklegung dieses Artikels so gut wie alle am RP2040 befindlichen Interfaces. Unter der URL https://kalumajs.org/docs findet sich dabei die umfangreiche Dokumentation, während unter https://github.com/kaluma-project/examples schlüsselfertige Beispiele verfügbar sind.
Fazit
Trotz des noch vergleichsweise frühen Entwicklungsstands gilt, dass Kaluma die Ausführung von Javascript am RP 2040 ermöglicht. Wer in seinem Unternehmen Javascript-IP hält, kann durch Nutzung dieses Systems Duplikation im Gesamtsystem reduzieren und die Wartbarkeit erhöhen. Dies ist ökonomisch sinnvoll - dass man als am Achtbitter mit Assembler aufgewachsener Entwickler dabei eine große und dichte Nasenklammer braucht, gibt der Autor allerdings vollumfänglich zu.
-
rp2040JavaScript.jpg
(240 KB)
-
1.png
(130 KB)
-
2.jpg
(230 KB)