Mbed end of life announcement

Oww, I didn't see that coming. I'm a bit of a fanboy of their C++ code. To my taste, they used the right style to OO embedded thingies (pins, interrupts, timers, callbacks peripherals). They were an inspiration for a post I wrote a few weeks ago:  C++ callbacks and templates .

I have dozens of projects stored in their cloud, mainly using NXP/Freescale parts (and occasionally used locally-installed Mbed) but have not used it for a few years. It has very high quality libraries.

I'm guessing that maybe chip manufacturers paid ARM to port their microcontroller dev-boards to be part of the ecosystem. Less and less boards have been added over the years : (

Good that they have provided at least a proper EoL announcement with a reasonable amount of time.

It do not surprise me. ARM basically terminated all their SW efforts. In my opinion they did them only for making attractive SW hard to port to RISC-V. What a irony that their Bluetooth stack Cordio was forked and now runs mainly on RISC-V cores.

What did they do to make it hard to port?

 ntewinkel  in the World of ARM yet another bites the dust, the crowd is thinning. So let's see what's in the graveyard. SPARC and TI offerings are still around but no new movement. So what are our global choices? X-86 (intel and AMD are slugging it out, BUT Intel just bought the entire book of AMSL! They now will win the speed race, the next move is AMDs. ) and ARM as well as some other crud floating around! ~~ RIP Cris H. 

Sigh.  Arduino actually has several boards that are built on top of Mbed.  (Several Nordic Semi boards, some STM32 boards, and the RPi rp2040.  Basically, stuff that is expected to run a network stack (but not ESP32, which runs FreeRTOS))  I wonder what they'll be doing?

Oh wow, I did not know that Bluetooth Cordio lives on. That's interesting.

Personally, I never understood the logic behind ARM terminating the MbedOS SW efforts the way that they did. They promised to keep it up and then left the community hanging for months. Rotten behaviour, IMHO. I felt that this was driven by corporate IPO desire/greed rather a strategic aim of fostering the right software ecosystem for vendors and users alike. They still do software as they maintain the CMSIS library and MbedOS was built on top of this. So, it seems bizarre.

Personally, I much preferred using Mbed 6 to Mbed 5, which everyone still remembers as it was free to use on the cloud. But, lets be honest here, MbedOS 5 was a chaotic mess. The whole thing was driven by a vision but it was not managed very well. Maybe vendors got cheesed off. Then, I still remember the huge effort they put in to port everything onto GitHub and then getting the whole issue and pull request process up and running for MbedOS 6. They also introduced the Thia-based Mbed IDE, which I liked too. Maybe the ARM dev team tipped in the opposite direction where control took precedence over speed. As things did get bogged down.

So when it all started to unravel, it was the peripheral connectivity libraries like Cordio that suffered most. They never updated quick enough. I certainly could never get it to work properly and I spent too much time correcting outdated drivers in Cordio for my own needs. The documentation was always out of date.

However, I still found it much easier to use than Zephyr RTOS, for example, but I think Zephyr has now finally caught up. But it is spread out far too thin... almost a bit like MbedOS 5... trying to cater for too many dev platforms.

It will be interesting to see what Arduino do next, as they were one of the very few who actually made Mbed 6 work very well. Maybe they will switch over to Zephyr too. We will have to wait and see.

Mbed was lame. Made dealing with and teaching Arduino stuff harder. The only cool thing about them is that a bunch of people have given me their kits after they give up when this platform is too confusing. Ardunio wrote the docs for you... how could you bork this up?

I inpolitely disagree :)

The idea was good, in my opinion, but probably got lost in implementation.

I remember trying an LED blinking "Hello World" project on MBED 5, which had 50 kB (half of my STM32L0's flash memory). The worst part was, I could see with my eyes, that the blinking is not regular. Somehow scheduler and probably another tasks (I didn't want any) was overloading an MCU at 32 MHz.