Thursday, 26 January 2017

A simple reaction timer in MicroPython on the micro:bit

The micro:bit continues to surprise and delight me.

My project yesterday was to write a simple reaction timer in MicroPython.

The timer application was really easy to code. I'll build up a subset of the code step-by-step, but the whole program is on GitHub. You can download it here.

Here's how the code works:

The program starts by displaying a clock image:

Next, it picks a random time to wait, ranging from 500 ms to 4500 ms. (In other words, it will wait between half a second and four-and-a-half seconds.)

sleep(random.randint(500, 4500))

When the time has run out it displays a happy face: 

Then it checks every tenth of a second to see if the user has pushed button a (to show they have seen the image, keeping count while it waits.

def time():
    # returns the time until waiting is over, in 1/10 secs
    count = 0
    while waiting():
        sleep(100) # 100 ms = 1/10 secs
        count = count + 1
    return count

 The waiting() function just checks that button a has not been pressed yet:

def waiting():
    return not(button_a.is_pressed())

Once the user presses button a, the loop ends and the application prints out the time in tenths of a second.


When you look at the code you'll see that the current version does a little more than that. It runs in a loop, timing reactions over and over again, and continues until the user presses button b to exit.

It also checks to see if the user jumps the gun (naughty!) by pressing button a before the happy face is displayed.

Sample output

Here's the application output in mu's REPL window on the Pi:

I'm using the mu editor on a Raspberry Pi. mu allows you to opens a REPL window where you can type and execute Python code, and it also displays any output from print statements.

The next step will be an application that runs on a connected Raspberry Pi. It will capture the printed output and use it to do some clever calculations. I'll tell you about that in another blog post.

What fun projects are you doing with your micro:bit? I'd love to know. Just post a comment below.

Friday, 20 January 2017

MicroPython on the BBC micro:bit - easy as Pi

The BBC micro:bit really makes it easy for you to get hooked and get coding with MicroPython.

Like Python, the micro:bit comes with batteries included. Plug in the battery and an irresistible introductory app launches.

Many newcomers will use the Scratch-like block coding environments. If, like me, you prefer to program in Python, a couple of clicks on the micro:bit website will show you how to upload and run your own code.

When you connect the the micro:bit via USB, it appears as a removable USB drive and you can just drop your code onto the drive to flash (install) and run your program.

There's a browser-based interface to the compiler, but I'm using the mu editor on the Pi.

That way I can maintain my source files on Github, and I'll be sharing them once I have something useful to show.

I'm hoping to start coding the controller for C2Pi in the next few days.
For now I'm working my way through the great examples available on the micro:bit website and elsewhere.

Here's the mu editor showing a little Python program that shows off the display and the buttons:

and here's what happens when you run it:

Thursday, 19 January 2017

Raspberry Pi and BBC micro:bit for C2Pi

Right now the Raspberry Pi and the BBC micro:bit look like a winning team.

If you're following this blog you will know that I am evaluating new hardware and software for C2Pi (the re-generated C3Pi, neƩ Trackbot).

Over the weekend I discovered that the micro:bit now supports MicroPython.

Since I am looking for a micro that supports a language with a REPL, I had to investigate.

MicroPython on the pyboard

I've been a fan of MicroPython for a while. It runs on several platforms, including a custom board (the pyboard).

I first met the pyboard, and Damien George, (its designer, and the original implementer of MicroPython) at an Open Technology conference in Cambridge a couple of years ago.

I learned that MicroPython is a full, optimised implementation of Python 3; the only difference lies in MicroPython's specialised libraries, which  focus on direct access to the hardware.

At the time I felt that the pyboard and MicroPython had great potential but I couldn't use them for the project I was building back then.

Things have changed.

MicroPython on the BBC micro:bit

The original Pyboard is a good fit for C2Pi. However, the BBC micro:bit looks even better. It's cheaper, and there are over a million micro:bits out in the field.

The micro:bit has slightly less functionality than the pyboard and a smaller memory but  looks entirely adequate for what I want to do.


I ordered a Kitronics micro:bit prototyping kit from my friends at Pimoroni and the kit arrived a couple of days ago.

Image courtesy of Pimoroni

So far I am encouraged and impressed. It's been easy to set up a link for the Pi to the micro:bit. I can send Python commands from the Pi for execution on the micro, which is perfect for fast development.

Interactive Python on the micro:bit

The session below shows the Linux screen app on a Pi, talking to a micro:bit via a USB serial link and running a couple of simple Python expressions.

Hardware interfaces exposed


The micro:bit running MicroPython gives easy access to all the interfaces that C2Pi needs: GPIO, UART, I2C and SPI.

If all continues to go well I will set up a public GitHub repo for my experimental code, and post more details here.


Prototyping kit

It seems there's great potential for the Pi combined with the micro:bit. What do you think?

If you have questions, opinions or ideas, do post a comment. I'd love to hear from you.

Tuesday, 17 January 2017

Embedded development is faster with a REPL

In my previous post I mentioned that I was frustrated by the slow pace of Arduino-style development and that I was looking at using a language with a REPL (Read-Evaluate-Print loop).

A REPL is just a fancy name for an interactive environment. You can type an expression and have the computer evaluate it; the computer display the result immediately. (If you've ever used Python interactively you'll know exactly what I mean).

Why REPLs are great

REPLs give you immediate feedback. If you've done something right, you get an immediate reward. If you've made a mistake, you get to fix it while everything is still fresh in your mind. I find it makes for much faster progress, particularly if I am using hardware or software I haven't used before.

They also give you a chance to do some stunning demos. Here's a video of two Dyabots dancing, courtesy of Morten Kromberg (CXO of Dyalog).

A tale of two REPLs 

C3Pi and Dyabot have two computers on board; a Pi to do the overall control, and a smaller, simpler micro-controller to handle motor control and related tasks. We could do that from the Pi but there are issues with real-time software on the Pi. We also  want to make sure that if the software on the Pi stops running the robot stops moving.

Ideally I'd like to program both the Pi and the micro-controller using interactive languages with REPLs. I'd also like to use languages that I know well that are widely used and well supported.

Spoilt for choice

There are plenty of REPL-based languages on the Pi. C3Pi and Dyabot use Python and APL, but those are just two of many alternatives.

There are fewer choices on the Arduino and the Teensy.

The Arduino IDE uses a subset of C/C++ with no REPL available. Development follows the usual cycle: edit, compile, upload, test.

I find that frustratingly slow.

If you want an interactive language with a REPL, there are versions of FORTH available on the Arduino but it has too little RAM for comfortable FORTH development. The Teensy is well suited to FORTH but the user base seems very small.

I've done some experiments with Mecrisp FORTH on a couple of low-cost ARM systems, and the results have been quite encouraging, but my FORTH is fairly rusty and the user community seems very small.

This week-end I realised there was a very promising alternative. I'm evaluating it at the moment.

It's cheap, it's easy to connect to the Pi, it has good GPIO and other interfaces, and I can program it in Python. Best of all it has a huge user base and great support from multiple vendors.

Tomorrow I'll post more details and tell you what I've established so far.

Meanwhile, I'm curious. What would hardware and software would you use as an intermediary between the Pi and the outside world? Leave a comment and let me know.

Saturday, 14 January 2017

C3Pi regenerates!

My old friend C3Pi, like Doctor Who, regenerates from time to time.

He started life as Trackbot - a tracked robot, powered by an Arduino Nano, with fairly limited capabilities.

Some years later he acquired a Raspberry Pi, and replaced the Nano by a Teensy 3.1.

C3Pi has proved a good subject for experiments, as did the Dyabots - the mobile robots built by Dyalog to experiment with APL as a control language for robotics. But...

The C3Pi and Dyabot designs had their limitations, and it's time to apply the lessons learned.

Issues with C3Pi and Dyabot

Several factors have stopped me achieving all I want to with the old version of C3Pi.
  • I found it awkward to recharge or replace C3Pi's batteries.
  • C3Pi’s limited room made it hard to add new capabilities.
  • The Pi was a veteran model 2 B+; C3Pi would benefit from the processing power of the Pi 3.
  • I found the Teensy disconnect-compile-upload-reconnect-test cycle frustratingly slow.
  • The motor controller was a cheap clone and it's hard to find an identical model on eBay.
  • C3Pi's base is no longer manufactured, so others couldn't replicate the design.

Dyabot uses a readily available robot base and motors, but
  • The Teensy development cycle causes the same problems
  • The IMU is not accurate enough to keep track of the robot's position

C3Pi regenerated

The next incarnation of C3Pi (and Dyabot) will use a Dagu Rover 5 robot base and motor controller. The base has quadrature encoders which keep track of the wheel's rotation, the motors are much more powerful, and there's a motor controller that's made by the manufacturer of the base. C3Pi will still need an IMU to keep track of the direction in which it’s pointing. I’m about to try Adafruit’s BNO055.

The base, the controller and the IMU are readily available, so you'll be able to replicate our experiments if you want to.

I'm currently evaluating two other changes: a possible replacement for the Teensy, and the use of a language with a REPL (Read/Evaluate/Print Loop) to program it.

The ability to type some code and run it immediately without having to compile and upload should speed development up a lot.

More information soon!

What do you think?

What do you think about the  new approach? I'd love to see your comments.