In a forum post has come the announcement that mBed, ARM’s accessible microcontroller development platform, is to reach end-of-life in July 2026. This means that the online platform and OS will no longer be supported by ARM, though the latter will remain an open source project. The website will be shuttered, and no new projects can be created after that date using ARM infrastructure.
mBed was originally launched back in 2009, as a competitor to the Arduino IDE for ARM’s chips. Its easy development made it attractive and there were soon an array of boards from different manufacturers supporting it, but perhaps due to its support for only the one architecture, it failed to find success. It’s certainly not the first time a single-architecture microcontroller development platform has been discontinued, we need only look to the Intel Edison for that, but given the success of ARM platforms in general it’s still something of a surprise. Perhaps it’s time to take the press release explanation that other platforms such as Arduino have simply been much more popular.
Will a community form around an open source mBed? Given that it’s been a definite minority among Hackaday projects over the years, while we hope it does, we’re not so sure.
mBed board image: Viswesr, CC BY-SA 3.0.
mbed was a great idea but was marred by bugs, partial (undocumented) support for hundreds of boards and then the release of mbedos. If they stuck to supporting 1-5 boards, squashed bugs as soon as they appeared, and made mbedos optional or at least more lightweight, I think they would’ve had more success.
In many ways, Zephyr RTOS is the spiritual successor to mbed, but unlike mbed, Zephyr gets many more things right.
at the same time, arduino’s IDE picked up support for targeting mbed so what was the point
I use mBed for one project (STM32F446RE MCU) – it is way better and easier to use than ST own cubeMX and HAL libraries. It is actually very convenient. Built in RTOS, sane API. Yes, there are rough edges and bugs, but IMHO still way better than ST HAL and cubeMX generator.
Zephyr is way different because of the devicetree – it is designed around premise that the hardware configuration is fixed. This is fine in some cases and not in others. For example in my case the connected hardware is defined by configuration received through network (after this network is initialized and operational) – it is not fixed. So no, zephyr is not a successor for mBed as it is far too different.
So i think there is really no replacement for mBed on STM32 now – Arduino is well Arduino, cubeMX is just terrible, and Zephyr has rigid hardware model (unless i am missing something, which is entirely possible)
Well Arduino might be able to run in 32-bit micros, but it is no replacement for mbed RTOS. In fact Arduino has no multitasking facilities to my knowledge, a library was in the making that used mbed dependencies. And FreeRTOS is just too difficult to work with.
So what is the alternative for those of us that have existing mbed projects? It is also used a lot in university courses to teach multitasking and concurrency. Why don’t they provide at least an offline means of compiling?
Not completely true, Arduino on ESP32 has multitasking capabilities. But yeah, that’s not on ARM.
FreeRTOS/Zephyr/NuttX are basically the only options that make sense in my opinion – all three of them have Large Vendor backers at this point and run on multiple hardware architectures, so they’re unlikely to go poof.
I was actually pretty surprised how many people used mBed. I’ve had multiple RTOSes go “poof” over the years and unlike “frameworks” like Arduino/etc. it’s much harder to swap code between RTOSes. So I’m pretty restrictive about jumping into an RTOS until I’m sure it’ll stick around.
Used it back in 2014 when I got a Freescale FRDM-K64 (if I remember correct) in a contest. Neat idea but really lacked options (I mean community projects and forums) where one would go for help. Also I remeber back then I was less experienced and it looked too complicated to do some things. Hopefully someone will maintain the open source part of it and maybe a brand will incorporate it and offer support.
I got one of the LPC1768 boards pictured in the article as part of a giveawaybut never really liked the online aspect (in part because the internet connection I was saddled with was rubbish) so it got stuffed in a cupboard. Few years ago I sampled a Maxim board which I was surprised to find used mbed.
Now I’ve got reliable and fast FTTP at home I might have tried it again but if they’re closing down, meh…
(though I do see to remember there was an offline offering at some point???)
At the end of the day its just an arm mcu, just like any other. Fire up your favorite IDE, add the hardware include headers and compile with GCC or something.
This is true, but back when, I was quite involved with development on Microchip PIC devices and ARM was a curiosity to me. I’ve since moved to STM32 and dabble instead of doing it for work.
I’ll dig out the LPC and Maxim board to have a play this weekend
If they focused their effort in documentation and bug fixes/better board, instead of focusing super hard on the online compiler they might have had a chance.
You can actually run mBed stuff just fine without the online environment, but they instead focused hard on the online environment as base. And that made it very unattractive for anything serious.
How much of the mBed experience is the online service anyway? If this is all replicated in the open-source component, it might not even matter?
I mean, then you are better off with Arduino anyway, download the IDE (or even use it online these days), at most burn the Arduino bootloader to it and you are set.
I once had a short look at MBED and did not like it much. Back then it was (nearly?) “cloud” only and it hides too much of the implementation in the libraries. That may be all righty for the “arduino” folks, but not if you want to do serious development. I guess MBED falls a bit in the middle with that. Too much for the “arduino crowd” and not good enough (bugs, bugs, bugs) for the “professionals”.
Just a few days I was (mildly) thinking about having another look at MBED. Not because I like the platform, but because it is apparently used by Expatria / Remora. Which is an STM32 step generator (hardware / software) for LinuxCNC.
My one experience with mBed left me so disgusted that I am glad to see it crash and burn. MCUs in general are great platforms to squeeze more or different functionality out of than their designers imagined at the time.
Like anything else which includes the kitchen sink and greases the skids to simplify a few common use cases it tends to lock you into a design paradigm that ends up excluding those off-the-edge-of-the-map use cases (because the HAL is, by definition, a lowest common denominator construct — when you abstract away the specifics you can’t really abuse that extra capability present in this one vendor’s version of the peripheral — and if the RTOS and driver framework expect everything to fit the HAL’s object model then they break too). This is particularly egregious when it comes to DMAs, configurable universal serial ports, and things like I2S.
What’s worse, it seems like many chip vendors seem to feel that contributing code (or even binary blob libraries) to make their chip work with such a framework absolves them of the need to provide a real datasheet with a full register map and clear description of any interconnected signals between peripherals (e.g. event signals you can mux to be interrupts, or to trigger ADCs to sample and convert, or to hit “go” on a DMA channel with a queue or chain of descriptors ready to go).
I’m just a bare metal type, so frameworks for those who want them are OK with me if and only if they don’t come at the expense of quality documentation for those who want (or need) to write bare metal code. My past experiences with quality documentation disappearing once the frameworks appear have been frequent enough, though, that I tend to wince whenever a new framework is announced…
Hi! I’m part of the Mbed Community Edition project. We forked Mbed OS back in 2022 when ARM stopped maintaining it, and have been steadily working on bugfixes, a build system redesign, and lots of other improvements. We are in the the process of adding support for ARM Arduino boards like the Nano 33 BLE and Portenta, but we still have compatibility with old boards like the FRDM K64F and LPC1768 (in fact, we support that one much better than the official IDE…), so your old hardware should be perfectly usable!
Feel free to check out our roadmap or give the hello world project a try! (links removed b/c I think my comment was being spam filtered, but you can look us up on github). We would love new users and contributors!
By the way, if anyone wants my two cents on why mbed died… I think it’s because it tried to be too many things to too many people. The project tried to create its own build system (twice!), its own Github clone, its own IDE (three times!), and its own network and bluetooth and USB stacks. And in most cases there wasn’t a good reason other than not-invented-here-ism by ARM. They had good ideas at times, especially in terms of making a web-based, zero setup IDE before anyone else really had, and using C++ objects to cleanly wrap and abstract microcontroller hardware. But there was so much jankiness at the core that they never bothered to actually dedicate effort to fixing, and the constant bugs, the kitchen sink of random features/drivers, and the spread-thin nature of Mbed OS development really turned a lot of people away.
In Mbed CE, rather than adding a lot of new features, I’d really like to just streamline access to what’s already there, and cut out all the crap that isn’t actually needed for working with the OS. That’s why we’ve switched to a standard CMake based build system and a dev workflow based around CLion, VS Code, or the command line. And we are focusing on building a new, better testing system to replace ARM’s CI setup!
Once I thought contributing fixes to the mbed for various boards, but after looking at their contributing guidelines, that idea was quickly deemed silly.
I think the reason it is being shuttered is because it doesn’t make commercial sense to ARM, not because of any technical failings. There was probably a hope that it would drive ‘pull through’ sales of general purpose ARM MCU’s, but if it did, that part of ARM’s business remains dwarfed by the IP revenue from Apple, Samsung etc. I do agree they lost their way by having to many boards and then ditching the initial very simple API and RTOS concept and online compiler for an altogether more complicated and messy user interface. I have in any event since started to transition across to the ST platform. Not perfect, but it’s stable and you know where you stand as a developer.