embedded software boot camp

Are all RTOSes the Same?

Wednesday, January 23rd, 2008 by Michael Barr

Having just, coincidentally, returned from teaching a two-day hands-on RTOS course in Florida, I was greeted this morning by the following message from an RTOS company president in my inbox:

Recently, I have had a statement by you thrown at me. The statement essentially said that all RTOSes are the same, or something to that effect. Obviously, you and I both know that there are differences, some large and some small. The problem is that people listen to what you say and I think they may have misunderstood you. So what were you trying to say? I’d like to know so I can rebut them with your own words when they quote you.

This reply is probably best handled publicly. Having used several commercially successful RTOSes (including both of the current top two according to Embedded Systems Design); written one of my own (ADEOS) for a book; taught OS theory as adjunct faculty at the University of Maryland; and also written and spoken of non-preemptive RTOS alternatives in several venues, I am quite opinionated on the subject. A few years back I was even interviewed about RTOSes on a PBS television show called American Business Review.

Here are a few of my past RTOS articles, which may provide additional background for this post:

I believe the opening paragraph of that last article concisely sums up an opinion I’ve often expressed–and which may have been the basis of the remark aimed at the RTOS vendor who e-mailed.

Every commercial RTOS employs a priority-based preemptive scheduler. This despite the fact that real-time systems vary in their requirements and real-time scheduling doesn’t have to be so uniform. Multitasking and meeting deadlines is certainly not a one-size-fits-all problem.

But my e-mail correspondent is correct that there are differences large and small. Here are some of the most obvious differences between the various commercial RTOSes:

  1. At the API level, each RTOS is unique. Though every RTOS has functions for creating a new task, acquiring a mutex, and posting to a message queue, the specific function names and parameter lists differ “by brand”. Individual programmers may find one RTOS’ API more comfortable or logical than another.
  2. To support true real-time scheduling via RMA, each RTOS must provide the following:

    1. A guarantee that the highest-priority task ready to use the CPU is the one actually running at all times
    2. A bounded worst-case context switch time
    3. A bounded worst-case interrupt latency
    4. A mechanism to automatically prevent unbounded priority inversion during mutex contention

    An RTOS that doesn’t do one of these things is, obviously, different from the others–but most do. But the specifics may vary. In particular, the precise timing of those worst-case times may differ from one RTOS to the next on one processor to the next. In addition, the details of the chosen priority inversion workaround will make a difference in the RMA calculation mathematics.

  3. Some RTOSes can use the MMU and others can’t

Hopefully, this clarifies both that I think commercial RTOSes are somewhat commodity products and that there are, nonetheless, obvious differences.

Tags: ,

4 Responses to “Are all RTOSes the Same?”

  1. Michael Barr says:

    I have just been shown a very recent article from Rich Nass that quotes me on the subject. I was interviewed for this months ago, and thus not aware of the The quote reads “Fundamentally, every RTOS is the same as every RTOS,” Barr said. “What you need is a way to divide your problem into tasks and have sufficient computing power. Then you want to have a priority-based preemptive kernel. And they’re all the same, whether you get your OS out of a book or with free source code included, or you get something else free. Unless you need that driver availability, or some special advanced features, you really aren’t willing to pay for it.”Perhaps this is the reason for the e-mail this week from an RTOS vendor. I can certainly see how the wording there might put a few folks on the defensive!

  2. speedplane says:

    What about middle-ware? Technically middleware is not a part of the OS, but having a good set of drivers and libraries can vastly speed up development time on an OS.There are major differences in middleware support for different OSs.

  3. speedplane says:

    One more thing…. tools support. An RTOS that is supported by crappy tools is pretty hard to use. Having stop-mode, run-mode, and trace debugging while not technically features of the OS, are paramount to the success of using one.

  4. Miro Samek says:

    The very existence of companies like Mapusoft proves that RTOSs are indeed mostly equivalent technically. Mapusoft bases their entire business model on porting from one RTOS to another.I’m really amazed that the marketplace sustains so many RTOS vendors. In every embedded show I go, at least two-thirds of the vendors offer RTOSs. How many of them do we need?

Leave a Reply