RTOS: Basic Selection Guide

It’s been more than hundred year’s efforts and dedication towards embedded system brought it to present day shape. An embedded computing system or embedded system includes a digital electronic system embedded in a larger system and it is an application specific. These systems have become an integral part of various commercial products like mobile phones, watches, flight controllers etc. The developer needs to select a right RTOS based on these applications. There is a strong and compatible relationship between the system hardware and the software, primarily the operating system to ensure hard real time deadlines.

With embedded markets becoming increasingly competitive, the value of RTOS technology has shifted. Developers are confronted by greater design complexities and limited windows of opportunity. Trends indicate that developers no longer have the time to individually research available processors, tools and operating systems; write, compile and debug code; integrate software and hardware and then test the final solution. And, yet, new vertical market application products are emerging weekly, placing increasing demands on embedded developers.

An RTOS is usually chosen based on its performance or one’s comfort and familiarity with the product. However, such a selection criteria is insufficient. To

make matter worse, there is a wide variety of RTOS ranging from commercial RTOS, open-source RTOS to internally developed RTOS to choose from. Therefore, it is incumbent upon the programmers to exercise extra caution in the selection process. The selection criteria of RTOS can be broadly classified into two main areas; technical features of RTOS and commercial aspect of the implementation.


Embedded systems must be reliable. Depending on the application, the system might need to operate for long periods without human intervention. Different degrees of reliability may be required. Although different degrees of reliability might be acceptable, in general, a reliable system is one that is available and does not fail.

For example, a digital solar-powered calculator might reset itself if it does not get enough light, yet the calculator might still be considered acceptable. On the other hand, a telecom switch cannot reset during operation without incurring high associated costs for down time.


Size or memory footprint is an important consideration. Most RTOS are scalable in which only the code required is included in the final memory footprint. Looking for granular scalability in an RTOS is a worthwhile endeavor, as it minimizes memory usage.


Because many embedded systems are also real-time systems, meeting time requirements is key to ensuring proper operation. The RTOS used in this case needs to be predictable to a certain degree. The term deterministic describes RTOS with predictable behavior, in which the completion of operating system calls occurs within known timeframes. Developers can write simple benchmark programs to validate the determinism of an RTOS. The result is based on timed responses to specific RTOS calls. In a good deterministic RTOS, the variance of the response times for each type of system call is very small.


Often, a current application may outgrow the hardware it was originally designed for as the requirements of the product increases. An RTOS with such a capability can therefore be ported between processor architectures and between specific target systems.

Run-time facilities

Run-time facilities refer to the services of the kernel (i.e. intertask  ommunication, task synchronization, interrupts and events handling, etc). Different application systems have different sets of requirements. Comparison of RTOSs is frequently between the kernel-level facilities they provided.

Run-time performance

Run-time performance of an RTOS is generally governed by the interrupt latency, context switching time and few other metric of kernel performance. This consideration is useful if the performance assessment of the application on a given RTOS is to prototype its performance-critical aspects on standard hardware.

Development tools

A sufficient set of development tools including debugger; compiler and performance profiler might help in shortening the development and debugging time, and improve the reliability of the coding. Commercial RTOSs usually have a

complete set of tools for analyzing and optimizing the RTOSs’ behavior whereas Open-Source RTOSs will not have.


Application design constraints and cost constraints help determine how compact an embedded system can be. For example, a cell phone clearly must be small, portable, and low cost. These design requirements limit system memory, which in turn limits the size of the application and operating system. In such embedded systems, where hardware real estate is limited due to size and costs, the RTOS clearly must be small and efficient. In these cases, the RTOS memory footprint can be an important factor. To meet total system requirements, designers must understand both the static and dynamic memory consumption of the RTOS and the application that will run on it.

Commercial Considerations


Costs are a major consideration in selection of RTOS. There are currently more than 80 RTOS vendors. Some of the RTOS packages are complete operating systems including not only the real-time kernel but also an input/output

manager, windowing systems, a file system, networking, language interface libraries, debuggers, and cross platform compilers. And the cost of an RTOS ranges from US$70 to over US$30,000. The RTOS vendor may also require

royalties on a per-target-system basis, which may varies between USS5 to more than US$250 per unit. In addition, there will be maintenance required and that can easily cost between US$100 to US$5,000 per year.


Because RTOS can be used in a wide variety of embedded systems, they must be able to scale up or down to meet application-specific requirements. Depending on how much functionality is required, an RTOS should be capable of adding or deleting modular components, including file systems and protocol stacks.

If an RTOS does not scale up well, development teams might have to buy or build the missing pieces. Suppose that a development team wants to use an RTOS for the design of a cellular phone project and a base station project. If an RTOS scales well, the same RTOS can be used in both projects, instead of two different RTOS, which saves considerable time and money.

Related posts:

About author

This article was written by admin

Admin has over twenty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles. Working presently as Development Manager in India. A firm Believer in Knowledge grows when it shared.


Comments (2)
  1. Rodrigo Neighbours says - Posted: October 25, 2012

    Thank you, I’ve recently been searching for info about this topic for a long time and yours is the best I’ve came upon so far. However, what about the conclusion? Are you positive concerning the source?

  2. Jim R says - Posted: August 8, 2013

    Is this the whole article?

Leave your comment

Your email address will not be published. Required fields are marked *