|For novel ideas about building embedded systems (both hardware and firmware), join the 27,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype, no vendor PR. It takes just a few seconds (just enter your email, which is shared with absolutely no one) to subscribe.|
By Jack Ganssle
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?