von Ralf Beesner
micro:bit - eigentlich ein gruseliges Konzept
Wer sich nicht völlig unbedarft im Web bewegt, weiß, dass man dort mit
seinen Daten zahlt. Die werden besonders in den USA von zahlreichen
Firmen zu Profilen gebündelt und verhökert. An andere Firmen, die damit
"zielgerichtete" Werbung verkaufen wollen, an Webshops, die den Leuten
je nach vermuteter Finanzkraft automatisiert unterschiedliche Preise
machen oder an Banken, die ihre Kundschaft nach Kreditwürdigkeit ranken
wollen. Gegenwehr (mit Firefox-Browser-Plugins wie NoScript und
RequestPolicy) ist vielen Leuten zu mühsam.
Der Spruch von den "Digital Natives" mit dem sich die junge,
mit dem Internet aufgewachsene Generation von den Alten abgrenzen
wollte, hat sich auf sarkastische Weise bewahrheitet: die "Digital
Natives" tauschen (wie damals die "Analog Natives" bei der Eroberung
Mittelamerikas) bei den digitalen Konquistadores ihr Gold gegen
Glasperlen ein. Dass sie übers Ohr gehauen werden, sieht man ja am
besten an den explodierenden Aktienkursen von Google und Fakebook.
Die Online-Programmierung des BBC micro:bit repräsentiert
daher so ziemlich alles, was mir bedenklich erscheint, denn sie
funktioniert nur mit reichlich Javascript, und Javascript ist die
Schlüsseltechnologie beim "Abschnorcheln" der User. Mit dem micro:bit
werden schon die Kinder darauf trainiert, dass "das Web ohne Javascript
nicht funktioniert".
Wegen der zu erwartenden starken Verbreitung des micro:bit
lohnt sich zwar die nähere Beschäftigung mit der Hardware und mit
MicroPython, aber die einzige (für einen senilen Geisterfahrer wie
mich) akzeptable Variante ist die Offline-Programmierung, z.B. mit dem
mu-Editor.
Dem mu-Editor unter die Motorhaube geschaut
Der micro:bit hat von der mbed-Familie geerbt. Während
Mikrocontroller üblicherweise per ISP-Programmierung oder mittels
seriellem Bootloader geflasht werden (eine Teilmenge der Bootloader
wird auch dfu - "device firmware upgrade" genannt), hat sich mbed ein
anderes Verfahren namens "DAPLink" ausgedacht.
Ein zweiter Chip auf dem Mikrocontroller-Board übernimmt die
Kommunikation mit dem PC. Er ist mit der DAPLink-Firmware geflasht, die
per USB parallel zwei Kanäle bereitstellt: einen für das Flashen des
Hauptchips - das Board präsentiert sich dafür als virtueller
Massenspeicher - und einen weiteren für eine UART-Verbindung, die für
das Debugging gedacht ist.
Unter diesem Link ist das Konzept erläutert:
http://tech.microbit.org/software/daplink-interface/
Der UART-Kanal kann ebenfalls von Anwenderprogrammen genutzt
werden, die als Firmware auf den Hauptchip geladen wurden. Leider ist
der virtuelle Massenspeicher, den DAPLink dem PC vorgaukelt, nur ein
Fake: nachdem man die Firmware (als HEX-File) auf das virtuelle
Laufwerk kopiert hat, meldet sich der "Massenspeicher" vom PC ab und
das Firmware-File ist weg, wenn er anschließend automatisch wieder neu
verbunden wird.
Man kann auf diesem Wege also keine Files mit dem micro:bit
austauschen; das geht nur über die serielle Schnittstelle mit einem
Workaround, den der mu-Editor unter dem Menüpunkt "Files" bietet, und
ist auch nur für Datenfiles gedacht - nicht für Python-Programme.
Wegen dieser Schwächen kann man man sein Python-Programm, das
ja nur wenige kB groß ist, nicht einfach direkt auf den micro:bit
übertragen (eigentlich ist der Python-Interpreter ja bereits auf diesem
vorhanden und aktiv). Nein, der mu-Editor wandelt den kleinen
Quelltext, den man im mu-Editor geschrieben hat, in ein HEX-File, hängt
es an das fast 700 kB große MicroPython-HEX-File an, überträgt beide
über das virtuelle Massenlaufwerk auf den micro:bit, und dort wird der
angehängte Quelltext dann wieder abgetrennt, zurückgewandelt und
automatisch ausgeführt.
Daher "darf" man nach jeder kleinen Änderung am Quelltext etwa
15 Sekunden meditieren, während der bereits auf dem micro:bit
vorhandene Interpreter wieder und wieder mit einer identischen Kopie
überschrieben wird. Das hat mich "rappelig" gemacht!
Ein Workaround für kurze Ladezeiten
Auf dem seriellen Kanal hat man ja Zugang zum
MicroPython-Interpreter; wenn man im mu-Editor auf "Repl" clickt,
landet man auf der MicroPython-Kommandozeile (Repl steht für
"Read-Eval-Print-Loop").
In dieses Fenster kann man im Prinzip auch Code
hineinkopieren. Also - Code im mu-Editor schreiben (er liegt dann noch
auf dem PC), markieren, kopieren, das "Repl"-Fenster öffnen und den
Code dort einfügen (dann befindet sich die Kopie auf dem micro:bit).
Dummerweise versucht der/die/das Repl, schlau zu sein und
editiert die hineinkopierten Zeilen sofort mit seiner
"autoindent"-Funktion. Bereits eingerückte Quellcode-Zeilen werden so
noch einmal eingerückt, alles ist durcheinander.
Aber Hilfe naht:
Wenn man im Repl "help()", eingibt, spuckt es unter anderem aus:
Control commands:
CTRL-C -- stop a running program
CTRL-D -- on a blank line, do a soft reset of the micro:bit
CTRL-E -- enter paste mode, turning off auto-indent
Daneben gibt es noch (durch Ausprobieren gefunden):
Ctrl-A raw REPL; CTRL-B to exit
Ctrl-B exit raw repl
Man sollte also das Repl mit (Control-e) in den "enter paste mode"
schalten können (bzw. mit (Ctrl-a) in den "raw repl mode"), den Code
per copy&paste einfügen und diesen mit (Ctrl-d) durch einen "soft
reset" starten können.
Klingt gut, klappt aber zumindest in meinem mu-Editor nicht. Anscheinend filtert der irgendwas weg.
Auch die meisten "großen" und bekannten Terminalprogramme
reichen nicht alle Ctrl-Befehle an die serielle Schnittstelle durch.
Ich verwende jedoch seit vielen Jahren ein winziges serielles
Terminalprogramm, das kein eigenes GUI hat, sondern im XTerm, also auf
der "Linux-Kommandozeile" läuft. Der Quellcode ist nur 8 kB groß, steht
unter einer freizügigen Lizenz und findet sich unter
http://www.brokestream.com/tinyserial.html.
Es ist "sauschnell" und und reicht fast alle Ctrl-Kommandos wirklich durch. Nur (Ctrl-a) und (Ctrl-x) sind belegt.
Da (Ctrl-a) für den micro:bit benötigt wird, habe ich die
Beenden-Funktion auf (Ctrl-o) umgelegt. Der geänderte Quellcode und
bereits kompilierte Binaries für RasPi 2/3, Intel Linux 32bit und
Intel/AMD Linux 64bit sind beigefügt.
Aufgerufen wird das Programm mit "como /dev/ttyACM0 115200" und beendet mit (Ctrl-o).
Es geht noch einfacher mit Linux-Bordmitteln oder mit Python
Man kann direkt auf der "Linux-Kommandozeile" Befehle an das
Repl auf dem micro:bit senden. Das lässt sich auch einfach mit einem
kleinen Skript automatisieren, ich habe es "ubitflash" genannt und
ebenfalls beigefügt. Man kopiert es nach /usr/local/bin und überträgt
Python-Programme mit "ubitflash programmname.py"
Nutzt man statt des mu-Editor eine IDE, z.B. Geany, kann man
das Hochladen auch auf eine Funktionstaste bzw. ein Icon in der
Menüzeile der IDE legen. Dafür eignet sich die weniger geschwätzige
Version "ubf" besser.
Auch eine Python-Version, die man für Windows anpassen kann, ist beigefügt.
Die Skripte verwenden folgende Befehle:
stty -F /dev/ttyACM0 115200 # PC-Baudrate auf 115200 bit/s setzen
echo -e "\002" > /dev/ttyACM0 # raw mode vorsorglich beenden (falls der microbit noch im raw mode ist)
echo -e "\003" > /dev/ttyACM0 # das laufende Programm beenden, Wechsel auf Python-Kommandoprompt
echo -e "reset()\r" > /dev/ttyACM0 # altes Programm überschreiben
echo -e "\001" > /dev/ttyACM0 # (Ctrl-A) ans Repl senden, schaltet in "raw mode"
cat $1 > /dev/ttyACM0 # Python-Code als Liste nach /dev/ttyACM0 senden
echo -e "\004" > /dev/ttyACM0 # (Ctrl-D) senden, löst "soft reset" aus und startet so das Programm
Die Befehle zwei bis vier sollen den micro:bit in möglichst
jedem Zustand "einfangen". Zwei Haken hat der schnelle Upload jedoch:
- große Python-Files (> 3,5kB) quittiert MicroPython mit
Fehlermeldungen. Ich hatte den Verdacht, dass es an einer zu schnellen
übertragung mit dem cat-Befehl liegt, aber mit einer "verlangsamten"
Python-Version tritt der Effekt auch auf
- drückt man den Reset-Knopf des micro:bit oder trennt ihn von
der Betriebsspannung, ist das Programm weg (ein auf dem "offiziellen
Weg" als "HEX-Anhängsel" hochgeladenes Python-File überlebt im
Flashspeicher und wird nach dem Reset erneut gestartet)
Um für klare Verhältnisse zu sorgen, sollte man einmalig
MicroPython ohne angehängtes "HEX-Anhängsel" auf den micro:bit
übertragen. Dazu öffnet man einfach im mu-Editor ein neues leeres
Projekt und lädt es mit dem Menüpunkt "Flash" auf den micro:bit hoch.
Eine generelle Empfehlung: Will man in eigenen Programmen die
serielle Schnittstelle nutzen, sollte man ebenfalls 115200 bit/s
verwenden, da das die "natürliche" Repl-Bitrate ist - dann gibt's
keinen Ärger,wenn man nicht weiss, ob gerade das Repl oder das eigene
Programm am Zuge ist (gilt auch bei Verwendung des mu-Editors).
Fazit
Wenn der micro:bit noch neu ist und man zahlreiche
Code-Beispiele durchprobieren möchte, sind die 15s Wartezeit bei jeder
Übertragung eine ziemliche Qual, und es ist recht angenehm, wenn man
die Upload-Zeit auf etwa 2s verkürzen kann.
Wenn man dazu neigt, selbstgeschriebenen Code lieber kurz
auszuprobieren, statt lang drüber nachzudenken, wird man vom mu-Editor
gnadenlos mit 15 Sekunden Wartezeit bestraft. Mir fällt meist noch
während der Wartezeit auf, was ich zu ändern vergessen habe. Mit dem
"ubitflash" kann ich meinen chaotischen Programmierstil reuelos
beibehalten ;)
Update 1:
"ubitflash" gibt so viel Text aus, dass darin ziemlich
untergeht, wenn das übergebene Python-File nicht vorhanden ist (z.B.
aufgrund eines Schreibfehlers). In der aktualisierten Version wird
zunächst getestet, ob das File existiert.
Das vorgestellte Programm "como" blockiert übrigens die verwendete
serielle Schnittstelle des PCs nicht in Senderichtung. Man kann daher
unter Linux "como" in einem XTerm laufen lassen - sieht dort also die
Repl-Ausgaben - und kann in einem zweiten XTerm parallel das
Python-Code mit "ubitflash" hochladen. Wenn der Code fehlerhaft war,
kann man die Repl-Fehlermeldung komfortabel im ersten XTerm lesen. Das
läuft so gut, dass ich den mu-Editor nur noch in Sonderfällen nutze.
Download der Programme: 0517-ubit-fuer-ungeduldige.zip
Elektronik-Labor Projekte Microbit
micro:bit für Ungeduldige