micro:bit für Ungeduldige 

von Ralf Beesner

           
Elektronik-Labor   Projekte   Microbit 



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 ;)



Download der Programme:  0517-ubit-fuer-ungeduldige.zip


Elektronik-Labor   Projekte   Microbit