Every embedded application needs an RTOS right? Certainly that's the impression one gets reading the trade press. There's no doubt that a decent OS brings much value to developers and the system. Tasking can greatly simply designs where multiple activities have to run concurrently. And even more importantly, robust and reentrant-safe communications resources like queues and mailboxes can help eliminate the problem-plagued global variables that infest so much firmware.
But an RTOS brings costs and perils. Preemptive multitasking can make systems inherently non-deterministic; they may run great for years but one odd combination of inputs and loading causes a task to run late. The system crashes and a camera team from 60 Minutes arrives at your door.
Even the smallest RTOSes consume some system resources. Though a handful of OS products are truly tiny, it sure seems that many commercial offerings have a bad case of code bloat. Features that customers demand (or that marketing tosses in to differentiate the product) have grown some products from micro-kernels to megabyte monsters.
Safety-critical applications may need a certifiable OS. That's not one meant for an asylum, but one that can, for tolerable costs, be shown to conform to a standard like DO-178B. The costs are staggering; the certification process for one app I know of generated half a page of documentation per line of code. Though a couple of certifiable RTOSes do exist, they are few indeed. In some cases it might make sense to skip the operating system to minimize these expenses.
In many cases a simple loop or interrupt-drive structure, or perhaps just a state machine design, yields a cleaner, simpler architecture that's easier to build, test and maintain.
My sense of the history of RTOS usage looks something like this:
1970s: Most of the RTOSes used were home-built
1980s: Wind River, Ready Systems, and others produced viable commercial
operating systems, marketed them well, and created a devoted following.
1990s: An explosion of specialty RTOSes emerged from small companies. The big vendors lost interest in the 8, and sometimes even the 16 bit market.
In the 2000s things are changing. While many, many of us use an operating system in our firmware, my email in-box is daily flooded with messages from engineers indicating a growing dissatisfaction with many commercial offerings. Users are flocking to “free” alternatives, like Linux and eCos, repelled by high licensing fees and frustrated by poor support.
Me, I like using an RTOS when there's a tangible benefit, though in a lot of systems an operating system is neither possible nor appropriate. But the grumbling of our community about many commercial offerings is getting louder. Engineers are voting their pocketbooks, flocking to the free or smaller alternatives (Micrium, CMX, Keil and many others) that may offer fewer features but which are easier to tame. Some of these are even DO-178B certifiable.
What do you think? Are you using an RTOS? Are you happy with the products being offered today? If you could use any product, what would it be?
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at . His website is .
I do like operating systems and I'm using ucos-ii for small microcontrollers (8 and 16 Bit) and VxWorks/BSD/Linux for the 32 bit stuff. Did you ever compare the price list of Wind River and Micrium? That's one of the few cases where Goliath wins over David in terms of “what you pay for is what you get”.
Since I do prefer to work with (RT)OSs than to write my own, or to work totally without any OS, I see things slightly differently from you. What I would demand is some more research on RTOSs, since there are IMHO no fundamental news for many years.
– Robert Berger
I am an italian EE.In my spare time I am developing a small embedded project from the chips and pcb layout upto the firmware and PC frontend.
Your latest column about RTOS gave me the opportunity to share with you the lesson I learned in my project.This project deals with an home automation system where the price of each device have to be less than $15.For this reason I choosed a 8 bit micro (a ST7 who is an enhancement of the well known HC05) with 384 bytes of RAM (128 of them are reserved to the stack) and 8K of Flash for code.
If I were constrained by time-to-market, an RTOS would be the right choice but I would not have learned how to manage the problems that a RTOS solves for its customer.My firmware architecture is based on a cooperative multitasking.There are two kinds of tasks: the interrupt handlers and the co-routines.
This may suffice to you to realize that my ASM code (co-routines are easier to code in ASM than C) have to manage reentrancy, interrupt priority inversion, latency, timers and the other shared resources.
I know, ASM was the old-way of coding… But the code is more clean even if my firmware uses interrupt nesting (i.e. enabling interrupts within an interrupt handler) to have the lowest latency.
The co-routines are the most valuable thing of my architecture.
In the old days, they were common because they were easy to code: split the stack between the tasks and handle the stack pointer during context-switching, that's all!
Tasks scheduling becomes as easy as a call to a function (a software interrupt if you want to save the bytes of the function address) that saves the current stack pointer, loads the one of the next task and … returns!What RTOS can give you context switch that takes 21 clock cycles? (Yes, I am one of the few that still counts clock cycles…)
Playing with the Stack Pointer it is easy to break something: one strong reason to use C, but gives you a better watchdog implementation.In the only place where I refresh it (a co-routine), I can be sure that all co-routines are not hung (otherwise this code would not be called).
Even if a RTOS is a bloated, costier solution for my project, I do not think it is useless.
I could afford to invest time to reinvent the wheel because my project is an hobbystic one.If it were a production one, it would be cheaper to pay a known amount of money to have the dirty work done by some more experienced guys…
– Enrico FAGGIOLI
For the most part, most projects use that while(1), or the for(;;) loop. The dividing line seems to be in the processor complexity. Most managers, almost withouth 2nd thought will start looking into an RTOS if the processor sports something like an MMU.
I have seen exceptions to this however. On the small side, I have even seen managers opt for an RTOS on a heavily-laden bank-switched 8051!
What is also truly amazing are all the desktop-PC's that double as embedded controllers…usually running something like Windows 2000, or XP professional. If you include this ilk into the domain of RTOS's, then clearly Microsoft has a commanding presence in the embedded world!
– Ken Wada
I am an Electrical engineer from Bangalore, India and I drive teams to design and implement embedded projects. To use or not to use an RTOS is a fundamental problem that I face in every project that I start and manage. While cost is a major factor contributing to this decision, of late my decisions have been influenced by the vast variety of options that we have now for RTOS's – mostly in the open source domain. However, a significant portion of our embedded projects still remain on non-RTOS based platforms. The reason being (a) Cost (b) Complexity of the application (which does not approve use of an RTOS and incur the cost of training engineers on the RTOS and the cost of the RTOS itself) (c) The fact that if we use a non-open source OS we are stuck with the vendors for everything. Reason (c) is of significant importance as I have bad experiences having to wait for weeks for the vendor's team to fix bugs that we reported putting our project off track. In many cases the bugs have been as serious as a Semaphore object allowing access to two tasks at the same time or a corruption of event objects resulting in the locking up of the whole application and the TCP/IP stack that we were running! To add to this, I had a vendor who said that he had fixed one such serious problem noted by us in a newer version and forced us to purchase the entire license again (including the IDE's) rather than giving me an inexpensive upgrade.
With all this, I have become more cautious in choosing propreitary RTOS's for my designs. With open source, atleast you know you have the code with you and can fix an issue your self if the situation arises.
– Ganesh Okade
Commercial RTOSes do offer good features even if they add the cost.
The cost of testing the home grown RTOSes for deploying in critical applications is phenomenol.
Additionally customising the commercial tools adds to the complexity.
If Time to Market adds up to above problems then Commercial RTOSes rule.
But care should be taken in selecting the right Commercial RTOS to avoid the problems like support, reliability etc
– Ravi K
I use embedded linux extensively and after my first product with it I just imagined the vast amount of projects it could help me create in half the time spent if I opted for any other OS on my 32-bit processor.
Of course purists still fight over it being counted as an RTOS but this is a non-issue for most systems running at +100 Mhz. This hardware trend is bound to become the norm given their pricing.
If you know your market well it is certainly a strategic decision to opt for linux. it gives you immense joy as a developer to see your queries being already answered by people eons ago on forums.On the other hand for a manager , its a big relief because his developers are using the same OS on their desktops, learning traits about the OS even when not explicitly working on it.
I am still not designing mission-critical systems so I'd rather agree that a certified RTOS augurs well on such systems atleast for now.
– Gautam Morey
The project that has consumed the last five years of my life sports a scheduler and co-routines, and one day we needed a means for any routine to pre-empt themselves and ensure a second process would execute immediately. Our solution was to tie an Altera CPLD pin to an external CPU interrupt, so whenever necessary, a routine could assert, and viola, crude pre-emptive multitasking. Goes to show how one can get away with an RTOS and even develop a powerful scheduler/co-routine OS with real-time properties through the use of a slave CPLD or FPGA!
– Matthew Staben
We've had success with our new controller, and the bundled software we purchased (Precise MQX + Allegro Web Server + SRI's SNMP).
The biggest concern I have is what our competitor may be concocting. Like us, they use a ColdFire in their controller, and know that the v4 ColdFire has an extra Ethernet port, and a Hardware encryption accelerator.
There is a huge gap between where we are today, and the functional capability of the next controller built using a v4 ColdFire.
NG Controllers would have:
1) Two Ethernet ports – one for use as a local craft port, and the other permanently connected to the customer's (surveillance) network.
2) Built-in Router Capability – the neat thing here is that craft people will now be able to check emails through our controller.
3) Secure communications – 128-bit encryption – this will make them more comfortable
But the biggest feature is going to be the ability for us, as a vendor, to monitor our own equipment once it's deployed.
I'm intriqued by what WindRiver is doing with the Remote Diagnostics DSO:
1) run-time agents that permit surveillance in a firewall friendly mode.
2) automated code updates
Now that OS's are perceived as a commodity, the vendors are trying to create more value in the middleware space.As a developer, how can I ignore that? My competitor's might not – they may use it and get to market sooner.And why would I want to re-invent the wheel, anyway?These things are too complex – my developers need to focus on the application as much as possible.
Sure, there is always the cost vs. make decision, but as you preach “Code is the most expensive thing on the planet!”
– David Essi
In some cases it's pretty clear that you need an RTOS in other cases it's pretty clear that you don't need one. The interesting cases lie in between and that's where it's important, and hard, to make the right choice.
Scalability is a huge factor and that's where traditional, commercial RTOS vendors still have a leg up on both embedded Linux (cool but huge) and semi-free things like uc-OSII (cool but limited).
Once you cross the line from while (1) to multiple threads on a real scheduler you can never go back so you want to think about that choice very carefully.
– Andrew Queisser
I currently use PIC's for safety critical applications. No OS required. UL1998 requirements would make approving the product unworkable with a 3rd party OS.
I've used in previous jobs uC/OS-II on 16HC12 platforms with excellent results. Well documented and low cost.
Pick what fits and can be supported by the processor of choice.
I do miss stack frames in the PIC….
– Walter Greene
I work in a small department where most of our software projects require a quick turn-around. On the past three projects, I have opted for an RTOS, mostly because the $8,000 to $13,000 cost is simply a drop in the bucket for the customers we deliver our products to (they pay our bills). Even a $13,000 RTOS costs only two weeks of one engineers time. So, the way I see it, if the RTOS will save you two weeks of development, why not use one?
Also, RTOSes typically come with a board support package and are ready to use on the hardware.
Finally, another reason I like to use RTOSes is because the middleware (USB stacks, ethernet stacks, etc) is typically designed for an RTOS. So it is usually easier to get your middleware
– Stephen Fenwick
A decade back, we developed GPS, X.25 software using the traditional while loops and interrupts. From then we moved to a variety of RTOses. In all these years, only one issue was the same, define what we want at what time.In my opinion a strong state based machine concept serves almost everything — just my 0.02$
– Girish S
I design,develop and drive teams to build multimedia communication systems. RTOS or No-RTOS – seems we are back to the same old question.
My engineers always seem to get into the mode of no RTOS targetting performance and resource problems. But we tend to ignore or forget the cost of the debugging time spent and most importantly the repurcussion on the maintenance costs when the same engineer or developer is no longer working on the product.
Whether we want it or not, costs ARE driving the embedded industry.
I should agree with Andrew that scalability plays a huge role in taking decision of RTOS or NO-RTOS.Any manger who seeks into reusable design and long term software plans (remember that we **still** do develop the code in C and every line of tested code reused cuts huge costs – I have repeaped the benefits myself many a times).
Not that I advocate an RTOS always.
No RTOS is ok for having in situations where dedication the core is completely dedicated to a single function only and we are sure that scalability does not make any sense.I wouldn't advocate linux as an rtos because linux is more of an embedded RTOS + “app-middleware platform” from my perspective (since it comes bundled with a likes of a TCP/IP network stack and lot of applications added there on).
– Saravanan T S
Here's the future — our product, SynthOS. It generates a small, optimized RTOS automatically so it becomes a non-issue. The RTOS consumes little memory and almost no development or debug time. Check it out at www.zeidman.biz/synthos.htm.
– Bob Zeidman