WIll mbed-os get back its previous pace of development?

mbed-os development seems to have really slowed down. Did arm move some folks to other teams?

Or is it just done beyond bug and security fixes now?


I’m definitely feeling the same way. Especially with the LoRa libraries and examples.

I believe it’s because Jan Jongboom left ARM

Hi John,

There’s been a lot of changes in Arm over the past six months or so that you may have seen, i.e. Pelion, which the Mbed team were part of, is now a separate company, wholly owned by Softbank. The core of the Mbed team is now part of the open source software team within Arm.

At the same time, Arm has been conducting a strategic overview of our IoT software and begun to make announcements around this, the first of which were made at DevSummit last October. One of the key parts of this is Project Centauri , which is pulling together industry and security standards to provide foundational software for Cortex-M based microcontrollers. We in the Mbed team are, along with other development teams in Arm, working on a longer term roadmap that brings this together with Mbed, CMSIS, TF-M and other technologies to simplify IoT development, which is, we think, one of the core tenets of Mbed.

So in the short term, we’ve slowed down Mbed work to give the team some space to conduct the engineering investigations needed to underpin this roadmap. We plan to share more on this work in the next few months, so I will update you when we have more details that we can share publicly.


thanks also for the insights.
I’m missing more marketing power for Mbed. ARM has invested a lot into Mbed and Mbed-OS is a great product. The only problem: really nobody does know it.
I have promoted it now for many years in a german forum, but the feedback is zero. The only known platform is Arduino and that is really a pitty. Well, one hurdle is C++, not everybody likes it and especially in embedded system there are still a lot of prejudices. I wish ARM would publish more articles about Mbed and also try to push it for comercial products. I have tried this also in our company, but its very hard because there are no partner companies for consulting or offering programming services.
Mbed is not only good for IoT and security, but also for a lot of other products. There need to be more focus on custom targets, because you cannot use a Nucleo board for commercial products e.g. And actually, an OS is a great help when you have to switch to some other MCU because of chip shortage.
So please, don’t slow down and don’t let Mbed die.


I agree with @JojoS, mbed is a great framework and we use it for our commercial product.

If there are less people on mbed’s side, why not let the community take a real part in the development?

Big open source project like Homebrew on macOS do it and it works great.


Mbed has been the go-to development platform for me, its API based focus is the way to go, unlike others. I am positive Mbed will go on to greater heights in the exciting world of IOT and security.

1 Like

yes, but also the simple switching between an OS with or without RT is unique. Support for USB, Ethernet, Storage, Connectivity, everything at a very high level, thats not only IoT. That needs definetely more attention!

Sounds like there’s too many chiefs in place creating new strategic plans and not enough people on the ground doing the simple stuff like cleaning up websites, sorting out documentation and archiving old Mbed 2.x examples.

Mbed 6.x is actually very good but it’s reputation is being damaged, in my opinion, simply because when you search online all that comes up is legacy Mbed 2.x stuff, which of course is no longer relevant. Simply putting “deprecated” on all the old Mbed 2.x webpages basically adds fuel to the perception that things are being wound done.


Personally I kind of wish it would be handed over to Linaro along with CMSIS-RTOS.

Then see if any synergy can be gained with the Zephyr Project.

Shouldn’t this slowdown and roadmap changes been published on the mbed blog when it happened?



Yes, I too have been trying to work out where the Zephyr Project fits within this broader ARM embedded ecosystem development roadmap.

Nordic Semiconductor, for example, are now making a big push with their newer nRF Connect SDK, which is based on Zephyr OS and includes many new connectivity features like BLE Mesh and Matter. Only MbedOS TLS is included. So if you want to use these features you have to take the plunge. Having decided to do so I had to go through a whole install process (for VSC rather than SES IDE) and it was a rather convoluted process that lacks system maturity. Mbed Studio is now so much better.

So, in my opinion ZephyrOS is where MbedOS 2 was where everyone (as in vendors like Nordic Semiconductor) jumped on board as it’s new. This is a real pity as MbedOS 6.x is a more mature system and the documentation is now much better (although getting to code examples and libraries is still a pain point). So what is MbedOS doing on the connectivity front. What plans are there to include Zigbee, Matter, Thread etc. Are the hardware vendors giving MbedOS the cold shoulder or is it something else.

Is this related to some of the non core aspects, I wonder. For example, why only pyOCD as flasher/debugger with Mbed Studio. Is Segger J-Link excluded or is there some licensing issue or something else in the background the caused them not to facilitate and support J-Link being used. There was a comment in this forum post, but little has changed: Segger J-Link Support

So it’s all up in the air and the Mbed team need to do more to explain in their blog and promote MbedOS 6.x better.

1 Like

Arm’s owner SoftBank is in financial trouble, there is also good chance that NVDIA won’t be able to take ARM over. It is remarkable Mbed OS has come so far, but without continuous and considerable financial backing, I am afraid development of Mbed will slow down in the foreseeable future.

Is there any news? Please do not let Mbed die.


Just heard the bad news :frowning:

What does it mean for mbed-os?

Time to start a community driven fork @MultipleMonomials?

1 Like

I’d still like to hear something from the Mbed team themselves before getting seriously into this. But it’s true: Ladislas and I have been mulling over the idea of creating a community-supported fork of Mbed (Mbed CE?) to keep development going if Arm is no longer maintaining the OS. If anyone else is interested, feel free to chime in!

I"m maybe interested, but it seems like it’d be a lot to maintain the whole thing. I’m not that concerned about the “core” of the OS as the useful APIs on top though. I guess I’d rather see the existing APIs as an abstraction on top of a Zephyr or other existing RTOS.

Well in defense of ARM, the project is still open-source and PRs are being merged by Martin. Nobody is holding back people from proposing and submitting changes. What would a fork change in this case?

I believe that without active development by ARM, there is not enough community activity to keep the project up-to-date in the long term.


Do things that the main project would not want to do because of different reasons. Being more cutting edge in terms of technologies and tools. Things such as moving to c++20 and upgrading the code base, reworking the cmake build system to get rid of interface, introducing more class interfaces and/or concepts for runtime/compile time polymorphism, etc.

Have the ability to remove everything that we don’t use and add them back on a as needed basis, for example the targets that only the maintainers of the community fork are using.

It would not replace the main project and PRs would be made to bring back the improvements.


Personally, I’ve had a very frustrating experience trying to contribute to Mbed OS, with several of my PRs being rejected, often after months of debate and/or months of silence. PRs like:

  • Updating the legacy build system to have un-ignore functionality in .mbedignore files
  • Reworking the CMake build system to replace INTERFACE libs with OBJECTs
  • Adding the ability to easily flash code directly from a CMake target

I would hope that a community fork of Mbed would be more amenable to merging changes that make the build system more polished and convenient for serious development work.

Some other things that come to mind:

  • Mainline Mbed is limited by the fact that they only support devices whose manufacturers are willing to contribute ports. Several manufacturers, like Microchip/Atmel, TI, and Infineon, seem to
    be uninterested in doing this, so their devices are not supported in Mbed. In a community model, where each device has its own “maintainer”, it would be possible for community members to add support for these devices.
  • Mbed OS has a pretty poor track record of bugginess in general, and this is NOT helped by that shady thing they did a few months ago where they closed every bug report that had been inactive for more than a few months, even though the large majority of the reports described real issues. A fork could hopefully have a better focus on fixing serious bugs before adding new features. Also, while Mbed only tests new changes on just a few physical chips, hopefully a fork could have a more serious device farm that would have a better chance of catching issues before they became a problem.

seems like it’d be better to base it on something like zephyr if you really wanted better board support.

I really like the user visible api of mbed-os, but it’d be nice not to have to deal with all the internals and let a larger community handle that.

This is especially the case in the BLE area, where cordio still has problems and isn’t developed in the usual open source way, unlike zephyr’s stack.

1 Like