Using a microbit to control a servo motor

Subtitle: Making things move a microbit at a time

In this post I explain how I set up and operated a small servo motor that runs directly from the same 2xAAA battery pack that powers my microbit. I then explain how to operate a servo motor that requires a 5V power supply from the same microbit, using a transistor as a voltage level converter for the control signal.

Introduction

I set up a small servo motor for a project to make an automated guinea pig feeder. Details on how to use this are here. Naturally, mistakes were made. I will detail the hardware setup, explain the control signals for the servo and show where the software can be found.

Hardware: SG51R servo motor

I used a Tower Pro SG51R servo motor, which runs from the same 2xAAA battery pack as the microbit. The battery pack, microbit and servo motor can be seen in the photo below. I slotted the microbit into a Kitronik edge connector.

2xAAA battery pack, microbit in a Kitronik edge connector and a SG51R servo motor

I got my SG51R servo motor from the Pi Hut here.

Why use this servo motor?

The SG51R works using a 2xAAA battery pack as the power supply, while many other servo motors require a higher voltage than 2xAAA batteries produce. This means it can run direct from the same battery pack used to power your microbit.

The manufacturer’s website says that this servo motor requires 4.8V to operate. However, it works fine with the 2.4V or so that we get from the 2xAAA rechargeable battery supply I use to power the microbit. This is great, as it means I don’t need to use a different voltage supply to power the servo motors with.

The servo has three wires for power and control. The black wire is for ground, the red wire for the voltage supply and the orange wire is the control signal.

The wires from the Kitronik edge connector to the servo motor connector can be seen in the photo below. I used D0 as the pin to output the servo motor control pulses on. The labels on the microbit are guides as how to use the microbit for the guinea pig feeder project.

The photo below shows how the wires from the microbit connect to the servo motor plug. Black is ground, red is positive voltage, yellow is the signal, from pin D0 on the microbit.

Wires from the microbit on the left, servo motor connector on the right

A servo typically responds to a control signal of a pulse between 1 ms and 2 ms long within a 20ms period. 180° needs a 1 ms pulse.

So what does that look like? The software I wrote to drive the servo motor is at the end of this article. I put an oscilloscope onto the signal pin. Here’s what it looks like:

Servo motor controller pulses

We see a positive pulse every 20 ms. Remember that these pulses go from ground to the battery voltage (about 2.4 V in this plot). We will revisit this polarity when we talk about driving a 5 V servo motor later in this post. The width of this pulse sets the angle of the servo motor. The pulse must occur within the same 20 ms window, just how much of this window it takes up changes.

From the data sheet for the SG51R:

This servo is pulse controlled. This means that supplying a pulse will move it to a particular angle. In this case 0° is a 1.5 ms pulse, 90° a 2 ms pulse and -90° is a 1ms pulse. This may not be set by your controller by default or give you the full range of movement as such you may wish to try up to 2.25 ms and as low as 0.75ms. Be aware that if you go to far you can break the servo.

Using my ‘scope, I could see that the servo motor responds to pulses with a width from 0.57 ms to 2.58 ms. Remember that the window that these pulses occur in remains as 20 ms wide. Just the width of the control pulse changes to take up more or less of this 20 ms.

Software

Initially I carefully crafted beautifully structured micropython code in classes. Then ran out of memory, so ripped out all of the classes and bludgeoned the code to fit into the memory of the microbit.

I did, of course, find example software elsewhere on the ‘net to get started and apologise that I can’t remember which site I found this on to give proper credit.

The code can be found in the file called feeder.py on my GitHub site at: https://github.com/hardwaremonkey/microbit_projects

5V servo motor MG90D

Maybe you need a more powerful servo motor for your application. In this case, you will probably need one that requires a higher voltage than we get from the battery pack for the microbit. This section explains how to control a servo motor that is running from a separate power supply using a battery-powered microbit.

The mg90d is a servo motor that requires a higher voltage than the microbit can supply to operate. I ran it at 5V from a power supply. So how do we set up our microbit to control this?

I used a 2n2222 transistor to interface the microbit with the servo motor control wire. The control signal from the microbit goes to the base of the transistor. There is a 1K Ohm current limiting resistor in between this signal from the microbit and the base of the transistor. The signal going to the base of the transistor switches the transistor on and off.

The collector of the transistor connects to the 5V power supply through a 100 Ohm resistor.

Remember: We are only using the transistor to change the voltage level of the control signal. The voltage for the servo motor comes directly from the +5V power supply.

When the control signal from the microbit goes high, the transistor turns on. When the control signal goes low, the transistor turns off.

Find the wiring diagram below. The images come from Fritzing, though I made the diagram in Inkscape.

Circuit layout showing how to power and control a 5V servo using a microbit and a 2N222 npn transistor

There is one catch with this circuit – the control signals become inverted. You might ask – why not tap the signal from the emitter of the transistor, not the collector, then the signal would not be inverted. However, doing this produces an output signal going to the servo motor of lower voltage than the signal coming into the base of the transistor. Which defeats the object. There is about a 0.6V drop between the base and emitter of a typical bipolar transistor.

The simple answer is to invert the control signal coming from the microbit. I did this. See the oscilloscope grab below, showing the inverted control signal from the microbit in yellow and the non-inverted control signal going to the servo motor in blue. Note the different voltage levels. The signal from the microbit is around 2.4 V in amplitude and the signal going to the servo is about 5 V in amplitude.

Inverted controller signal from microbit is yellow, signal from transistor emitter to servo is blue

I put the micropython code needed to generate both a non-inverted and an inverted pulse below so you can see the simple trick needed to invert the pulse.

   def set_ms_pulse(self, ms_on):
        # pin.write_analog(1023) is constant on pulse
        # (1023 * ms_on / 20) gives a pulse of length ms_on
        self.pin.write_analog(1023 * ms_on / 20)

    def set_ms_pulse_invert(self, ms_on):
        ''' Gives inverted logic servo control pulse. '''
        self.pin.write_analog(1023 - 1023 * (ms_on / 20))

This worked to operate the 5V servo motor. The transistor allows us to drive the servo motor using the output of a battery powered microbit.

Another component that allows us to drive a device requiring a voltage that is not compatible the part that generates the control signal is an opto isolator. This is a story for another day.

As always, comments are welcome.

BBC micro:bit guinea pig timed feeder instructions

This blog post is the instructions on how to use a timed servo motor circuit that I lashed up as part of a guinea pig feeder for a friend.

The hardware details can be found here: here

Software is on my GitHub site here

The need

A friend wanted something to open a box of food to feed his guinea pigs. The box needs to open after an adjustable time.

I can think of no more noble cause to focus on than feeding our furry friends.

After a period of procrastination and confusion I supplied the hardware and software detailed in this post. The mechanical components that the device will operate are up to my friend to make. He is a highly experienced mechanical engineer. I am but a lowly electronics tech.

Between the two of us, the guinea pigs will be fed!

Description

The microbit counts down for a preset amount of time. The remaining time is indicated on the LEDs on the microbit. At the end of the pre-set time, the servo motor lever moves 90 degrees. The two positions of the servo motor are shown in the pictures below.

The timer is adjusted using the A and B buttons as detailed in the Instructions section below.

Servo motor position while the timer is in operation
Servo motor position once the timer completes the countdown

Instructions for use

The A button adds 12 minutes to the timer. An extra LED will light up for each press of the button. The B button decrements 12 buttons from the timer. An LED will turn off for each press of the button. The photograph below shows two lit LEDs on the microbit, indicating 24 minutes or less are left on the timer.

The two lit LEDs indicate that 24 minutes are left until the servo motor is activated

The last timer setting is recorded to the memory on the microbit. When the board is reset, it will start counting down from this time. So, if you set the timer to 2 hours (10 LEDs lit), on resetting, you will see 10 LEDs lit up and the board will take 2 hours to trigger the servo motor.

The reset button on the back of the board restarts the board. Please see the photograph below which shows the position of this button.

Underside of the microbit with the rest button indicated, next to the battery connector

Hardware description

The components of the system are shown in the picture below. On the left is a AAA battery pack containing 2 x AAA batteries. I use battery packs with a switch, which I get from eBay. The microbit is in the centre, slotted into a kitronik microbit edge connector. This edge connector allows the signal pins of the microbit to be connected to the servo motor using female to male jumper cables . The cables are designed for the 0.1″ pins and sockets found on the edge connector and the cable connected to the servo motor.

AAA. battery pack, microbit, servo motor

The full assembly including cabling is shown in the photo below.

AAA battery pack (right), microbit and edge connector board (centre), servo motor (top), connectors (right)

A close up photo showing how the cables from the edge connector and the servo motor connector are connected is shown below. The black/brown wires are ground, the red wires are the battery voltage and the yellow wire is the PIN0 signal line.

Pins from cables connected to the Kitroniks edge connector on the left, sockets connected to the servo motor on the right

The photo below shows how the cables connect to the pins on the Kitronik edge connector.

Cables connected to the Kitronik edge connector. Yellow goes to 0, black to 0V, red to 3V.

BBC micro:bit wrist holders

With my handshake project, a microbit and AAA battery pack need to be worn on the wrist. They can be vigorously shaken. I don’t want the equipment flying off! So what can I use that will hold the microbit and batteries safely in place and is comfortable and safe to wear?

I tried a couple of armband holders aimed at iPods recently. Both of them are suitable for housing a BBC microbit and a AAA battery pack. Prior to this, I used a wrist holder that I made myself.

The advantages of repurposing an iPod arm band holder instead of making one yourself are:

  • Saves you the time of making one.
  • The clear plastic cover makes it easy to clean.

Please find photographs of the armband holders I tried out as wrist holders containing a microbit and AAA battery holder below. First a top-tip!

Velcro tabs to secure armband straps

Whichever armband you re-purpose to be a wrist holder, as the wrist is narrower than your arm, the end of the strap will no longer stick down. The end will flap free. As this end of the strap has the hook velcro on it and the rest of the strap is the loop kind, the strap will no longer stick down to itself. You need to make some double sided hook velcro tabs. See the photo below.

Double sided hook velcro tabs

These are lengths of sticky back hook velcro, stuck back to back. Place them on the loop velcro to enable the strap to stick to itself when used on the wrist.

TuneBelt Armband for iPod touch 4G

The TuneBelt iPod touch 4G armband holder can be used to hold a microbit and AAA battery pack as shown in the photo below. Use some double sided velcro hook ‘gender bender’ strips to allow the strap to stick to itself when used on the wrist.

iPod touch 4G arm band in use as a microbit and AAA battery pack wrist holder
TuneBelt iPod touch 4G used as a microbit and AAA battery pack holder, front view

arm band in use as a microbit and AAA battery pack wrist holder

TuneBelt Sport Armband iPod touch 4G box
 

igagdgitz iPod classic armband holder

Larger than the iPod touch 4G holder. Costs about twice as much – about £10 from eBay. The build uses thicker neoprene. The rear panel folds down to allow easy installation and removal of the microbit and battery holder. This is made from a decent thickness of neoprene and is held securely in place with velcro on three sides.

The strap is longer and bulkier than the iPod 4G holder . If you know you are going to use this arm band as a wrist holder, it would be worth trimming the strap down. Then you would rely on the velcro double-sided tabs to stick the strap down unless you sewed some hook velcro on to replace the tab that you had cut off when shortening the strap.

iPod classic arm band in use as a microbit and AAA battery pack wrist holder
igadgitz iPod classic holder, front view, containing BBC microbit and AAA battery holder. There are two velcro tabs near the plastic to enable the strap to latch onto itself when worn on the wrist.

 
Rear view, showing fold down flap which allows acccess to the interior

Automating loading micropython code to the BBC micro:bit in Linux

Introduction

When I edit micropython for a microbit project, I want the code to automagically load onto the microbit each time that I save the code. Then I want to see any messages from the microbit displayed. I worked out a toolchain that does this under Linux.

I summarise the toolchain in the next section, then go through each step in more detail.

For the examples in this post, I am editing a file called ‘feeder.py’.

Toolchain

Use your favourite editor for creating your code with. The toolchain to load the code to the microbit kicks off when you save the file.

There are four tools needed to automate the process.

  • A script to locate and mount the microbit. I wrote a blog post about this script here.
  • The uflash utility to write the micropython file to the microbit.
  • screen terminal to display messages from the microbit
  • inotifywait command to monitor the micropython file being edited

uflash

Use pip to install this. Details are in the link given earlier in this post. To load a_file.py to an attached microbit, simply type:

uflash a_file.py

Using virtual environments makes my life easier, so I use one for my microbit programming. There are plenty of blog posts detailing how to set up and use these.

script to attach a microbit

I wrote a blog post on how to create a script that automatically locates and mounts a microbit here. This script is aliased to mm and md in my .bashrc file to mount a microbit and dismount a microbit.

screen

screen is built in to most Linux distros, so I use it here. This connects to the port that is in use by the microbit and displays any output from the microbit.

You need to know what port your microbit is attached to though. On my laptop this is often /dev/ttyACM3, which I use in the example below.

I present a script in the next section to automatically find the port that the microbit is connected to and fire up a screen connection using this.

To fire up the connection manually, if you know the port (in this example /dev/ttyACM3) use:

screen /dev/ttyACM3 115200

Remember to kill screen without leaving it running in the background by using:

control-a k

One potential problem with screen, is that it is easy to ‘detach’ from screen instead of ending the process, which leaves an instance of screen running invisibly which is attached to the same port as the microbit. When you come to try and run screen or connect to the microbit again, you will see an error like the one below:

can't open device "/dev/ttyACM3" 

To find and kill the errant screen instance:

lsof | grep /dev/ttyACM3

If you get something like:

screen  8610  elm    5u   CHR  166,3      0t0 5599015 /dev/ttyACM3

You still have a screen instance attached to the port. The PID is the second value in the list, in this case 8610. Kill it using e.g.

kill 8610

One way to prevent this potential problem is to replace screen with another terminal display tool such as gtkterm.

script to automate finding and connecting to the microbit

The python3 script below automates finding a connected microbit. The script starts a screen session on the port that the microbit is connected to.

'''
Find pyboard or microbit and open a terminal.
Created on 4 Nov 2015.
From http://wdi.supelec.fr/boulanger/MicroPython/
Usage: find_device [device]
Calls screen on "device". If device is not given, looks for /dev/ttyACM* devices
then /dev/tty.usbmodem* devices (for MacOS).
'''
#!/usr/bin/python
import sys
import os
import fnmatch

BAUD = 115200

def main():
    if len(sys.argv) > 1:
        ttymodems = [sys.argv[1]]
    else:
        ttymodems = fnmatch.filter(os.listdir('/dev'), 'ttyACM*')
        if len(ttymodems) == 0:
            ttymodems = fnmatch.filter(os.listdir('/dev'), 'tty.usbmodem*')
        if len(ttymodems) == 0:
            print('Error: no pyboard found.')
            sys.exit(1)
        ttymodems[0] = '/dev/' + ttymodems[0]
        print('connection at: {}'.format(ttymodems[0]))
    os.system('screen '+ttymodems[0] + ' {}'.format(BAUD))

if __name__ == "__main__":
    main()

inotifywait

inotifywait is a command line tool that can be configured to watch a file for a change, then trigger an action. Here we use it to watch for a change in the micropython file being edited. When this file is saved, inotifywait mounts the microbit and flashes the file to it.

If infotifywait is not already installed, then you need to install inotify-tools.

The command to watch a file called feeder.py for a change, then run the alias mm (to mount the microbit) and to flash the file to the microbit is:

while inotifywait -e modify feeder.py ; do mm && uflash feeder.py ; done

I would have formatted the above line as the other code in this post but found that the syntax highlighter plug-in refuses to show the ampersand symbol correctly.

notes

Some editors have the ‘feature’ of ‘kind of’ saving the file you are editing while you are editing it. This creates a new timestamp for the file and activates inotifywait without your saving the file. mu is one of these editors. In this case, I do not use inotify and run the following command from the command line each time I want to flash the updated file. In this example the updated file is called feeder.py:

mm && uflash feeder.py

but why not use a Makefile

Makefiles are typically used to build programming projects, detailing the dependencies of each component. The file is run when ‘make’ is typed on the command line.

The one-liner command using inotifywait is fine for this simple example where we are editing a single file. Which is most of what I do with the microbit and micropython. Makefile comes into its own for more complex builds involving multiple files. It allows for extra run-time options to be added, e.g. to clean files created by earlier builds.

For completeness, I present a simple Makefile below for this project. Makefile is a useful tool that is worth learning to use for when we have larger projects to build.

Makefile

I created a Makefile containing commands to mount the microbit to the Linux filesystem, then flash a micropython file to the attached microbit.

An example Makefile is below. Note: Use tabs to create the indents after the line ‘run:’. Or the World Ends. The supporting file microbit_mount.sh is in the same directory as feeder.py to keep it simple.

MICROPYTHON_FILE=feeder.py

run:
	./microbit_mount.sh mount
	uflash $(MICROPYTHON_FILE)

In this example, microbit_mount.sh is the script to attach a microbit, detailed above.

uflash is the tool used to write the .py file to the microbit. This is detailed above.

To automate the Makefile being run each time that we save new code, we can use the inotifywait command below:

while inotifywait -e close_write feeder.py ; do make; done

Powering the BBC micro:bit with a 5V power bank

I had an interesting question to a blog post I made about running a DC motor from a microbit. The blog post is here. I am pleased that anybody reads my blogs.

Doesn’t applying 5V to the microbit board exceed the voltage spec?

When we connect the board to our laptops or PCs, we apply 5V to the board through the USB connector. Sometimes I run the board from a USB power bank. This supplies 5V to the microbit. The advantage of using the power bank over AAA batteries is that I can use the power bank to also run e.g. a DC motor. So far I have not cooked off a microbit doing this.

But I still only measure 3.2V on the pads on the board edge connector.

Why is this?

Let’s look at the board circuit schematics. Please find a screengrab showing the USB connector on the left and the microcontroller on the microbit on the right.

BBC micro:bit schematic fragment, showing USB connector and the microcontroller.

Let’s zoom in on the connector:

Schematic showing the USB connector.

The 5V input voltage on the USB connector is given the net label VBUS_IF. This label reappears next to the little number 5 – which means this is where the track connects to on the PCB. The zener diode to the left of the number 5 and the 10 Ohm resistor R31 to the right combine to protect the board in the case of reverse polarity – if somehow the voltage is applied to the USB connector backwards, the current flows to ground, not into the microcontroller.

The capacitor C31 and C33 are there to act as little charge stores for the microcontroller for when it needs a sudden ‘oomph’ of charge that the USB power supply cannot supply quickly enough. These are called decoupling capacitors.

The +5V signal is renamed VBUS_IF_2 to the right of R31. Lets look at where this goes into the microcontroller. I labelled the net VBUS_IF_2:

So our +5V USB voltage connects to the microcontroller on a dedicated pin VREGIN. This is the input to a regulator inside of the microcontroller. The output of this regulator is a DC voltage called +3.3V_IF. This output supplies the +3.3V seen elsewhere in the board and on the board edge connector pads.

Now, if the input to VREGIN is below 3.3V, we are not going to see 3.3V on the output pads. In fact, I see 3.2V with an input of 5V, so there is a 0.1V drop somewhere on the board.

So, in summary, we can apply 5V through the USB connector.

One last schematic fragment. This shows the battery connector and where this supply connects with the voltage generated by the internal regulator on the microcontroller:

Microbit schematic showing the battery connector and how it connects to the board voltage tracks.

The battery voltage goes through a low drop BAT60A schottky diode labelled D2. This then connects to V_TGT. This is the main voltage rail for powering most of the board components, such as the magnetometer and accelerometer. This is also the rail that connects to the board edge connector on the pad labelled ‘3V’.

Both the output from the microcontroller regulator, labelled 3.3V_IF and the voltage from the battery labelled VBAT connect to this rail through BAT60A schottky diodes. The diodes mean that the battery voltage and the regulator output voltages are isolated from each other, but either can produce V_TGT.

What if both a battery and a USB connector are connected? Whichever is the higher of VBAT or 3.3V_IF, minus a small voltage drop created by the BAT60A diode, will produce V_TGT. The voltage drop across the diode is around 0.1-0.2V according to the datasheet for the BAT60A.

It would be dangerous to the board to apply 5V to the battery connector. I am not about to try this. The battery connector bypasses the regulator in the microcontroller, so applying a high voltage to this connector applies the same high voltage to the components on the microbit board, minus a small drop across the BAT60A diode. Many of these are not rated to work at 5V.

The board is designed to take 5V only through the USB connector.

Running handShake in administrator mode to operate Grid 3

Sensory Software’s Grid 3 is a popular communication software package, running in Windows. Naturally, I would like handShake to be able to operate this software through the software keystrokes that handShake generates.  To get Grid 3 to respond to a software keystroke, I have to ‘elevate’ the base.py script which runs on the communication device to run as an Administrator.

There is a second solution. I can use a Freetronics Leostick USB dongle as a pretend keyboard and have this generate keystrokes that appear as coming from a physical keyboard. I did this for a while, but this adds a layer of complexity and expense to the project. The simplest solution is to run handShake as an Administrator when using Grid 3, or other software that requires software keystrokes to come from an elevated source.

I tested out adding the functionality for handShake to detect when Grid3 was running, then automatically try to elevate the base.py script to run in Administrator mode. I got this running. Then removed the functionality. Why? Security. Software running as Administrator can damage your system if incorrectly or maliciously written.

Now handShake detects if Grid 3 is running and advises that this requires the software to be restarted as an Administrator, but does not try to automate this restart. The decision is left to the user.

The Grid 3 software is detected using the code shown below. The code looks through the titles of the windows for any that match the ones in the list called ADMIN_SOFTWARE. At the moment there is only one title to check for – ‘grid’. This is the title for a window running Grid3. As I find other packages that demand that my script runs as Administrator to have the ability to interact with it, then I will add their titles to the ADMIN_SOFTWARE list.

ADMIN_SOFTWARE = ['grid']

def target_admin_sware(software=ADMIN_SOFTWARE):
    ''' Check if target software requires this script to run as Administrator. '''
    toplist, winlist = [], []
    logging.info('Looking for software that requires elevation to Aministrator: {}'
        .format(ADMIN_SOFTWARE))
    def _enum_cb(hwnd, results):
        winlist.append((hwnd, win32gui.GetWindowText(hwnd)))
    win32gui.EnumWindows(_enum_cb, toplist)
    for sware in software:
        # winlist is a list of tuples (window_id, window title)
        for hwnd, title in winlist:
            if sware in title.lower():
                logging.info('found software requiring Administrator mode {}'
                    .format(title))
                return True
    return False

Running handShake as Administrator is a choice that the user makes and implements if he or she deems necessary.  As all of the code is on the project GitHub site, the code can be reviewed to check that it is safe to run as an Administrator.

One of the advantages of open source projects is that they are open to this kind of scrutiny to find security flaws.

For interest, I detail the code I added and then removed from the base.py script to enable it to detect if it is running as an administrator and if not, request to be restarted as an Administrator.

I added the option to run the script as an Administrator from the command line using the click library.

click.command()

@click.option('-a', '--admin', default=False, 
    help='Run as administrator. Required for Grid 3.')

@click.option('-k', '--keystroke', default='F1',
     help='Keystroke to send. Default is F1.')

def main(admin, keystroke):
    logging.info('software keystroke is {}'.format(keystroke))
    logging.debug('admin flag is {}'.format(admin))
    if is_admin():
        logging.info('running as administrator')
    else:
        logging.info('not running as administrator')
        if admin:
            logging.info("restarting as administrator")
            elevate()
    service_microbit(keystroke) 

To test if the script is running as an administrator I added this method:

def is_admin():
    ''' Is the script running as an Administrator? '''
    try:
        return windll.shell32.IsUserAnAdmin()
    except:
        return False

Connecting the BBC micro:bit to Windows and adding code to it

This page details how to connect the BBC micro:bit to Windows then install a pre-written program to it. This guide was written to support some of my ‘how-to’ guides for assistive technology devices I made using the BBC micro:bit.

Author: Matthew Oppenheim

email: matt.oppenheim@gmail.com

GitHub site: https://github.com/hardwaremonkey

Summary

Connect the microbit using a micro USB cable from the microbit to the Windows device. You do not need a battery pack for the microbit. The microbit is powered from the USB connection.

  • Install the driver for the microbit if you are not using Windows 10.
  • Connect the microbit using a USB cable to the device with the communication software on it.

To install software, drag and drop the file, which ends with .hex, into the MICROBIT folder.

Connecting a microbit to a Windows machine

Connect your microbit to your Windows machine using a USB cable.

BBC microbit board connected using a micro USB cable to the Windows device. A battery pack is not needed.

Windows 10 should automatically detect the microbit. If you are using an earlier version of Windows, you will need to install the driver for the microbit.

If File Explorer shows that the microbit is attached, you are done. Success. The screenshot of File Explorer below shows that the microbit is connected as a drive called ‘MICROBIT’. A new microbit has a demo program installed which will scroll all kinds of things across the LEDs.

If the microbit does not automatically connect, download and run the microbit driver installer.

microbit showing as successfully connected in File Explorer.

How to install the microbit driver if the microbit is not detected

Windows 10 should recognise the microbit, but in testing, this was not found to always be the case. The driver can be manually installed using the instructions in this section.

I found that Windows 7 would find and download the driver for the microbit on its own when left for about 5 minutes. The microbit needs to be connected with the USB cable first.

If for any reason the driver is not found and installed by Windows automatically, then the driver can be downloaded and installed manually.

The name of the driver installation file is:

mbedWinSerial_16466.exe

A newer version may be available.

Get this file by clicking on the ‘Download current driver’ link on this page: https://os.mbed.com/handbook/Windows-serial-configuration

The microbit needs to be plugged in before the serial driver installer is run.

Follow the instructions on the webpage to install the driver. Once installed, the microbit should show up as a connected drive, as shown in the screenshot above.

Installing code on to the micro:bit

The micro:bit is programmed by placing .hex files onto it. This can be done by dragging and dropping these files onto the MICROBIT folder from File Explorer. For instance, if you are trying to install a file called ubit_flash.hex, the file called ubit_flash.hex needs to be dragged and dropped into the MICROBIT folder as shown in the screenshot below.

Drag and drop the file ubit_flash.hex to the MICROBIT folder.

Wait about 10 seconds for the microbit to start to program. The light on the back of the microbit will then flash for about 10 seconds as it loads the new program.

The code will remain stored on the microbit and run whenever it is powered. The microbit can be left unpowered and the code will stay on the device for when you next connect it to the Windows device.

As the microbits are being distributed to all 11-12 year-olds in the UK, if you get stuck installing code on to the microbit and live in the UK, find a friendly 11-12 year-old to help you out.

Problems

Microbit is connected, but the software tells you that no microbit is found

If a microbit is plugged in and you still get the message that there is no microbit connected, then the microbit driver is not installed. Look at ‘Installing the microbit driver’.

micro:bit C toolchain explained, part 1. ninja & cmake.

I use the offline build tools from Lancaster University for compiling and building C-code for the BBC Micro:bit board. I used the toolset without really understanding what was going on under the hood. I spent some happy time fixing this. Understanding our tools gives us a better chance of fixing things when they fail. I hope to pass on what I learned here.

So you have written some C code to go onto your micro:bit. Great. Now how does your beautiful prose get converted into the executable (often called a binary) file that can be copied onto the micro:bit?

The components of the toolchain that are unleashed upon your unsuspecting C code are shown below. Let’s start at the bottom.

Offline tool chain for building an executable from C code for the micro:bit

The ‘file to go to micro:bit’ is the end product of the chain of build tools and the Gnu C compiler (called gcc) shown above. This is the file that you copy to your micro:bit and is automatically executed when you power up the micro:bit. Let’s talk about gcc.

gcc

gcc stands for the Gnu C Compiler. If we write a simple ‘hello world’ C program contained in a single file to run on your workstation, telling your C compiler (in our case gcc) how to build the executable can be done in a single command. For example, the command gcc -o hello hello_world.c creates an executable file called ‘hello’ from a C program in a single file called hello_world.c, using gcc to do the compiling and linking. It gets more complicated when there are multiple files in the project. As we are using the micro:bit, there will be multiple files as many C files need to be brought into your project to enable the code to be built to run on the micro:bit hardware.

gcc is used to do the compiling and linking of your C code and the supporting libraries that are needed to enable the code to run on the micro:bit. gcc comes as standard with most distributions of Linux. But something has to tell gcc what files how to assemble the general mish-mash of interdependent files and libraries. This is what ninja does. ninja is a ‘build tool’. Let’s discuss what build tools are.

build tools

To understand the rest of the blocks in the toolchain, we need to have a little chat about build tools. A build tool looks for instructions in a text file, which is often called a build file on how to build ‘something’. That something could be how to use a compiler to compile and link files written in C, or for indeed another language. That something could also be how to build the instruction text file for a different build tool. This , which will then go on to do ‘something else’.

The build file contains a list of rules, such as the flags and controls to run the compiler with. It also contains a list of build statements which say how to build each of the files necessary to produce the output.

There are many different build tools. The micro:bit toolchain uses several. ninja, cmake, yotta and make are all build tools. Each of these tools looks for a text file specific to that tool. Here’s a little table for each build tool command and the corresponding build file that it works with.

build toolbuild file
yottayotta_config.json
cmakeCMakeLists.txt
ninjabuild.ninja

A build tool can often be used for building more than one type of language or thing. Let’s make build tools clearer by looking at how we use the ninja build tool to build a simple C project.

ninja

In the micro:bit toolchain, the ninja build tool uses a build file called build.ninja to instruct gcc on how to compile and link all of the project’s C files. Entering ‘ninja’ at the command line causes the contents of this file to be processed by the ninja build system. The build.ninja file contains details of the interdependencies of the files that are used to create the binary that we want to load onto the micro:bit.

Let’s look at how ninja could be used with a simple three file C project outside of the micro:bit system. Consider a simple example project, split across three files. The three files are called array.c, display.c and display.h. This example runs on your workstation, not on the micro:bit. I’m trying to keep it simple to show what ninja does and what a simple build.ninja file looks like. We will use this example to help explain some of the other build tools as well.

array.c

#include <stdio.h>
#include "display.h"

int main() {
    int v[5] = {1,2,3,4,5};
    display_arr(v, 5);
    return 0;
}

display.h

#ifndef DISPLAY_H
#define DISPLAY_H

void display_arr(int *arr, int len);

#endif

display.c

#include <stdio.h>
#include "display.h"

void display_arr(int *arr, int len) {
    for (int count=0; count<len; count++) {
        printf("arr[%i] = %i\n", count, arr[count]);
    }
}

We can see that the files depend on each other. To build these three files into a single executable we need to tell gcc how each file depends on other files. An example build.ninja file that will compile and link the three example files to create an executable called ‘array’ is shown below.

build.ninja

cc  = gcc
cflags = -Wall -g
rule compile
    command = $cc $cflags -c $in -o $out

rule link
    command = $cc $in -o $out

build array.o: compile array.c
build display.o: compile display.c
build array: link array.o display.o

default array

Putting all of these files into the same directory and typing ninja will create the following output:

[3/3] gcc array.o display.o -o array

You will find a new file called ‘array’ in the same folder. This is an executable file. Typing array at the command line gives this unexciting output:

arr[0] = 1
arr[1] = 2
arr[2] = 3
arr[3] = 4
arr[4] = 5

ninja is a relatively recent build tool. Traditionally the make build tool is used to build C programs. I will cover this tool in part 2 and show how this tool can be used to automate loading your code onto the micro:bit. However, with the micro:bit, ninja is used here. I’ve read that ninja offers about a 10x increase in speed of building the executable for large projects compared with make.

In our example above, I wrote the build.ninja file by hand. But how do we create this build.ninja file for our project? As I mentioned, building an executable for the micro:bit requires a bunch of C files and libraries to be compiled and linked with the source code that we write.

At the top of the ninja website, it states that ninja ‘is designed to have its input files generated by a higher-level build system’. In our case, this is done using the CMake build tool. So CMake produces the build.ninja file. Let’s have a look at CMake.

CMake

CMake is used to create the build.ninja file. That’s right – we are using one build tool to create the build file for another build tool to do something. There is a lot of this going on in the micro:bit build system. CMake can generate the build instruction files for a variety of build tools. Type cmake --help and look at the list of generators at the bottom. CMake uses the Ninja generator to generate the build.ninja file.

Let’s use CMake to create a build.ninja file for our previous example C code. In the directory with the C files, create a file called CMakeLists.txt with the content below.

CMakeLists.txt

project(array) 
add_executable(array array.c display.c)

Two lines only! Create a directory called build_ninja and cd into this. Then type CMake .. -G "Ninja". The “..” part will look for the CMakeLists.txt file in the directory above where you are now, then use the contents to create the build.ninja file. You will see a lot of new files are created including a build.ninja file.

The build.ninja file I wrote by hand earlier contains 10 non-blank lines. The new build.ninja file created by CMake contains 95 non-blank lines! Granted, a lot of them are comments, but still…. One of the first lines in the new build.ninja file is include rules.ninja. This file contains an extra 44 non-blank lines. So we have moved from 10 lines to a total of 95 + 44 = 139 lines. I included rules.ninja as a build file in the diagram at the top of this page as this file becomes part of the build.ninja file.

The next obvious question is ‘how is the CMakeLists.txt file created for the micro:bit build system’. This is done by yotta.

End dribble

Right, this is enough for one post. In the next part which I will link to here once it is ready, we will discuss yotta and the directory structure of the micro:bit C projects.

Additional reading

One good website that helped me figure out the programming toolchain, about 2/3 of the way down the article is https://hackernoon.com/the-first-video-game-on-the-bbc-micro-bit-probably-4175fab44da8.

Communication Matters Conference 2019

I attended the 2019 Communication Matters Conference in Leeds on Monday. I presented a poster on three of my assistive technology projects using the BBC micro:bit and gave a ‘lightning talk’ – 15 slides, auto advancing every 25 seconds. I wrote the PowerPoint presentation using Libreoffice on my Linux distro. Just before giving the talk I realised I had not tested it in Windows, which the conference PC was running with. Of course. Why use Linux for free when you can pay for Windows? Fortunately the slides displayed and auto-advanced correctly. This was my first time presenting at a conference, so I was a little nervous. I think it all went well. I didn’t notice anybody asleep and nothing was thrown.

A number of people showed interest in the poster. I presented my handshake, give-me-a-minute and hand-wave projects. Hopefully this interest will carry over to implementing these projects to help people access communication devices.

If any of these projects are of use for you or somebody you know, please get in touch. Contact details are on my home page.

Standing by my poster with the sunlight glinting gently off my baldy head.
My Mighty Poster. The original is A1.

People laugh when I tell them that I mostly failed over the years that I prodded at these projects. I went down the proverbial rabbit hole trying to implement camera based virtual switches before moving to repurposing simpler off the shelf technology, such as the BBC micro:bit.

I finally realised that trying to implement vision based controllers in the Real World was too much for Little Matty working on my time off from my paid work offshore. I managed to demonstrate the idea of using depth cameras to create virtual controls using head tracking: https://www.seismicmatt.com/headbanger-controlling-software-with-head-motion/ before moving on.

I was gratified to see a presentation from a Japanese team that succeeded with depth camera based controllers: http://gesture-interface.jp/en/. The Japanese team have been working on this project for 5 years and have 9 people working on the team, according to the team member I talked with at the conference. So even simple sounding ideas using off the shelf technology can take significant resources and software development to implement in the Real World.

Using the microbit to control switch access software

What is switch access software

Many disabled people use specialist software to create speech or to interact with the environment (e.g. turn on lights). Some are unable to use keyboards or mice to operate this software, so use a variety of ‘switches’, such as push buttons. These buttons act like keys on a keyboard, or pretend to be a mouse click.

I took some hand held video of a switchable software package which enables speech to be created. The software is called Liberator. A big red button was configured as the switch controller. When the button is pressed, a row is highlighted. The highlighted row scans down. A second click selects a row. The software now scans across the single cells in the selected row. A third click now selects that cell and the text for that cell appears in the speech window. Sometimes a cell will lead to a new grid. Once the speech text is composed, a cell can be selected for the text to be sent to a speaker. I tried this out at the Communication Matters conference in Leeds.

Trying out the Linberator switch access software at the Communication Matters Conference.

Wikipedia has a page (of course) explaining what an assistive technology (AT) switch is here. Copying the one line summary at the start of that page: “A switch is an assistive technology device that replaces the need to use a computer keyboard or a mouse.”

The system we developed allows the BBC microbit to pretend to be an AT switch, so that movement sensor devices I make using the microbit can be used to control switch accessible communication software. For instance, Grid 3 by Smartbox.

The picture below shows a typical button switch and a Joybox switch to USB adapter. The adapter enables the button switch to be connected to a USB port. This allows the button to act as if a key is pressed on a keyboard. This simulated keyboard key press then controls software, to e.g. create speech. The standard connector for a switch is the venerable 3.5mm audio plug. The 3.5mm plug is on the end of the cable attached to the button switch. A 3.5mm socket is attached to the USB to switch converter.

My task was to enable a microbit board to connect with a 3.5mm plug and act as a switch, so that the signal would be recognised by the switch to USB adapter. How hard could this be?

Button switch and interface dongle.

How does the switch work? The 3.5mm connector has 2 contacts inside of it. When the switch is operated, these are connected together internally. So, the contacts are normally open and closed when the switch is pressed. How do I recreate this switch electronically?

I used a Grove M281 Optocoupler Relay.

Grove M281 optocoupler relay board. The control pins are on the left, the relay pins are on the right.

This acts as an electronically controlled switch. When the CTR pin on the board goes high, the two connectors with the screws on top are connected. When the CTR pin is low, they are disconnected. The CTR pin can be seen on the left of the photo. There are connections for ground (GND), power (VCC) as well. The NC pin is Not Connected.

I could maybe lash up something cheaper using a transistor or two, but for around £6 I had an off the shelf solution that I got tested and running within a day. The microbit connects to the pins on the left of the board in the photo. The 3.5mm plug connects to the screw top terminals on the right of the photo.

The advantage of using optocoupler is that the microbit is isolated from the communication device that the 3.5mm plug is connected to. My slight worry was creating a ground loop. If I didn’t have any isolation between the microbit and the 3.5mm plug, if the microbit is powered from a USB source – say another computer – and then the microbit is connected to a communication device that is also connected to the mains, we may create a ground loop. The optoisolator prevents this. I don’t think this is a likely scenario with the tiny currents involved, but I am working with a vulnerable user group, so am a little more cautious than usual.

The optocoupler relay board is specced at 3.3V, but worked with the 2xAAA battery pack powered microbit at 2.4V. Nobody is more surprised than I am when something I build works!

The photo below shows all of the parts of the system, apart from the switch to USB adapter, shown in the photo at the top of the page. The microbit board slides into a Kitronik edge connector and break out board:

https://www.kitronik.co.uk/5601b-edge-connector-breakout-board-for-bbc-microbit-pre-built.html

microbit board slid inside a Kitronix break out board connected to a solid state relay board connected to a 3.5mm plug. The plug is unscrewed so you can see the two connectors.

The Kitronix break out board allows all the signal pins on the microbit board to be accessed. I used digital pin 16 on the microbit board to connect to the CTR pin on the M281 board, as it allowed for the neatest wiring. The photo below shows the wiring on the right. Pin 16 connects to the yellow wire. Ground is the black wire and the 3V output is connected to the red wire. Ignore the connectors and resistor on the lower left of the photo – these are used for connecting a motion detecting sensor, which I will write up on a different post.

The two screw top terminal connectors on the M281 are connected to each of the two contacts in the 3.5mm plug. The wires connected to the plug by soldering and are connected to the M281 by screwing down the terminals.

I wrote a small program to toggle pin 16 on the microbit high to simulate the action of the sensor detecting a hand motion, which is the action we would like to use to trigger the switch.

Pin 16 is connected to the solid state relay board using the yellow wire. The red and black wires connect to +3V and ground pins.

The 3.5mm plug goes into the socket of the interface dongle shown in the photo at the top of the blog. The dongle plugs into your PC on a USB port. The dongle is recognised as a switch interface using the free software at:

https://thinksmartbox.com/product/switch-driver-6/#

I used Windows 10 to check that everything works as it should. Which it did. Screen shot of the software below. Hurrah.

The final code used for this project can be found on my github page in the hand_wave folder.

Smartbox Switch Driver software used to test the switch.

One final Top Tip is to replace the AAA battery pack that comes with the microbit with one that has a power switch. These are about £4 + £0.75 postage from eBay. The title for the switched battery box I bought is ‘Switched battery power box for BBC Micro:Bit 2 x AAA’.