Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Controls/MCUs

Comparing MCU real-time operating systems

Posted: 20 Dec 2013 ?? ?Print Version ?Bookmark and Share

Keywords:microprocessor? MPU? Linux? Real-time operating systems? OSIX?

A number of larger microprocessor (MPU) designs are built with embedded Linux. Real-time operating systems (RTOSes) are used only in cases where hard real-time performance is required. Regardless of the MPU operating systemeither embedded Linux or an MPU RTOSall use POSIX as the standard for application programming interface (API) calls. Larger operating systems such as Windows and desktop Linux also support these same API calls.

Microcontrollers (MCUs) have reached the point where most are capable of running an operating system, but none can run Linux, Linux variants, or Windows due to the resources required. The developers of small MPU and MCU systems have no choice but to run bare metal or run an RTOS because they can't run Linux. This article discusses the various options I use for MCU RTOS selection and the criteria by which this selection might be made.

The first choice to be made is whether the application needs a full RTOS or just the kernel component. A kernel is not an RTOS, but this can be a confusing issue because of the inappropriate naming chosen for some popular kernels, 'freeRTOS' for example.

An RTOS includes the kernel component, which provides scheduling, communication and synchronisation, timers, and interrupt handling. In addition, the RTOS provides an I/O mechanism, which presumably offers uniform access to devices, software stacks for a broad set of connectivity options, file systems, display options, off the shelf examples, documentation, and tools for debugging applications running on the RTOS. Table 1 shows how some of the popular RTOSes rate in terms of virtual memory support.

Table 1: RTOS kernel support.

From this table we can see that the MCU OS versions will run on an MPU but do not support virtual memory. All MCU OS variants support memory protection units and may use the MMU for protection on larger processors.

One of the big issues for development in larger companies is the ability to preserve your investment in applications software. This is done with platform-based development or lean product development, with POSIX as the single standard common API for all larger operating systems. With the rise of embedded Linux, and all MPU RTOSs with virtual memory (VM) supporting this standard, this means that POSIX is the API or platform of choice, making it easier to preserve investment in applications software. It provides software reuse, risk reduction, and great flexibility and portability, and allows non-embedded engineers to easily program MCUs,.

For MCU and small MPU operating system offerings, POSIX APIs can extend this software and knowledge reuse into the MCU, MPU, and FPGA area. This approach has been successfully used by some, but more often than not this is a marketing response. Actual functionality that is operational as a layer resting on top of another kernel is often incomplete and defective. More details are provided in the tables I have included the end of this article. The tables compares the various RTOS offerings by some of the criteria discussed here: modularity, time to market, platform type, I/O limitations, Internet Protocol support, USB support, memory size required, and security, among others.

Modularity is key in environments with limited resources. To be able to easily include or exclude modules is important to control size. Along with this comes a modular boot sequence so that the start-up sequencing can be controlled and the developer has a means to provide "instant on" capabilities even if there is still initialisation happening in the background.

Another significant issue is time to market. By purchasing components, the risk can be reduced and the time to market significantly reduced. Sometimes free components are available but often 'free' is not really free. Integration and testing time is 50% of a typical software project, so integrating disparate components can be expensive even if individual components are free. For this reason, it is best to get off the shelf components or components that can be very easily adapted. Not only today's components should be considered, but be sure there is a roadmap going forward so that you can evolve your product without risk of expensive development.

Another aspect of application development is platform selection and it too is tied to time to market. By choosing a standard API like POSIX there is a wealth of benefits that can substantially reduce time to market as well as minimise total cost of ownership for ongoing development efforts. POSIX increases quality because the extensive set of tests can be used and because they were written by a diverse set of people, and not biased by an individual developer.

Limitations to the I/O models are common. Ideally a unified POSIX I/O model is best because it offers greater portability and a univeral means to do I/O. When I/O models are trying to follow a standard but are not unified, problems occur and unexpected behaviour results, which leads to development delays and latent defects. This is one of the issues with POSIX layers.

Given that you should purchase components to reduce time-to-market and that standards-based offerings are desirable, making sure that the environment you choose has a proven set of protcols for Internet connectivity is key. The trend today is towards the Internet of Things (IoT) or Machine to Machine (M2M) communication. To make sure that you can address product requirements not only now but in the future in this area, and be sure that the basic and advanced Internet protocols are off the shelf.

The most common protocol for microcontrollers over the past few years has been USB. Your device may not need it today but it is very possible that it will be a future requirement.

1???2?Next Page?Last Page

Article Comments - Comparing MCU real-time operating sy...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top