Designers Have Expanding OS Choices for MCU-Based Systems

By Maury Wright

Contributed By Electronic Products


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.

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.

About this author

Maury Wright

Maury Wright is an electronics engineer turned technology journalist and industry consultant with broad experience in technology areas ranging from microprocessors to digital media to wireless to power management. Wright worked at EDN Magazine for 22 years, serving as editor-in-chief and editorial director for five years. Wright also served as editor of EE Times' Digital Home and Power Management websites.

Currently, Wright is working as a consultant for a number of technology companies and writing under his own byline for the Intel Embedded Community website and for LEDs Magazine.

Wright has won numerous industry awards, including ASBPE national wards for EDN's 50th Anniversary Issue and a similar award for the EDN Prying Eyes department. Wright is an expert in the area of digital media and the connected home, having covered the wired and wireless service-provider and in-home networks extensively. This expertise extends from processors and ASSPs all the way up through the end application. Wright graduated from Auburn University in 1978 with a BSEE and a curriculum emphasis on digital design and development with early microprocessors.

About this publisher

Electronic Products

Electronic Products magazine and ElectronicProducts.com serves engineers and engineering managers responsible for designing electronic equipment and systems.