Designers Have Expanding OS Choices for MCU-Based Systems

Embedded design teams working with microprocessors almost always rely on an operating system (OS) of some type to simplify the software-development process and add system reliability. Designers working with microcontrollers (MCUs) haven’t always had the luxury of an OS to manage multiple tasks given the limited memory integrated in MCUs and performance limitations. Frankly, many MCU-based designs simply don’t need an OS because the application can be singularly focused without the multitude of tasks that often pervade microprocessor-based systems. But times are changing, with faster 32-bit MCUs and megabytes of integrated memory. Let’s examine why you may want to use an OS in your next design and consider evolving OS options for some popular MCUs.

An OS can greatly simplify the software-development process anytime an application requires multiple tasks. Moreover, an OS often comes with an interrupt handling structure in place. A real-time OS (RTOS) even guarantees a minimal latency that a system experiences in reacting to internal or external interrupts.

MCUs don’t include a memory-management unit (MMU). So an OS for an MCU doesn’t need to handle virtual to physical address translations. Some MCUs do have provisions for isolating and protecting areas of memory that are reserved for a specific task or algorithm. For example, some members of the Renesas RX MCU family have what the company calls a memory protection unit (MPU). The MPU can protect regions of memory much like MMUs can. OSs can take advantage of such hardware features to handle memory partitioning and protection.

MCU complexity spurs OS trend

The growing complexity and greater level of integration found in new-32-bit MCUs also is driving the OS trend. MCUs in the 32-bit class commonly ship with a megabyte or more of memory and easily accommodate small OSs. Moreover MCUs increasingly support graphics-oriented displays, and robust user interfaces such as capacitive-touch-based systems. Design teams will find it much simpler to implement and support the multiple tasks that implement the user interface with the help of an OS.

MCU vendors all supply a suite of software-development tools for use with their products. The suite may include an integrated development environment, and certainly tools such as compilers and debuggers. But third parties may be the best source of OSs for embedded teams.

Micrium supports a number of MCU families with its µC/OS-III RTOS including those based on ARM 7, 9, and Cortex-MX cores. Vendors of ARM-based MCUs include STMicroelectronics, NXP, and Texas Instruments (TI) among others. The Micrium RTOS also supports the Renesas RX, H8, SH, M16C, and M32C families, and PowerPC and Coldfire MCUs from Freescale.

The µC/OS-III RTOS support for multiple tasks is only gated by available memory. The RTOS supports an unlimited number of priority levels for tasks although Micrium recommends that 32 to 256 levels should be sufficient for most applications. Also, the RTOS employs preemptive multitasking to run the most important task that is ready while it time slices tasks that have the same priority level. Design teams can also scale the size of the RTOS by only including the features needed for their application.

Linux-like MCU operating systems

There are several RTOS flavors available for MCUs that are Linux like or Linux compatible and that rely on an open-source model. Linux by definition requires an MMU so it can’t be directly ported to an MCU. RoweBots, for example, has its Unison RTOS that is Linux and POSIX compatible. The RTOS supports essentially the same list of processors as does the Micrium offering.

FreeRTOS is another cross-platform, open-source project that supports 26 MCU architectures. For design teams that don’t want to build their own I/O system on top of the free kernel, HighIntegrity Systems offers commercial versions of FreeRTOS called Open RTOS and SafeRTOS – the latter for security-centric applications.

The trend of OS use on MCUs isn’t limited to 32-bit processors. There are RTOS implementations that run on 8- and 16-bit models as well. The kernel utilized in many OSs is surprisingly small. For example, the kernel used in the RoweBots Unison implementation can require as little as 1 kbytes of RAM and 6 kbytes of Flash. It’s generally I/O support and other features that drive up the memory footprint.

In fact RoweBots offers a product that it calls the DSPnano RTOS that it targets at 8- and 16-bit MCUs and digital signal controllers (DSCs). The RTOS relies on a single process while supporting multiple threads. But design teams can implement the RTOS with support for a variety of I/O including TCP/IP and even a file system as memory allows. Supported MCUs include the Renesas M16C and R8C and a variety of PIC and dsPIC devices from Microchip.

Of course, the TI MSP430 family is among the most popular 16-bit MCU families on the market today. Design teams using that architecture have several OS choices, including the previously mentioned FreeRTOS that will also run on 16-bit hosts.

The Segger embOS RTOS also supports the MSP430 family as well as a long list of devices from other vendors including Microchip, Renesas, Freescale, STMicroelectronics, Zilog, and others. The RTOS relies on preemptive scheduling, supports 255 priority levels, and unlimited tasks as memory can accommodate.

There are a couple of other RTOS choices that embedded teams might consider, especially when working with 16-bit MCUs. CMX Systems offers its CMX-TINY+ RTOS that can fit in as little as 512 bytes of RAM. Micrium has a smaller RTOS called µC/OS-II that is limited to 250 tasks.