The History of Mbed OS and Mbed CE

This page will go into more detail about the various versions of Mbed that have existed, and how we ended up where we are.

Mbed OS History

The first public release of Mbed was Mbed 2 (no "OS" yet), which was created by ARM in 2009 for its Mbed LPC1768 board (and eventually a few others). This release didn't contain an RTOS or networking support, and resembled the current "bare metal" version of Mbed CE in terms of functionality. Mbed 2 leaned heavily into its Online Compiler feature to provide a zero setup way to develop code, making it a favorite of hobbyist users and educators.

Next up, in 2015, was Mbed OS 3, which added more networking and IoT features, and embraced an event driven (non-threaded) architecture, as well as a new build system (yotta) that split the codebase over multiple repos. This was soon scrapped, however, and the next version, Mbed OS 5, returned to a single mono-repo and integrated the Keil RTX RTOS to provide threading support. Mbed OS 5 also introduced a new offline build system, which relied on a huge mass of homegrown Python scripts to scan the project, calculate build flags, and then actually build the code.

A few years later, in 2020, Mbed OS 6 was released, which was a more incremental change than previous releases -- it made a number of breaking changes to the API and file structure, but didn't fundamentally affect how Mbed OS was developed or what it did. Soon after Mbed 6 released, however, ARM made the announcement that they were investigating rewriting its build system in CMake to make Mbed easier to maintain and more extensible. This effort seemed promising, until...

In late 2021, the situation at ARM took a turn for the worse. A two-year effort for Nvidia to acquire ARM fell through (which is likely a good thing on the balance, it would have created a massive chip monopoly). However, this led to layoffs and restructuring, and soon contributors & users noticed that development activity on Mbed OS drastically slowed down. In January 2022, project developer Andy Powers announced that Mbed development would be paused for a few months as ARM's staff who worked on Mbed had been temporarily retasked. Another update from ARM... never came, until the sudden announcement in July 2024 that the Mbed OS project was being end-of-lifed by ARM.

Why EoL?

Why did the end of life happen? Well, to get on my soapbox for a minute, I think that ARM Mbed OS 6 had three major issues.

First of all, it was very expensive for ARM to maintain. Not only did they have to employ quite a few developers to maintain Mbed and its website infrastructure (including Mbed's clone of GitHub), but there was also the Online Compiler to deal with. This compiler worked by building your code and Mbed itself on a remote machine, then downloading the compiled bin file onto your computer for installation. Compiling Mbed was slow, especially with the old build system and the bloated Mbed 5 codebase, so I imagine it cost ARM several minutes of CPU time on one of their servers every time someone pressed build.

Second of all, Mbed OS was struggling with its quality, and had been for a while, especially across the wider range of boards it supported. Mbed OS 5/6 used the development model that MCU vendors had to contribute their own ports of Mbed's drivers if they wanted Mbed support on their boards. This meant that lots of developers with relatively little Mbed OS experience were contributing features, and little meaningful review or testing of these ports was done by ARM -- vendors just had to attest that they'd tested things on their own hardware. Even ports that had first-party testing done by ARM still had major issues -- from 2018 until 2021, much of the I2C functionality on STM32 devices was badly broken due to a one line mistake that caused every byte after the first one transferred to fail to go through. The half-baked changes and limited testing led to bugs, bugs, and more bugs, most of which the Mbed developers either referred to the vendor (who might or might not care enough to fix them), or simply ignored until they were closed (due to "inactivity").

While minor, there was also a lot of confusion for users over the different versions of Mbed. Since Mbed 2 was apparently the most popular version of Mbed, and still had a significant user base well into the 2010s, many of the most popular libraries and tutorials still referenced it. This (plus some awful SEO on ARM's part that made the Mbed 2 pages show up first in search results) led to an extremely confusing experience for users. A lot of common examples and projects just didn't work on the board you had, either because the port was bugged, or because the code was from an older version of Mbed. I'm ultimately guessing based on what I saw from forum posts over the years, but I suspect that Mbed OS users often struggled with these issues, and that the user experience generally got worse over the years.

The quality issues, as well as the rise in competition from other embedded frameworks like Arduino, NuttX, and Zephyr, led to Mbed OS 5/6 being "pigeonholed" as an OS for education and hobbyist use. Educators loved it because it was easy for students to set up -- it was better than even Arduino, as it didn't require any local installation at all. And hobbyists enjoyed it because it was easy to get started, and hobbyist projects often didn't stress Mbed enough to hit its limitations. However, most corporate users shunned it, because it didn't take too much probing to hit serious bugs and limitations -- and requiring an Internet connection for a build, unless you went out of your way to install things locally, likely didn't help either. Additionally, there is a perception, IMO largely thanks to Arduino, that high-level HAL libraries, especially C++ ones, are too limiting and not appropriate for serious usage. These factors meant that serious company projects, which would have brought in significant new business to ARM, weren't using Mbed very often.

My suspicion is that the expenses, quality issues, and lack of serious users combined to sour ARM's management on Mbed OS. They likely decided that the benefits it brought in (introducing users to ARM chips, helping people get started with embedded software more easily, and making it easy for Mbed projects to move between different ARM chips) were not worth the cost of maintaining Mbed. I don't agree with this decision -- it seems shortsighted -- but we have to live with it. And ARM's decision to EoL Mbed OS 6 created the opportunity for Mbed CE to exist!

Mbed CE History

Jamie Smith had been involved in a couple of projects related to improving Mbed and its build system. In 2021, while a student at USC Rocket Propulsion Lab, he created the mbed-cmake project, which was a way to compile Mbed 2, 5, and 6 locally using a CMake build system that interoperated with the Mbed CLI python scripts. He then worked together with ARM developers on Mbed 6's prototype CMake build system, and also contributed some other features and fixes to Mbed (such as fixing the aforementioned STM32 I2C bug).

When ARM stopped development of Mbed OS 6, he independently finished the CMake build system prototype and spun it off into its own project: Mbed OS Community Edition. That brings us to today: we have been growing the Mbed CE project, slowly but surely, to try and fill the Mbed OS-shaped hole in the world without support or backing from ARM. While we aren't are parity yet (there's not really a hope of something like the Online Compiler), I hope that you will find Mbed CE to be perfectly usable for what you need.