By Bill Lamie
President/CEO, PX5
There is a seemingly endless number of RTOSes used with embedded MCUs, most of which have their own proprietary functionally as well as a unique API. Some of the RTOS APIs are good, and some not quite as good. In reality, the delta between a good and less-good RTOS API is quite small — most RTOS APIs will do the trick. As I look back on the past 30+ years, I’ve come to realize propriety RTOS APIs have had and continue to have a profound negative impact on embedded software development and on the embedded industry as a whole.
First and foremost, the proprietary RTOS API represents a lock-in for the application firmware. Code written using a proprietary RTOS API must be changed in order to move to a different RTOS. Worse, the changes required to move to another RTOS can be daunting. Some RTOS vendors have added an adaptation layer in an attempt to support other RTOS APIs. However, this solution is less than ideal as it often tries to fit a square peg in a round hole. Not to mention additional layers greatly increase overhead as well as complexity of the RTOS, which in turn can result in errors.
In any case, not being able to easily migrate embedded application code can severely limit the evolution of a product. For example, if an application is dependent on RTOS XYZ and it doesn’t support the latest and greatest processor, the application developer either needs to modify the code base to move to another RTOS, wait until RTOS XYX adds support, or just give up. Similarly, migrating an RTOS XYZ-based application to embedded Linux (another very common situation), is difficult because multithreading in embedded Linux is based on the POSIX pthreads API. A standard RTOS API would help eliminate lock-in, thereby making embedded applications more portable and enhancing their future evolution.
Proprietary RTOS APIs also require extensive training. Most developers using an RTOS for the first time have to spend significant cycles learning the proprietary RTOS API. Even embedded software developers using FreeRTOS or Microsoft’s Azure RTOS, ThreadX – both popular embedded RTOSes, each having their own proprietary API – represent a fairly small percentage of the total number of software developers. The point here is that proprietary RTOS APIs necessitate learning, which costs companies time and money. An industry-standard RTOS API would reduce training and, as a result, save money and improve device maker’s time-to-market.
Another issue is that some device makers have product families that span both MCU and MPU processors, typically with different functionality and price points. Their MPU-based products frequently use some flavor of embedded Linux. For these companies, having to maintain separate development teams (and code bases) because of a proprietary RTOS API is both difficult and costly. With a standard RTOS API, application code could be instantly shared between MPU- and MCU-based projects, improving the entire development process, from coding and testing to product release.
Before we go further, credit should be given to Arm, since they identified this problem in the embedded industry many years ago and even tried to address it with the CMSIS-RTOS API. Unfortunately, the CMSIS RTOS API is ultimately yet another proprietary RTOS API.
Back to what the standard RTOS API should be. Amusingly, the answer has been right in front of us for many years: The standard RTOS API should be the same industry-standard POSIX pthread API, which is already part of every embedded Linux distribution, as well as every university computer science curriculum. Since embedded Linux represents 70% of the embedded designs, it’s easy to argue that the POSIX pthread API is already the RTOS API standard in the embedded software space and what most embedded developers are already familiar with.
Furthermore, the POSIX pthread APIs have been tested on UNIX/Linux systems for over 30 years. Coupling hard real-time RTOS capabilities with this industrial standard API promises embedded developers the best of both worlds. Our industry just needs the various RTOS providers to natively adopt it. Uniting the embedded software industry on the POSIX pthread API standard would eliminate vendor lock-in, accelerate embedded product evolution, reduce training, and instantly enable code sharing and migration between MCU- and MPU-class devices – all of which represents a significant step forward for the embedded industry.