Still rolling your own small-footprint real-time operating system (RTOS) for low-end micros? You're in a minority that's shrinking fast. Even if you're moving to 32-bit platforms, getting an RTOS is easier than ever. So why build your own? Reasons like size, optimization, and owning the RTOS make no sense these days.
There's a plethora of options when looking at any variable, from licensing to targets. Open-source has had a major impact, as has royalty-free licensing. Even considering support costs for commercial or open-source products, going outside for an RTOS remains a bargain. Even more important to many companies, third-party support means RTOS expertise isn't stuck in one employee's head.
Some designers find it hard to justify paying for such a small amount of code. At the very low end, a kernel like CMX Systems' CMX-Tiny+ may be under 1 kbyte of program memory using a tiny amount of RAM. Even low-end kernels for 32-bit platforms like Express Logic's ThreadX come in under 2 kbytes and 500 bytes of RAM. There are even specialized kernels like the open-source TinyOS designed for wireless environments like ZigBee and 802.15.4.
The big difference between this small amount of code and a larger application is the amount of work done to get the code small, fast, portable, and reliable. Significantly more effort is spent on the RTOS than on most applications since its impact on application performance and reliability is usually critical.
A downside of going with a third-party RTOS is choice. There are too many of them, especially when you move into the 16- and 32-bit realm. The problem is a lack of standards for the application programming interfaces (APIs). Higher-end operating systems can support standards like µITron or one or more of the many IEEE POSIX APIs (see the figure). But the operating systems still tend to maintain their own unique API. This is one reason why most embedded code isn't portable, even though most RTOSs and embedded applications are written in C.
Of course, a unique API is usually the result of tradeoffs and design approaches. Interrupt handling, schedulers, task/thread priority systems, and even memory management techniques vary widely among operating systems. Things really become diverse when interprocess communication comes into play, ranging from unrestricted shared memory to message passing.
The benefits of a common platform are significant from the users' perspective but tend to be just the opposite from a vendors' perspective. In fact, some companies are in court about compatibility issues.
It's clear that operating systems at the low end will continue to proliferate. It's simply too easy to build one. On the other hand, it makes sense for most developers to just use an existing RTOS instead of building one from scratch. The question as to whether any API standards will arise at the low end remains open. Anyone interested in starting a standard?
CMX Microsystems • www.cmx.com
Express Logic • www.rtos.com
IEEE • www.ieee.org
TinyOS • www.tinyos.net
