MBED started out as a board and an IDE. The board was special, because it presented itself as a USB memory disk, allowing people to upload by simply dragging the firmware to it. The IDE was special because it was web-based, requiring no setup whatsoever.

A very potent mix:

1. purchase a board, and plug it in via USB
2. click on the one HTML file which appears on the USB disk
3. the browser takes you to the MBED site, which needs a free initial sign-up
4. go to the compiler / IDE, pick a demo, select your board
5. press “Compile”, which finishes with a file on your disk called “firmware.bin”
6. drag the file to the USB drive, and voilá… the demo starts up

A far cry from having to download and install a huge IDE, figure out how to start it up, load a demo, compile, and upload to an attached board. Which never works on first try, because you have to install a USB driver, figure out COM ports or TTY devices, etc, etc, etc.

That’s how MBED started. But this has evolved quite a bit further:

• there are now over 60 boards, all supported by the MBED IDE
• IDE projects can be exported and turned into a local source + build tree
• lots of documentation, a code browser, and a massive community
• a large set of software components (libraries), ready to use in your projects
• newer “MBED enabled” boards support simultaneous h/w debugging + serial I/O
• the recent versions of the runtime libraries include an optional real-time OS

MBED is very much an ARM-only environment, but since the range of ARM µC’s and ARM-based boards is so enormous, this is really not limiting in any way. From the most power-efficient “Gecko” boards by Silicon Labs, to the extensive ARM Cortex M4F boards by NXP and STM32, with megabytes of flash and RAM memory – it’s all there.

MBED is not just a set of boards and an IDE, though. It’s also the name of the runtime library which allows much of the code to run on different boards, from many vendors.

This generality has its price, unfortunately: code size. A minimal project in MBED is at least 2..3 KB, and adding a serial port with printf will quickly raise the size to over 10 KB. This need not be a problem, if the µC has plenty of flash memory. But on an LPC824 with 32 KB flash, the “hit” of this initial code footprint is noticeable and could easily become an issue when adding more libraries (especially if written to handle many “general” cases).

Here is an example of a minimal LED blink demo:

#include "mbed.h"

DigitalOut myled (P0_23); // pin 1 on TSSOP-20

int main() {
    while(1) {
        myled = 1;
        wait_ms(200);
        myled = 0;
        wait_ms(200);
    }
}

This compiles to 2,388 bytes in the online IDE (which uses a highly optimising proprietary compiler), and 2,880 bytes when compiled locally with arm-none-eabi-gcc and “-Os”.

Here’s a minimal serial port + printf demo:

#include "mbed.h"

Serial pc (P0_4, P0_0); // tx, rx

int main() {
    pc.baud(115200);
    pc.printf("Hello %s!\n", "World");
    while(1) {
        wait_ms(200);
        pc.printf("ping\n");
    }
}

Code size: 11,576 bytes (online IDE) and 15,192 bytes (local “gcc -Os”).

It’s hard to tell at this point how much further the code will grow as real application code gets added. But having half of the LPC824’s flash consumed already does not bode well.

[Back to article index]