The embedded RTOS vendors are being removed from the embedded market at an alarming rate, with three major players absorbed in the last couple of years: Express Logic by Microsoft, FreeRTOS by Amazon and Micrium by Silicon Labs. By my estimations there were about 50 similar companies 12 years ago; now, at most, a handful remain. How does this affect the embedded industry overall and developers in particular?

What is the Fuss Around RTOSes?

I am a little perplexed by the fuss about RTOSes. Back in the 1990s, your choice of RTOS could be very important to your ability to reach your design goals. The whole concept was relatively new, microcontrollers were relatively slow, and context-switch time was actually important. But microcontroller performance accelerated through the early 2000s, rendering context-switch time less relevant. There evolved many well-proven RTOSes that do a reliable job, meaning that for 95 percent of applications, the choice of RTOS could be based on what you know and love or just gut instinct.

MCUs are quirky – the countless variants are designed to satisfy a huge range of applications. Software engineers use the C language (or similar) to hide the details of the instruction set but when it comes to the RTOS, although what each RTOS achieves is very similar, a standard has failed to reach de facto status. As a result, although the comparatively complex MCU instruction set is transparent to the application developer the relatively simple RTOS has defied standardization.

What is the Silicon Vendor’s Strategy?

In the case of the Micrium and Express Logic acquisitions, you could argue that the acquiring companies bought much more than an RTOS. The products acquired included extensive ranges of middleware and infrastructure (though it remains to be seen exactly what aspects of Express Logic Microsoft hopes to exploit).

When Silicon Labs acquired Micrium, the purpose of the acquisition seemed clear as part of a trend. The silicon vendors wanted to minimize their customers’ costs on supporting software, both in terms of effort and licensing, and make it easier for them to develop products cost-effectively. All major MCU vendors have a strategy for this and they all continue to enhance their software ecosystems.

But for the device developer who wants flexibility in their choice of MCU, this creates a problem: Once they develop an application to one silicon vendor’s ecosystem, it is expensive to change.

ARM tried to address this with embedded and CMSIS, but this restricts developers to some ARM architectures. What happens if they want to change to something else, such as the fast-developing RISC-V architecture?

How Will all These Ecosystems Work with the IoT?

Each MCU silicon vendor has its own ecosystem (SiLabs/Micrium, ST/STCube, TI/TiRTOS, Microchip/Harmony, etc.) based on different, but similar components. But now Amazon and Microsoft have each acquired its own, different core technology for building an MCU/embedded ecosystem to enable IoT devices for its respective cloud platforms (AWS and Azure). The big question here is how this will play out. Will the silicon ecosystems be forced to create compatibility with both AWS and Azure if they want to stay in these markets?

The Elusive Goal of a Common Embedded Ecosystem

To summarize all of the above, the push to standardize embedded development has been initiated from three different directions:

1. The silicon vendors developing ecosystems for all of their customers
2. The MCU architecture vendors developing a system independent of silicon providers but dependent on MCU architecture (e.g., ARM CMSIS)
3. The IoT giants creating their own ideas of embedded standardization

You could also argue that several other attempts at different levels have occurred such as OSEK for automotive, ARINC653 for aerospace, or even POSIX. The point is that the whole thing remains pretty ugly if you are investing heavily in a new device and you want some flexibility in design for the future, such as price or function competition in the silicon you choose. Integrating with a proprietary system limits both your design and business options.

Why Should we Worry About the RTOS?

All these options notwithstanding, what is needed by 95 percent of embedded applications from an RTOS is straightforward. There are four core functions that need to be realized:

• Prioritized tasks to do chunks of work
• Events for signaling between tasks
• Mutexes for protecting shared resources
• Interrupt handling

If your RTOS can do these, then most embedded applications are viable. Sure, different RTOSes have different (and useful) extensions, but in the end they are building on these four basic concepts.

With this in mind, it makes a lot of sense for enterprises to define what the RTOS interface is and use that interface across all their product development. When the need to move between RTOSes arises, for whatever reason, only the porting layer needs to be ported. The investment in your application is protected, which gives you more reason to invest more heavily in perfecting your application code – it is going to be reusable!

Conceptually this is not difficult to do. HCC Embedded adopted this strategy in about 2007 because we were developing middleware that we wanted to be available on any platform regardless of MCU architecture, endianness, compiler, and RTOS. We have successfully built hundreds of modules for networking, file systems, flash management, and USB that have no conditional code and run seamlessly with 40 different RTOSes – or even without an RTOS. (Access our webinar on the topic here: https://www.hcc-embedded.com/webinar-developing-rtos-independent-code-in-embedded-designs/

The Big Takeaway: Take Back Control!

Decide what your organization needs from an RTOS, define that abstraction and build your products for the abstraction. Then just port it when circumstances change (e.g., Microsoft buys Express Logic or you change to a microcontroller with a different ecosystem).

C compilers hid the MCU instruction set from you and the RTOS is the next building block on top of this. It seems a natural process to abstract the RTOS and further isolate your applications from implementation details, and thereby protect the value of your development.

Now all we need is a standard for this abstraction. Unfortunately, that takes us full circle – there is no obvious body that would manage this. For now, we must do this ourselves, taking comfort in the knowledge that if a standard is adopted at some point in history it is likely to be a straightforward process to adopt it.