Picking the right RTOS for your embedded and IoT designs - Embedded.com

Picking the right RTOS for your embedded and IoT designs

This week's Tech Focus newsletter highlights two important aspects of embedded systems design in the age of ubiquitous Internet of Things connectivity.

First, much has changed in terms of the numbers of devices, their relation to one another, and the number of elements that must be coordinated. Second, at the root of the job is finding right mix of system capabilities to take on a variety of multitasking and multithreading operations and do so in a real-time and deterministic manner.

This challenge is further complicated by the diversity of systems in which this must be done. At one extreme are mobile and consumer IoT apps in which a complex multicore subsystem must manage not only human interface and network operations but also coordinate with a variety of loosely coupled microcontrollers operating internally. At the other extreme are machine-to-machine and wireless sensor network designs, where the challenge is all about monitoring and gathering sensor data, processing it, and either making local real-time control decisions, or, if the system parameters allow it, passing it back to a server or gateway processor for evaluation.

At the core of all this stands the embedded real-time operating system. It makes the decisions about responding to interrupts, the priorities of such actions and their scheduling, how to handle memory allocation, and when to send out semaphores to alert various elements as to some action.

The challenge for the embedded systems developer is to take advantage of these RTOS capabilities to achieve his or her design goals. But before that there is the problem of picking the right RTOS for the job, easier said than done in a design environment where there are now many alternatives available.

Not only are there the many embedded and real-time open source Linux OS distributions but also proprietary RTOSes such as Integrity, Nucleus, SMX, ThreadX, VxWorks, LynxOS, u-Velosity, and uC/OS, among many others. To these have been added a variety of newer operating system alternatives that have emerged to deal with the specific requirements of wireless sensors and machine-to-machine networks on the internet of things. In addition to some of those included in this week's Tech Focus Newsletter , some other recent articles on Embedded.com discussing these alternatives include:

Towards an OS for the Internet of Things
Providing OS support for wireless sensor networks
A comparative study on operating systems for WSNs
Towards Unix-like OS abstractions for wireless sensor networks

How do you select from among the many choices? The most direct way is to look at the alternatives available and compare them feature for feature in terms of what your design will need. Some good guides on Embedded.com are at the top of my Editor's Top Pick List.

Using RTOS semaphores
Blocking and non-blocking RTOS APIs
Lower the overhead in RTOS scheduling
Reduce RTOS latency in interrupt-intensive apps
A multitasking kernel in one line of code – almost
Comparing microcontroller real-time operating systems

In addition, two recent articles that will provide further useful guidelines to cut down the many alternatives to a manageable few are: “Selecting an operating system for an embedded application” by Colin Walls and “Consider the source when selecting your RTOS,” by John A. Carbone.

In his article Wells discusses the criteria by which you can decide whether or not you need an embedded OS in your design, and if so, whether it will be a free, open source version, commercial, or a custom designed one. Then he looks at the pros and cons of various features you will need in the OS you have chosen.

“The selection of an embedded OS is a complex process, requiring consideration of multiple factors, both technical and commercial,” he writes. “Also, leveraging experience is essential. All desktop computers are essentially identical. That is why there is a choice of about three operating systems, which are all broadly equivalent. On the other hand, embedded systems are all different, which is why we have such a wide choice of OS products on the market and why this selection process is necessary.”

In his contribution, Carbone drills down a bit deeper, not into specific characteristics of the operating system, but into issues relating to the source code of the operating system you use. He delves into such questions as: Is simply having the source code sufficient? Are there qualitative elements or attributes of source code, beyond its simple existence, that make it more or less valuable?

“RTOS source code is valuable,” he writes, “and developers cite it as the single most important criteria in the selection of an RTOS. But all source code is not of equal benefit to a user. If the source code is essential, it makes sense that it’s expected to provide benefits.”

What criteria do you use in your choice of operating systems for your designs? A strict feature-by-feature comparison against your system requirements? Or do you look at broader issues first? How has your decision making changed in this new, much more connected environment?

Embedded.com Site Editor Bernard Cole is also editor of the twice-a-week Embedded.com newsletters as well as a partner in the TechRite Associates editorial services consultancy. He welcomes your feedback. Send an email to , or call 928-525-9087.

See more articles and column like this one on Embedded.com.Sign up for s ubscriptions and newsletters . Copyright © 2014 UBM–All rights reserved.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.