Question of the Week: When does it make sense to use an RTOS or operating system?

Wednesday, March 31st, 2010 by Robert Cravotta

[Editor's Note: This was originally posted on the Embedded Master

I posted last week’s question about dynamic memory allocation here and in a group discussion at LinkedIn. There were many thoughtful comments at both locations, with the majority of responses made in the LinkedIn discussion. I’m trying to figure out a way to enable you to see the responses from both groups in one place. If you have any ideas, please let me know.

This week’s question expands on one of the underlying premises behind last week’s question – that the size of the system, real time requirements, and reliability affect your answer to the question. For this week, under what conditions do you use or avoid using an RTOS or operating system in your embedded designs?

Depending on where you draw the line on what constitutes a system, I have built embedded systems with none, one, or even multiple operating systems. In general, the smaller systems relied on an infinite loop construct or a manually built scheduler; these systems often had hard real-time and high reliability requirements. In some of the systems, we used an RTOS most significantly to leverage the communication stack support it offered when the system was in a near-real time operating mode. When the system switched to a hard real-time mode, the control software no longer made any RTOS calls.

The only context we used a full blown operating system was for ground and test support equipment that provided a near-real time, data rich user interface for the human operator and for non-real time post-operational analysis. In these cases, the operating system reduced the complexity for driving application-level processing such as receiving inputs from the operator, displaying messages and data to the operator, and communicating with other remotely located components of the systems.

Based on these projects, the team’s decision to use or avoid using an RTOS correlated strongly with the real time and reliability constraints of the system as well as how intimately the software was coupled to controlling and monitoring the hardware components.

Contemporary processors and RTOS offer coupled resources, such as memory protection units and padded cell virtualization support, which may blur the criteria for when it is appropriate to use or avoid using an RTOS. I’m trying to tease out under what conditions, such as resource limits, reliability requirements, project scheduling, and real-time operating constraints that the trade-offs favor adopting or dropping RTOS support. So when answering this question, please try to identify the key criteria for your application space that pushed your decision one way or the other.

8 Responses to “Question of the Week: When does it make sense to use an RTOS or operating system?”

  1. P.N. @LI says:

    Buying an RTOS gives a big advantage as follows: thousands of design decisions have already been made (for better or worse) and the project does not have to be slowed down to consider each of those decisions. In this day and age, all but the most cost or power constrained projects can afford the runtime overhead associated with at least a small fast kernel.

  2. P.B. @LI says:

    It makes sense to use an RTOS when you require the facilities of an RTOS – file system, protocol stack, scheduler, debug tools, …. If you are building a system that doesn’t require input or output, and doesn’t execute much code, you probably don’t need an RTOS. If you have several developers, and industry standard I/O ports, you probably need an rtos unless you have a very simple application, or you have enough time and money to write the entire product yourself and exhaustively test all the code.

    But an RTOS gives you future growth, to add capabilities that your customers demand, by just incorporating additional parts of the RTOS : Ethernet port, USB, wireless, web access, touch screen gui, …. an RTOS lets you buy these commodity items and lets you focus on your value add, where your product really differentiates itself from other products. And the RTOS comes tested, so you only have to test and debug your application, not the entire system.

    And a RTOS allows easy migration to a new processor or hardware, without your software development team having to rewrite everything for the new hardware.

    I would hate to have to write my own file system, disk drive code when this is a commodity item, and would work with all the disk drives out there. If manufacturing changes hardware due to cost or availability, your software needs to be able to respond without a major software rewrite if you want to be cost competitive in today’s environment.

  3. L.X. @LI says:

    Most of time I will consider using an RTOS in the application as it usually offers a unified hardware abstraction layer and bunch of inter-process(task) communication APIs. Those offerings make applicaiton code more portable and more structure. On the other hand, if it is a very hard realtime application which means any time overhead are not acceptable I will not consider using RTOS. Finally I heard if the product needs to pass SIL(safety integrity level) certification, RTOS is probably not allowed.

  4. D.A. @LI says:

    It might be useful to make a distinction between a real-time “operating system” and a multi-tasking kernel. As Paul pointed out, an RTOS has lots of facilities like file systems, network stacks and so on that can be useful if you need them. But at the heart of any RTOS is a multi-tasking kernel whose primary job is to schedule tasks in response to events.

    When I was teaching real-time programming seminars a few years back I told my students that if you have two or more asynchronous interrupts in a system, you probably should use a multi-tasking kernel. And remember that the timer tick is one of those interrupts.

  5. B.Z. @LI says:

    When a design indicates multiple asynchronous threads or processes rather than simpler synchronous operation, an RTOS kernel is recommended. Even with fairly complex operations, a synchronous system can be easily handled with a coroutine scheduler and can be 100% validated. But when you have an asynchronous situation, a COTS RTOS makes things a lot easier.

    That’s my dividing line — asynchronous versus synchronous operation.

  6. D. @EM says:

    I’m working in deep-deep embedded areas (automotive and industrial automation) and would never consider not using an RTOS.

    There is a class of not-so-well-known RTOSses that have no file-system, multi-tasking in the usual way etc. but is still delivering a reliable task scheduling service and a minimum of HW abstraction.
    In the past I’ve even written such simple RTOSses on my own to ease the subsequent development.

    RTOS ? Never again without !

  7. E.W. @LI says:

    I think previous posts have covered the technical aspects :-)
    If the production volumes are low and you use a lot of the device drivers and protocols then it’ll tend to be cheaper to use an RTOS.
    If the production volumes are high then even though the overheads of an RTOS are low, they can be significant and a roll-your-own can be cheaper, especially if you’re not using lots of the device drivers.
    If time-to-market is critical ( for you to get there before your competitors), then an RTOS can give you a head start.
    As L. X. says, if you want to demonstrate that your system has been developed to a process that conforms to a particular standard, your choices of RTOS are limited. There are a few RTOSs that are designed to be used in military/aerospace/nuclear/automotive applications, but it’s more than a rubber-stamping exercise and may require working closely with the RTOS vendor.

  8. P.N. @LI says:

    Re: If time-to-market is critical


Leave a Reply