mbed Blog

Working with the BBC on micro:bit: Part 1 - using the mbed HDK

For the last few months, we’ve been hard at work helping the BBC and its partners in the Make it Digital campaign turn the BBC micro:bit into an awesome reality. With the launch announcement today, we are now able to talk a lot more about the BBC micro:bit, mbed, and how together with its partners the BBC has built a working mbed Enabled board in just four months.

We are used to having our heads stuck in the details of how to build embedded systems, but normally we are doing that in order to make fundamental building blocks so that other people can create mbed Enabled platforms quickly. This project has been different, though: as well as our usual role as mbed, we’ve stepped to the other side of the silkscreen and worked with the BBC and partners to build and test the early prototypes of the BBC micro:bit hardware.


This is the first of a series of blog posts about how the micro:bit was put together, how it was built and tested, and what we’ve learned by eating our own dog food and putting ourselves in our partners’ shoes.

  • Part 1: Building the hardware – using the HDK and testing the early boards.
  • Part 2: Bringing up the software and supporting Lancaster University in building the micro:bit runtime.
  • Part 3: Development tools and the compile API.

BBC micro:bit is mbed Enabled

So how has mbed helped the BBC micro:bit project? Here’s a slide I presented at the first Hardware Working Group meeting as a proposal:


We thought that building micro:bit based on the mbed SDK and HDK would be great for the project; by using open source, deployed, tested components as a foundation, the idea of having something produced in enormous quantities within months of the ‘go’ date seemed less daunting.

Start with known working parts

One of the most time consuming parts of an embedded project can be the early “trust nothing” stage: when you can’t be sure whether your tools, your design, your test system or your own sanity is the reason something doesn’t work. By basing the BBC micro:bit on the mbed HDK it was possible for the other groups in the project to start working and testing with other (known good!) mbed Enabled boards, knowing that they would be able to switch over to the micro:bit when it was ready. Given the aggressive schedule, the partners working on the programming environments and smartphone apps needed something to work with while the boards were being designed and made.

On the hardware side, the BBC had done extensive trials in schools with earlier hardware that had LED matrices, and they knew they wanted to keep that feature – would we be able to drive all the LEDs directly from the nRF51822 without needing extra drivers? Could we scan the matrix fast enough and have the image look clear? Would the BLE radio interrupts give visual glitches on the ‘display’? For a quick answer, Lawrence (from upBeat Product Development) made some nice LED matrix boards, and we plugged them into a Nordic NRF51822 development kit, which uses the same chip as the micro:bit, and is a very similar board.

Click to enlarge

It works!

Layout the HDK, any size will do

The next step was to take the HDK, add the micro:bit specific components and lay it out on a board with the LEDs so we could test in earnest. Chris, dusting off his Eagle gloves, took on this task. The resultant board, called ‘the square board’, had a run of 10, was not at all square, and didn’t work out of the box. Luckily, Marcelo is good with his soldering iron; in the picture below you can see the workaround for selecting the wrong USB connector part: desolder it and put the cables directly onto the board! This kind of mistake is easy to make when you’re picking up a new part or design, and it’s led us to think about how much we can provide alongside the HDKs - we’ve got some exciting plans to announce soon.

Click to enlarge

The ‘square board’ was also the first place we tried driving the LED matrix with animations. Yes, that’s on a plane…

Click to enlarge

Form factor prototypes and reducing the number of components

As the project progressed, it became clear we needed some form factor prototypes. This is the kind of task we’re usually one step removed from, but given the need for a quick turnaround, and the fact that Chris had already done the layout for ‘the square board’, he was the natural choice for ‘square board two’ (which I can report is also not square…). There are a few neat tricks in the micro:bit to save cost, such as using the on-chip regulator of the KL26 to regulate USB 5V to 3.3 for the Nordic chip. While I’m sure mbed users deploying the HDK regularly use these techniques, it’s been great seeing them up close, and that’s given us a chance to factor them back into the sources, hopefully saving our downstream developers time, money, and hassle. We also needed to check that the layout for the board could be done in the size desired, on a two-layer board.

Here’s Chris, proudly holding the first ‘SB2’ that came back from the board house. Answer: yes, it fits! I owe Chris at least one beer.


Sadly, as we’d spent a lot of the time with the first square board debugging the USB issues, we didn’t yet have a working port of the interface firmware. This meant that the new SB2 wasn’t easy to program. We were posting boards around to partners in the project, and we needed a way to program them…

Click to enlarge

Luckily, it’s possible to use the Nordic –DK board as an external programmer for another nrf51. The experience is just like using mbed normally, but there’s not much documentation around this on mbed. We wanted to make the information available to other mbed developers – it’s a useful trick, and again, the kind of thing we don’t necessarily encounter day to day. The page here was our way of getting the useful information out, without tipping anyone off that BBC micro:bit was on its way. On the plus side, if you manage to brick your beacons, it’ll help you out, too.

The SB2 design is what we’ve handed over to Farnell for them to start the process of taking the board to manufacture in volume. Meanwhile, our focus has shifted to getting involved in the software work, porting the mbed SDK to the micro:bit board, and supporting the other partners building tools on top of the SDK; I’ll write much more about that in the second installment of this series of blog posts.

The BBC is doing something ambitious and ground-breaking by giving away a micro:bit to every year 7 pupil in the country, and it’s a privilege to be involved. We can’t wait to see what people start building with their micro:bits!

Below are some other photos from the hardware design stages that we hope might be of interest.

Click to enlarge

One of the early planning sessions for our involvement in the BBC micro:bit project. Notice the ‘EEK’ on the right hand side.

Click to enlarge

Don’t get your wires crossed! (Also, don’t draw diagrams like this. Top pin, top label; bottom pin, bottom label.)

Click to enlarge

Boards, yet to be populated. These were the first boards with the excellent design from Technology Will Save Us. Colours are not final.

Click to enlarge

Four generations of BBC micro:bit prototype, ready to do something amazing.

Using the new mbed power management API

Today, ARM and Silicon Labs are releasing an extension to the ARM mbed SDK, enabling mbed users to more efficiently use system resources. We demo-ed the result of using these new low-power APIs before, and will provide guidance on how you can take advantage of them in this post.

What we are releasing today is a three-pronged approach to reducing power consumption in everyday mbed applications. Firstly, you can now take advantage of asynchronous I/O transactions on SPI, I2C and Serial peripherals. That will allow you to intelligently sleep, or do other calculations, while your potentially slow or long-running transaction is executing.

Secondly, the behavior of sleep() has been altered to support all sleep modes. On supporting platforms calling sleep() will automatically put your chip in the lowest power mode possible, depending on which transactions, timers or other operations are currently running. As of today, that functionality is present on Silicon Labs’ platforms, with other platforms hopefully following soon.

And lastly, the addition of low-power Ticker, Timer and Timeout APIs. The implementations for this will be dependent on which platform they’re running on, but the base idea is that you are sacrificing timing resolution for (much) lower power consumption. On Silicon Labs’ platforms, even though you’re still setting the timing value in microseconds, the resolution will be along the quarter millisecond line.

It is worth mentioning that no pre-existing APIs have been deprecated, so all code that uses the blocking APIs will still work, even on low-power enabled platforms. So now, let’s dive into the details! Asynchronous transaction calls

Asynchronous calls allow you to submit an I/O operation to the system for execution, and let the system handle the transaction in the background. When complete (or if it errors out), you get a callback to your own specified function. Depending on the implementation, this uses either an interrupt-driven or DMA-driven execution style under the hood, or a combination of both.


This is the new type definition for callbacks generated by asynchronous I/O operations. It can point to a void (int) function, and needs to be initialized by the calling code. For example, when you want to define a callback to a function called handler, you would do something like this:

event_callback_t functionpointer;

void handler(int events) {
	// Handle events here

void init_fp() {


For I2C, the traditional start, stop, read and write functions have been superseded by a single ‘transfer’ function. It takes both a write (tx) and read (rx) length in bytes, and char pointers to the respective write and read buffers. It will automatically add start and stop conditions before and after the transaction, and if both write and read lengths are greater then zero, a restart condition will be generated between the write and the read. Additionally, it takes an event argument, which is the logical OR of all events you want to get a callback for (defined in i2c_api.h), and a pointer to an event_callback_t for your callback handler.

When the transfer has started, the function will return 0. If not, there is an error or there is another I2C transfer already in progress. The abort_transfer function will abort the current transfer.

You can see the new APIs being used in a real-world scenario in Silicon Labs’ mbed library for the si70xx series of relative temperature and humidity sensors.


Until now, SPI really only consisted of one function, write, which would write the configured amount of bits to the bus, and return the response. With the asynchronous API, we are introducing the ‘transfer’ function, much like the I2C equivalent. The difference here is that if the amount of bytes to receive is greater then the amount of writes, the transaction will automatically write fill words to receive the given number of bytes. The other way around also works, the transaction will only fill the receive buffer with the specified amount of data, even if the write buffer is larger.

The transfer function also takes an event argument, which is the logical OR of all events you want to get a callback for (defined in spi_api.h), and a pointer to an event_callback_t for your callback handler.

You can see the new APIs being used in Silicon Labs’ mbed library for the Sharp LS013B7DH03 memory LCD.


The serial bus is the odd one out of the three. Because it is asynchronous by nature, the functions had to be split up in two: one for sending, and one for receiving data.

The transmit function is called ‘write’, and takes a buffer, its length, a logical OR of events to listen for, and a pointer to the relevant event_callback_t object. The event flags are defined in serial_api.h. The transmit function will return immediately, and the callback will get called on completion of the transmission, or on an error condition. When there is already a transmission in progress, the transmit function will return an error code, and the callback will not get called.

Likewise, the receive function, called ‘read’, takes a buffer, its length, a collection of event flags, and a pointer to the relevant event_callback_t object. However, it can also take a fifth argument, which is a character to listen for. If the SERIAL_EVENT_RX_CHARACTER_MATCH flag is enabled, reception will cease upon seeing this character, and the callback will get called with this flag.

You can see the new API in action in Silicon Labs’ low power serial demo program.

Harmonized sleep calls

Historically, mbed has had sleep() and deepsleep() calls, that would put the system in the specified state. Silicon Labs’, however, is making it easier for you to write low power optimized applications! Now, when you call sleep(), the system will decide which sleep mode to go to, depending on the callbacks that have been registered.

Beware that sleep() currently returns after every interrupt, and that interrupt may or may not be related to any callbacks you have registered. Therefore, if you want to sleep until a certain callback has fired, you need to have a variable changed by that callback, and keep calling sleep until the change has happened.

	while(condition == true) sleep();

For example, when you have a serial transaction going on while you are actually waiting on a low powered timeout that is set to happen after the serial transaction completes, this implementation allows the system to go to a lower power mode after completion of the serial transaction.

Low-power Ticker/Timer/Timeout

The Ticker, Timer and Timeout classes now have a low-power equivalent with the exact same API, but a different underlying implementation. On Silicon Labs platforms, the non low-power classes rely on a high-frequency timer for timekeeping, preventing the system from going into a significant sleeping mode. The low-power classes, on the other hand, are implemented using the RTC, which means they have a lower resolution, but allow for higher energy savings.

Guest Blogger:

Steven Cooreman, Software Engineer, IoT MCU & Wireless, Silicon Labs. Originally from Belgium, Steven has always been fascinated by the wondrous world of electronics. Also bitten by the travel bug, he pursued multiple exchange semesters during his EE education (in Finland and the USA) before joining Silicon Labs in Oslo, Norway. Having started his career in the summer of 2014, Steven now works as the main mbed developer within Silicon Labs.

mbed enables Makers

2014 was our first ever Maker Faire and we enjoyed it so much that we are going back for more this week. I’m expecting to see many robots, connected things, wearables and who know what else passing by the ARM booth which can be found in Zone 2 near the main entrance – just look for the large ARM balloon. The event runs over the weekend of 16th-17th May with a corporate/press/education day on Friday 15th.


Come along to our booth and see how quickly you can get the eyes flashing on our robot for a chance to take an mbed development board home for your next project. We are fortunate enough to have some of our mbed Applications Engineers on site who will be able to answer questions from getting started with programming to senior engineers with tricky questions at companies shipping millions of gadgets per day.

Last year we ordered a new coffee machine for the office and it was working really well in the R&D department but it vanished for a few hours one day. Next thing we knew it had been retrofitted with a color sensor connected to an NXP LPC1768 mbed development board and connected to the cloud. From that moment on we all had our daily coffee intake monitored and the stock levels of Nespresso capsules were always replenished. This is what happens when mbed Engineers have access to 3D printers, sensors, development boards and a few wires. I managed to prise the coffee machine from the R&D team for a week and ship it over to our San Jose office ready to show (and tell) all about it this weekend. I forgot to tell the team that it will then fly to Taiwan and Shenzhen for the upcoming Maker Faires there – looks like productivity in the office could suffer in the coming weeks. /media/uploads/Phill_/nespressoimage.png

The Zebra technologies team will join us on the booth to show off their Connected Wine Rack demo. This seems to be a regular wine rack that one of their engineers decided to connect to the cloud in order to never run out of wine. The wine rack is covered with sensors to detect the presence of a smart wine bottle and report stock levels to the Zatar cloud platform. Again, this is what happens when engineers mix mbed and everyday objects. I just need to remember to bring the corkscrew.


As usual, there are plenty of events coming up so if anyone has any suggestions of embed powered things we should consider showing please let me know and we can work out a way to get it seen.

See you at the show (and tell).


mbed BLE Documentation: the Alpha Version

Hello. My name is Irit, and I am the new technical author at mbed. By way of introduction, I’d like to send you to the alpha version of our BLE documentation.

The BLE docs cover two use cases:

  1. Experienced developers who are interested in mbed BLE.
  2. People from outside the world of technology who are drawn to BLE to solve a particular issue and need a detailed introduction.

We’d like to ask for your feedback on these docs and suggestions for additional docs related to mbed BLE. Please comment on this blog post with ideas and questions.

Thank you,

Scheduled Maintenance Saturday 25th April

On Saturday 25th April 2015 developer.mbed.org will be offline for necessary network upgrades.

The site will be unavailable or only intermittently available between 9am PST (6pm UK, 2am on 26th Japan) and 3pm PST (midnight UK, 8am on 26th Japan).

We understand the inconvenience this will cause and apologise in advance.

UPDATE: This maintenance is now complete.