Inside Microsoft’s latest OS: Azure RTOS

Microsoft’s collection of operating systems continues to grow. We’re all aware of Windows and its moves into Linux with WSL (Windows Subsystem for Linux) and in Azure through the SONiC (Software for Open Networking in the Cloud) networking platform. The secure IoT Azure Sphere is also increasingly familiar. Now there’s another Microsoft OS out there, one that’s a lot more specialized but starting to get more attention from silicon vendors.

Microsoft’s 2019 acquisition of Express Logic brought its ThreadX real-time operating system into the Azure fold. Now branded as Azure RTOS, it’s an industrial-grade, real-time operating system for devices that fit somewhere between Arduino and Raspberry Pi, needing more than firmware but less than a full Azure Sphere-like Linux. The OS adds to Microsoft’s edge compute capabilities, already running on more than two billion devices.

Real time with Azure RTOS

At the heart of Azure RTOS is the ThreadX picokernel. It’s designed to scale across a range of hardware, with a customizable deployment image that only bundles the services needed by your code. Those services are implemented as a C library, simplifying building and delivering runtime code. The kernel is distributed as C source code, so it’s possible (though not recommended) to modify it to deal with specific hardware or application requirements.

Services run side by side as threads—they don’t layer—allowing ThreadX to be optimized for speed and for switching between services. Performance is essential, as real-time operating systems need to respond quickly to event-driven inputs as they often operate in safety-critical roles.

The kernel is a real-time kernel, so there’s no need to build applications that run from a basic control loop. Instead the OS manages task switching between threads, using a priority-based scheduler for pre-emptive multitasking. Key events can be given a high priority, allowing them to respond quickly, in the time needed for Azure RTOS to make a context switch.

Code is developed on traditional PCs in familiar development environments before being compiled, linked to the ThreadX libraries, and then downloaded to a device. Azure RTOS is designed for embedded hardware, so it’s delivered to device ROM, with debugging via hardware connections to the device silicon. Most industrial IoT hardware is programmed before being deployed, and any updates are delivered by reprogramming the device. If you’re handling this remotely, you’re likely to need a second set of firmware for updating the main system.

Extending the ThreadX kernel

Additional features come as libraries, ready to build into your applications and to extend the core ThreadX kernel. These include file system support, with FileX, a FAT (File allocation table)-based file system for RAM and various flash memory formats. The NetX library is a TCP/IP stack, adding network connectivity for devices that need to send data to services such as Azure IoT. It’s for IPv4 connections; a newer, alternative networking stack adds support for IPv6. If you’re planning on deploying many thousands of devices, you’re better off using this second stack, as IPv4 addresses are in short supply and are expensive at scale.

Unlike many RTOS implementations, Azure RTOS has a GUI option for devices that need to interact with users. Like the rest of the platform, it’s small and fast, with a library-based approach. You design the UI on a PC using the Azure RTOS GUIX Studio, which takes your design and generates the appropriate C code, which is then compiled and linked with the Guix library. With Azure RTOS certified for medical and automotive use, a UI is an important feature. If you’re planning on adding a GUI to your applications, you’re likely to need a higher-end microcontroller, as smaller devices rarely support displays.

Working with microcontrollers

One advantage of ThreadX’s architecture is that it’s very easy to port to new silicon architectures. That’s been an important part in Microsoft’s new distribution policy for Azure RTOS, which changes how it’s being delivered to microcontrollers. In the past it was a third-party platform, maintained and ported by Express Logic for their direct customers. Now it’s delivered as a first-class citizen, with hardware support from Qualcomm, Microchip, NXP, and other vendors.

I spoke to NXP recently to understand how they integrate Azure RTOS with their hardware. Most NXP microcontrollers currently use Amazon’s FreeRTOS or the Linaro-based Zephyr OS. Azure RTOS will be a third option for NXP devices, so developers will be able to choose a platform that meets their requirements. NXP’s SDKs will add hardware-specific features, with everything coming from one vendor rather than having to source hardware from one manufacturer and software and development tools from another. It’s a much simpler way. Instead of using Microsoft developer tools, you write your ThreadX code in NXP’s MCUXpresso development environment.

One advantage of this approach is that NXP will provide sample code for specific devices, showing how to build both local and network-connected applications, not only for Azure, but also for AWS or Google Cloud. With Microsoft handling industry safety certification for Azure RTOS, making it suitable for both vehicle and rail applications, as well as medical and aviation use, it’s an opportunity for NXP to ship a precertified RTOS with its microcontrollers, reducing its costs. Similarly, with Azure RTOS’s modular design, more complex devices can ship with its graphic library or its Azure IoT integration features.

NXP’s range of “crossover” microcontrollers looks to be an ideal platform for Azure RTOS. It uses low-power ARM Cortex-M cores, but instead of running them at 400MHz, they’re on silicon that can be clocked at 1GHz. The resulting mix of hardware and software should give high performance at a relatively low cost, without needing a large power budget.

Azure’s IoT OS portfolio

Hardware vendor support for Azure RTOS is necessary for it to become a success. The original model from Express Logic made sense for a smaller-scale organization; now Microsoft is aiming for mass distribution of Azure RTOS, and that means stepping away from custom builds. Working with vendors such as NXP to deliver support for their main product lines makes a lot of sense, as they offer both prototyping boards and production systems, reducing the risk associated with application and hardware development.

With Azure RTOS, Microsoft has a portfolio of IoT operating systems that scale from the smallest devices to edge controllers. Azure RTOS starts small and scales up to midrange devices, and then Azure Sphere comes in and adds a secure layer (you can use Azure Sphere as a gateway to protect a fleet of Azure RTOS devices). For more complex hardware that doesn’t need to support real-time events, the Windows 10 IoT family is ready for devices like the Raspberry Pi and other ARM and Intel single-board computers.