Skip to main content

Programming Micro:bit remotely

The Micro:bit track of our local Coderdojo went virtual during a COVID-19 peak. This created a challenge: not all kids have Micro:bits at home, and the makecode Micro:bit simulator doesn't simulate all extensions and functions. We provided an e-mail gateway to remotely program Micro:bits, with a live webcam view of the running programs. Our solution runs on a Linux machine, which could be a regular PC or even a Raspberry Pi. Please make sure your Linux box can power the Micro:bits and the extensions you connect, or otherwise use a powered USB hub to connect them.

Create a mailbox 

We created a dedicated mailbox that is accessible via IMAP or POP3. In our case, we used a local mailserver, but an account at an external e-mail provider could be used as well. 

Install fetchmail and procmail 

Fetchmail can poll an IMAP or POP3 mailbox and save the fetched mails locally. Local delivery is done via procmail. Our fetchmail config is

#### .fetchmailrc


 set daemon 60

 set logfile fetchmail.log


 poll mailserver-FQDN proto POP3

  user "mail-username" pass "mail-password" is "pi" postconnect "/home/pi/microbit/munpack-microbit.sh"

  ssl

  fetchall

  no keep

  no rewrite

  mda "/usr/bin/procmail -f %F -d %T";


Our local user is "pi", and we poll our mailbox every 60 seconds. The postconnect script will unpack the attachments and write them to the Micro:bit (see below). We need the mail messages containing the Micro:bit programs as separate files, so we configure procmail to save them in Maildir format. Our .procmailrc

#.procmailrc.

#

SHELL=/bin/bash

LINEBUF=4096

PATH=/bin:/usr/bin:/usr/local/bin:/opt/local/bin

VERBOSE=off

MAILDIR=/home/pi/maildir

DEFAULT=$MAILDIR/inbox/ # See the slash!

LOGFILE=$HOME/procmaillog

FORMAIL=/usr/bin/formail

SENDMAIL=/usr/sbin/sendmail


## save everything in Maildir format in ~/maildir

#

:0

$MAILDIR/

This means the fetched mails will be saved as individual files in ~pi/maildir/new/

Install mpack 

The mpack package provides the munpack command, which saves attachments from mail files. We integrate unpack into a shell script that copies the attached .hex files to the Micro:bit USB mass storage device: munpack-microbit.sh

#!/bin/bash


ls ~pi/maildir/new/???* 2> /dev/null > /dev/null || exit 0


for mailfile in ~pi/maildir/new/*; do 

        munpack -C ~pi/microbit/ $mailfile ; 

        mv $mailfile ~pi/maildir/cur/ ;

done


disklist=""

for disk in $(echo "sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl sdm sdn sdo"); do

        [[ -L /sys/block/$disk ]] && [[ "$(cat /sys/block/$disk/size)" -le "131200" ]] && disklist="$disklist $disk"

done


for disk in $(echo $disklist); do

        if [[ -L /sys/block/$disk ]]; then

                #[[ "x$(cat /sys/block/$disk/size)" -eq "x16512" ]] || continue #flash size old Micro:bit firmware

                #[[ "x$(cat /sys/block/$disk/size)" -eq "x131200" ]] || continue #flash size new Micro:bit firmware

                [[ "$(cat /sys/block/$disk/size)" -le "131200" ]] || continue # only continue on small disks

                [[ -d /tmp/$disk ]] || mkdir /tmp/$disk

                [[ -e /tmp/$disk/MICROBIT.HTM ]] || sudo mount -t vfat /dev/$disk /tmp/$disk

        fi

done

ls ~pi/microbit/*.hex 2> /dev/null > /dev/null || exit 0


for hexfile in ~pi/microbit/*.hex ; do

        #echo $hexfile | grep -iq scroll && disklist="sdh sdi sdj" # use fixed disklist for scroll:bit

        #echo $hexfile | grep -iq halo && disklist="sdg" # use fixed disklist for Kitronik ZIP Halo

        [[ -d ~pi/microbit/used ]] || mkdir ~pi/microbit/used

        for disk in $(echo $disklist); do

                [[ -e /tmp/$disk/MICROBIT.HTM ]] && sudo cp $hexfile /tmp/$disk/

                sudo sync

        done

        mv $hexfile ~pi/microbit/used/

done

exit 0


Note that some actions like mount require root privileges, so the user running this (pi, in our case) needs passwordless sudo privileges. 

Run it

Now start fetchmail: fetchmail -f ~pi/.fetchmailrc . You can monitor the fetchmail log file (see fetchmailrc) using tail -f. Fetchmail will run as a daemon until you stop it using fetchmail -q. 


Comments

Popular posts from this blog

Volkswagen UHV bluetooth touch adapter & its problems

My Volkswagen car has the "universal cellphone preparation" UHV built-in. This is the main part of a car kit, but requires an additional adapter for connecting to a cellphone. At first, I was using an adapter for my good old Nokia 6310, even after I changed to the Nokia E71. Connecting was easy: pair the phone with the "VW UHV" bluetooth entity, and done. This has the phone connected to the car kit at all times, so even non-call-related functions use the car audio system (e.g. voice recognition). But progress will have its way, no matter what happens. So in comes the "bluetooth touch adapter". Instead of a phone-specific adapter, this is a small touchscreen device that slots into the UHV dashboard mount. Connecting a phone is very different now: the Bluetooth Touch Adapter connects to the "VW UHV" device via bluetooth the phone connects to "Touch Adapter" device, also via bluetooth The device doesn't allow step 2 if step 1 didn'

Reset lost root password on vSphere ESXi 6.7

VMware's solution to a lost or forgotten root password for ESXi is simple: go to  https://kb.vmware.com/s/article/1317898?lang=en_US  and you'll find that "Reinstalling the ESXi host is the only supported way to reset a password on ESXi". If your host is still connected to vCenter, you may be able to use Host Profiles to reset the root password, or alternatively you can join ESXi in Active Directory via vCenter, and log in with a user in the "ESX Admins" AD group. If your host is no longer connected to vCenter, those options are closed. Can you avoid reinstallation? Fortunately, you can. You will need to reset and reboot your ESXi though. If you're ready for an unsupported deep dive into the bowels of ESXi, follow these steps: Create a bootable Linux USB-drive (or something else you can boot your server with). I used a CentOS 7 installation USB-drive that I could use to boot into rescue mode. Reset your ESXi and boot from the Linux medium. Ident

GEM WS2 MIDI System Exclusive structure and checksums

MIDI is the standard for communication between electronic music instruments like keyboards and synthesizers. And computers! While tinkering with an old floppy-less GEM WS2 keyboard, I wanted to figure out the structure of their System Exclusive memory dumps. SysEx is the vendor-specific (and non-standard) part of MIDI. Vendors can use it for real-time instructions (changing a sound parameter in real-time) and for non-real-time instructions (sending or loading a configuration, sample set, etc.). In the GEM WS2, there's two ways of saving the memory (voices, globals, styles and songs): in .ALL files on floppy, and via MIDI SysEx. The .ALL files are binary files, 60415 bytes long. The only recognizable parts are the ASCII encoded voice and global names. The SysEx dumps are 73691 bytes long. As always in MIDI, only command start (and end) bytes have MSB 1, and all data bytes have MSB 0. The data is spread out over 576 SysEx packets, preceded by one SysEx packet with header informat