By Max Maxfield
eejournal.com
Every now and then, I get to meet someone who is a legend in their own lifetime (I flatter myself that I’m a legend in my own lunchtime, but that’s far less prestigious and much easier to achieve). I was just chatting with one such person who, over the years, has created multiple de facto standard real-time operating system (RTOS) solutions.
Three of these solutions—Nucleus RTX, Nucleus PLUS, and ThreadX—are household names. Well, they are if you happen to live in a household with someone who works with RTOSes. These little rascals currently run in billions of embedded devices around the world.
The man in question is Bill Lamie, who is President and CEO of PX5 RTOS. The only reason Bill’s latest and greatest offering, PX5, isn’t on everybody’s lips is that this new RTOS for the 21st century became available to the market only a couple of weeks ago as I pen these words.
I was fortunate enough to get to chat with Bill earlier this week. Our conversation covered many topics, including the fact that Bill opted to take a class in typing at high school, which (he says) has paid him back a thousand times. My mother begged me to learn to type when I was a young lad, but that was in the early 1970s before computers became a “thing” and I couldn’t see the point (a decision that has paid me back a thousand times, but not in a good way).
Sad to relate, we don’t have the time to cover this wide-ranging conversation in its entirety, so I will summarize it in a crunchy nutshell as follows:
#1: With over three billion users scattered around the globe, Linux is one of the most popular operating systems in the world. Furthermore, in the demanding embedded systems industry, Embedded Linux accounts for approximately 70% of embedded designs.
#2: Originating in the 1980s, the Portable Operating System Interface (POSIX) is a family of standards specified by the IEEE Computer Society. Amongst other things, POSIX defines an application programming interface (API) to provide software compatibility (portability) with variants of Unix, Linux, and other operating systems.
#3: In the old days, the only thing you could do with Linux on the multi-threading front was process-oriented, and process behavior was really, really overhead-laden. To address this, circa the mid-1990s, the IEEE folks came out with a POSIX standard for putting multi-threading inside processes, thereby providing a lighter weight way to do things like context switching and dividing the application into pieces. POSIX Threads, commonly known as pthreads, is a parallel execution model that exists independently from a language, allowing a program to control multiple different flows of work that overlap in time.
#4: We can think of pthreads as being a standards-based API for multithreaded applications developed in C/C++. It’s included in all Embedded Linux distributions. It helps with code portability and re-use. And, most importantly, most software developers are already familiar with the pthreads API.
#5: Sad to relate, Embedded Linux is not ideal for all applications. It doesn’t offer hard real-time in terms of interrupt latency, determinism, context switching, and service overhead. Also, it’s too large and complex for use on microcontroller units (MCUs) lacking a memory management unit (MMU) and with limited resources in terms of memory, CPU performance, and battery life.
#6: “Why not use an existing RTOS?” I hear you cry. I’m glad you asked. The problem is that each RTOS has its own proprietary API, and legacy requirements make it difficult to re-code the native API, so most RTOSes don’t support the pthreads API. Having said this, some RTOSes do offer a “pthreads API adaptation layer,” which is often developed as a “quick and dirty” solution that involves converting calls from the pthreads API to the RTOS’s native API, resulting in increased code size and increased execution time for all services, thereby delaying real-time responses and degrading system performance.
I’m sure you can see where I’m going with all this. If not, then my name isn’t “Max the Magnificent” (feel free to imagine this name being proclaimed in deep, dulcet tones by James Earl Jones accompanied by a fanfare of sarrusophones).
Yes! You are right! PX5 RTOS (the company) has just announced PX5 RTOS (the… well, RTOS). PX5 is an advanced 5th-generation RTOS designed for the most sophisticated embedded applications. As we learn in this video, this bodacious beauty has been architected from the ground up to provide the best-of-the-best in RTOS technology and, best of all, it employs a native implementation of the industry-standard, well known, familiar, IEEE POSIX pthreads API.
This native RTOS implementation provides enhanced speed and efficiency, boasting non-layered, direct implementation of all services, sub-microsecond API service performance, sub-microsecond context switching, and deterministic, hard real-time response. Even better, it offers all of this in an MCU-sized small memory footprint (typically 1KB to 10KB for code with as little as 1KB of RAM). What’s not to love?
PX5 is both safe and secure, with 100% statement and branch condition tested and verified, unique pointer/data verification (PDV) technology for memory corruption detection and mitigation, clean static analysis of the entire code base, and it’s MISRA compliant (with few exceptions). Safety certifications coming in 2023 include IEC 61508, IEC 62304, ISO 26262, and more.
In addition to coming out of the gate with broad development tools support, instructive tutorials, whitepapers, how-to-videos, and full source code, the PX5 business model features royalty-free, commercially friendly licensing.
Are you as excited by all of this as your humble narrator (I pride myself on my humility)? I know some people who are. For example, I also had a chat with Trish Messiter, who is CEO at Clarinox Technologies. The guys and gals at Clarinox specialize in software solutions for wireless communication, offering state-of-the-art wireless protocol stacks for Bluetooth and WiFi under the product names of ClarinoxBlue and ClarinoxWiFi (I’ll leave it as an exercise for the reader to guess which is which).
They also provide specialized debugging in the form of the ClariFi embedded wireless debugger to help developers quickly and easily troubleshoot and optimize their ClarinoxBlue and ClarinoxWiFi wireless-enabled devices. As Trish told me, debugging wireless systems can be like trying to locate a black cat in a dark room (I usually find ours by accidently standing on it). ClariFi is designed to illuminate the problem by providing detailed information about the operation of the wireless protocol stack and the underlying software, firmware, and hardware layers, thereby making it easier to identify and resolve issues.
Trish told me that the partnership between Clarinox and PX5 will bring a strong offering to the market by combining the robust RTOS capabilities of PX5 with Clarinox’s expertise in wireless communication. Since the folks at Clarinox already work with other high-performance OSes offering POSIX support (e.g., Linux/QNX), they see PX5 as being a great move to enable wireless connectivity in resource-constrained embedded systems.
I also got to chat with Steve DeLaney, who is President at Cypherbridge Systems. Established in 2005, Cypherbridge is a technology R&D company on a mission to deliver solutions for authentication and trust, electronic data privacy, and integrity. The chaps and chapesses at Cypherbridge supply standalone, IoT, and cloud-connected software development kits (SDKs) and toolkits.
The reason I’m waffling on about this here is that, on 25 January 2023, Cypherbridge announced the integration of its SDKPac and uLoadXL IoT software with the new PX5 RTOS. The Cypherbridge SDKPac offers comprehensive standards-based secure communications protocols and interoperable software libraries for a wide range of applications, including industrial control, medical device, energy, and transportation. The uLoadXL secure boot and software update SDK anchors the IoT platform root of trust (RoT), authenticating and integrity checking PX5 RTOS-based system applications. Managed software updates are securely distributed over-the air (OTA) and installed on the target product.
But wait, there’s more, because everywhere I turn, I hear from more companies who are jumping on the PX5 RTOS bandwagon. Whilst writing this column, for example, I heard from the lads and lasses at IAR Systems saying: “The PX5 RTOS has just been launched and IAR Systems, the world leader in software and services for embedded development, already offers full support for this new real-time operating system.” Wow! That was fast!
There are so many ramifications to all of this that it makes my head spin. For example, a lot of Embedded Linux developers steer clear of RTOSes because they don’t want to learn a proprietary API. However, for anyone who is already creating applications using the pthreads API, it’s going to be relatively easy for them to start using the PX5 RTOS. Contrariwise, for someone developing a new MCU application using the PX5 RTOS, they have a relatively easy migration path to Embedded Linux. Another thought that just popped into my mind is that it now becomes easier to create applications that scale from small embedded RTOS-based systems to large Embedded Linux-based applications.
Even though I’m a hardware designer by trade, and have only passing acquaintance with the RTOS domain, I think PX5 RTOS is poised to take the RTOS world by storm. But it’s not all about me—it should be, but it’s not—so what do you think about the introduction of the PX5 RTOS?