BBC micro:bit – Lunar Lander Project (part 1)

With my godson’s eleventh birthday coming up, I was wondering what would be an interesting gift. A few months ago, J, his little brother N, and I had been talking about passwords. They’d been told at school that it helped to misspell words – so ‘werdz’, say, rather than ‘words’ – and to insert punctuation marks. But why are you being given this advice, I pressed them. This led to some discussion about how a person – or more likely a computer program – might try and guess a password. And this, in turn, led to us writing some code in Scratch, a programming language for kids, that would actually guess passwords. The boys enjoyed themselves hugely. And they were just awestruck by how many brute force guesses were required to crack passwords.

So for J’s birthday, I thought something with coding might be fun. But I also liked the idea of him having something of his own, something not virtual. And so I got to wondering if we could code a game on one of these new breed of tiny computers, such as the BBC micro:bit.

What I had in mind was the sort of game that I had coded up back in the early 1980s using machines such as the ZX80 (my big brother’s), Commodore Pet (at school), Acorn Atom (at John Cupitt‘s), Oric-1 (mine!), and BBC Micro (at JC’s again). This was when I was first learning about programming and you either used BASIC – which was often too slow or couldn’t let you control the screen with sufficient precision – or more likely machine code. Tricky, but rewarding when you finally got things to work.

Preparation

So I started doing some research on-line. It turns out that you can buy tiny displays and it looked, in theory, as if I could connect one of these to the micro:bit and make it work. I reckoned that if I could hook up a 128 x 128 pixel display to the micro:bit that would be large enough to make a playable Lunar Lander game.

Before I committed to ordering any parts, I thought I’d do some sort of proof of concept. These days, when I program it is mostly for the iPhone using Apple’s Swift language. So I knocked up the vary bare bones of a Lunar Lander program as an iPhone app, scaling the display size to 128 x 128 pixels. And all seemed OK.

Is 128 x 128 pixels enough for a playable Lunar Lander game? Doing a “proof of concept” on the iPhone.

There remained some uncertainty though. I couldn’t find any definite instructions or a worked example of connecting a micro:bit to any of the displays I’d been looking at. There were things written about doing this for other tiny computers, such as the Raspberry Pi, but not so much for the micro:bit. So I couldn’t yet be sure whether I could actually get the micro:bit to “talk” to a display. But I was getting to the end of what I could realistically do with desk bound research. And so, I ordered two micro:bits and two Inventor’s Kits, one each for me and for J. I also ordered one display to test out. If I couldn’t make it work, then I’d have to come up with a plan B.

Microbits and Inventor’s Kits. One for J and one for me.

Before I wrapped up J’s micro:bit I wanted to try things out and get a sense of how it worked, so I could tell his mum a little bit about it and write a decent note for him in his birthday card. I encouraged J to try out the hardware and follow the instructions on his own. But I also know that what he loves more than anything is doing things with other people. For him, that’s at least three quarters of the fun. And, so it turned out, he chose to wait for my visit – scheduled for a couple of weeks’ time – before breaking the seals on his new toys.

The actual micro:bit really is micro. I was expecting it to be small from the size of the box, but even so I was surprised at how tiny it is.

Back at home, I was figuring out how the micro:bit worked. You write code on your computer, using a special web page. And even without connecting the micro:bit you can see the effects as the page has a “simulator” – an animated picture of the micro:bit that performs, more or less, in the same way as the real hardware. The main thing the micro:bit does is let your create patterns on a 5×5 grid of LEDs, to respond to two buttons and, if you connect some headphones or a small speaker, make noises and play tunes. The simulator lets your try out all these things. And then, if you connect the computer to the micro:bit you can transfer the program to the tiny computer.

There are a few different choices of programming language for the micro:bit. Because I wanted J to be able to do some of the coding himself, I went for the option called the JavaScript blocks editor. The JavaScript language is one I know something about. It’s the language that can be run inside a web browsers and is used to make web pages do all sorts of clever things. And the “blocks editor’ bit means that kids can drag chunks of code around rather than having to type things in word by word.

Great, I thought. What I can do is to develop some code in my web browser using JavaScript and I can simulate the pixel display there. That way, I can write and test code before my display arrives. I went ahead and did this, getting some basic code to paint a lunar lander on the screen and move it about. (If you are reading this on a Mac or a PC, you can see a bare bones JavaScript proof of concept version of the game running in your browser. And you can click through to JSFiddle to the see the code.)

I was greatly encouraged to have my proof of concept up and running, but there was still the question of whether I could successfully connect micro:bit and display.

When the display arrived in the post, the first task was to do some soldering so I could plug it in the “breadboard” and, through that, wire it up to the micro:bit.

Working with hardware is different from working with software. There are fewer second chances and my soldering skills were pretty rusty. But I seemed to get on OK. The most anxious part of the soldering operation was that the ‘connector’ part that came with the display had more pins than there were holes in the display board. I needed to clip off a few of the pins. I’m glad I was cautious and did an experimental clip first, as it turned out it was very easy to overshoot with the clipping.

The next phase of the project was the most challenging. The display is designed to talk to a computer using something called a Serial Peripheral Interface Bus (SPI). I was learning about this for the first time and was not finding many examples on-line of making practical use of the SPI with the micro:bit. Not for the first time, I wondered if I had bitten off more than I could chew.

At root there needs to be some wires between the display and the computer, and signals get sent down these wires to tell the display what to do. At the level of the hardware, I needed to connect some power and then four wires for communication. By following the published data sheet for the display and the micro:bit documentation, I wired everything up. And, at this point, the display actually lit up. This wasn’t telling me anything much, because I wasn’t yet sending any messages to the display to tell it what to do. But it was at least an encouraging sign.

The next phase was to start sending messages – in the form of a series of numbers – to the display to get it to do what I wanted. The people who provided the display provided lots of useful documentation and also some sample code that lets people with computers that are not micro:bits talk to the display. So I had to look at the code and convert it into the JavaScript language that the micro:bit could understand.

Writing about it now, it sounds straightforward enough. And by the time I’d gone through their code line by line, I suppose it was. But it took time and patience. For example, I had to identify what code was essential and what I could set aside. I couldn’t run or test this code, so it was a matter of reading through and making sense of it step by step. To even start the display up at all, required sending a series of numbers. And if any one of them was wrong it was entirely possible nothing would work. And then to get coloured dots to appear meant sending more carefully crafted numbers. Some hours later, I had checked and re-checked the code I had written. It all looked OK, so it was time to transfer the code to micro:bit and see what happened.

And what happened was… precisely nothing at all. The same white screen – yes, I already know the power is working – stared back at me as I stared at it.

Carefully checked code running, all wires attached and no change on the screen. Oh dear.

There was a real moment – indeed an extended stretch – of doubt here. Because at this point I wasn’t sure how many moves I had to make. I’m used to working in software, but perhaps there was some hardware thing that I’d failed to understand. Perhaps my soldering had been shockingly poor. Perhaps, I wondered, I just won’t be able to fix this.

Still, it’s engineering, right. So it’s a matter of coming up with hypotheses as to why it’s not working and testing each one. I checked which wires I’d connected between the micro:bit and the display. Everything was checking out. I got back to the original software provided by display supplier and compared key sequences between it and my code. And then, I spotted something.

One bit of code controls the signal sent down a particular wire that, basically, asks the display to sit up and pay attention. Surely, the pay attention signal would be positive three volts and not zero volts? That is a one instead of a zero. Well, I must have thought this without really thinking, because that’s what the code I’d written assumed to be the case. But as the display supplier’s code made clear, the “sit up and pay attention” signal was a 0 and the “ignore everything, it’s not for you” signal was a 1.

The code change took less than half a minute. Transferring the software to the micro:bit took about the same time again. By this time, I’d also wired up a speaker so the setup made some sounds when the software had transferred. And now, as the beep sounded, so the display transformed into hundreds of random coloured dots. Not quite what I was expecting, but a clear sign that the signals I was sending were getting through. And, amongst the random coloured dots, in red, was the just discernible outline of a lunar lander. I pressed one of the buttons on micro:bit that I had programmed to move the lander a pixel to the right. And again. And, yes, the lander was moving, leaving a trail of blackness behind it. Time for a picture, I thought.

Game On! My code is working and I have something that looks like a lunar lander on screen.

The multi-coloured background is just what happens when the display starts up. I needed to ask it, explicitly, to clear the screen. But I already had code, adapted from the display supplier’s, to paint rectangles of an arbitrary size. Although, even that code didn’t quite work the first time.

An almost clear screen with the lander

At this point I was optimistic about making rapid progress. The plan was to take chunks of the code I’d written for my proof of concept in the web browser and use it on the micro:bit. After all, they both say they use JavaScript.

However, as it turns out, the JavaScript for the micro:bit is a severely stripped down version of the language that runs in a web browser. Just how stripped down became apparent slowly and painfully. So, for example, inside the web browser the JavaScript language understands decimal numbers. And my code relied on the use of decimals all over the place. For example, it relied on decimals in working out how to draw a straight line or how to apply gravity or the force of a rocket booster to the lander. This particular problem was one of the more straightforward ones that I encountered. Instead of relying on fractions, I was able to just multiply everything up and then, when it came to calculating the real pixel position, divide down and round up.

Slowly, the game started to come together. There were plenty of wrong turnings, as there always are with programming, such as the landscape appearing at the top rather than the bottom of the screen.

Landscape in the sky. Classic computing error. The machine, of course, was doing exactly what I’d asked it to do.

The not so solid surface of the moon. Not so much a bug this time, just a case of not having got to the point where I’d added a test for the lander hitting the surface.

Next Steps

So I had most of a working game. I didn’t want to polish it up too much. Rather, I wanted to take the basic building blocks and ideas and get my godson to, first, put together his own hardware and, second, code up the game. Knowing that I had the really tricky code to talk to the display, to put pixels – and also little patterns of pixels, such as the lander – on screen, made it a viable plan. Although it still seemed pretty ambitious. I was only visiting for a weekend. But I very much hoped, J would both have fun and, at the end of the visit, have a viable – if basic – Lunar Lander game.

I’ll add a link to part 2 when it’s written… watch this space. If you want to try this project yourself check out Connecting a micro:bit and an AdaFruit 1.44 inch display.

Questions and Comments

Comments are not enabled on this site, but if there are interesting comments or useful tips submitted then I’ll append them to this or one of the other Lunar Landed related posts.

Name

Email

[honeypot area-of-interest id:area]

Question or comment

Facebooktwittergoogle_plusmailFacebooktwittergoogle_plusmail