Open Source Software for Real-Time Solutions

Dean Koester, Cygnus' Director of Product Marketing, sees a whole spectrum of real-time applications. They vary throughout that spectrum according to their requirements. We will look at Koester's spectrum by examining the two ends, and see why RTLinux and eCos fall where they do on the spectrum. While we are at it, we will look at the economic implications of some of those requirements.

The term “real time” has become a buzz word, as in “real time stock quotes”. If the NYSE ticker is running an hour late, your quotes aren't in real time and that's that. Real time, according to Koester, means getting the job done on time, every time. Not some of the time, or most of the time, but every time. This means your primary concern is not average response time, but worst-case response time.

Take a simple example: a processor that controls a servo based on one analog-to-digital converter's input. The processor reads the A/D converter and adjusts the servo accordingly. Painting pretty pictures based on the data or shuffling it off to a log file are secondary.

Linux, as Linus Torvalds and his team of kernel hackers provide it, simply is not a real-time operating system, nor was it ever intended to be one. It is designed to provide the best average response time. As Linux is loaded down, it gracefully degrades the performance of all tasks. This is not acceptable for real-time computing. The data acquisition and control functions must respond on time, every time. They cannot degrade, gracefully or otherwise.

The RTLinux response to this is to write a minimal RTOS, then run Linux as a background task under the minimal RTOS. As long as the real-time functions are getting done, and there are resources to spare, Linux is permitted to run whatever tasks are assigned to it. The typical RTLinux application runs one or two real-time tasks. They collect data and stuff it into FIFOs. All processing is done in the background, using Linux and all the neat programming tools that come with it.

This makes RTLinux suitable for what we might call “desktop real time”: data collection where overhead such as several hundred megabytes of Linux are acceptable, even when you don't use them in the application. It means applications where a typical desktop computer, with its keyboard, video display (even running X) and other extraneous processes are acceptable overhead. The extreme here is a student project which collects a few streams of analog data and uses them to control some device.

While RTLinux is excellent for desktop real time, it is by no means restricted to the desktop. Applications using RTLinux running on stripped-down PC hardware can be embedded into products.

RTLinux also offers very fast development for real-time programming. The data collection driver is a Linux module, which means you can remove it, recompile it and re-insert it without rebooting. All of the post-collection data messaging is done with the tried-and-true tools we all know and love, such as Perl and Ghostscript.

Also, RTLinux offers very inexpensive R&D economics. If you have a desktop computer with Linux on it, you already have most of the capital cost of implementing a minimal RTLinux project. You can spend money for custom PC-compatible hardware if volume and real estate are constraints. Many RTLinux projects will do this.

However, Cygnus wasn't after “desktop real time”. The term “embedded” originally meant putting a microprocessor into some product in such a way that it wasn't obvious a computer was even there. A classic case is a photocopier. Even a simple home photocopier has some microcontroller running it. But it doesn't look like a computer: there is no QWERTY keyboard, no monitor, no GUI. The key to an embedded application is that absolutely no inessential overhead is acceptable.

There are two classic embedded project paradigms. The first is a mass production product, where tens of thousands or millions of pieces will be manufactured. Spending hundreds of thousands of dollars up front to shave ten cents off a single unit is economical because of the production run involved. An automobile brake controller is an archetypal application.

The other classic embedded project is where the customer is the European Space Agency (ESA) or the Department of Defense, and spending vast piles of money to shave a gram of weight is considered economical. For example, the Jet Propulsion Lab's Mars Pathfinder or Voyager spacecraft fit this paradigm.

Cygnus decided it was simpler to start from scratch and build an RTOS for embedded applications than it would be to strip unnecessary components from Linux to produce an RTOS suitable for embedded projects. eCos was designed to scale down to just a few kilobytes of code if all you require is a HAL and C library. An attempt to strip Linux that far down would produce something you would not recognize as Linux.

An RTOS suitable for embedding in applications where lives are at stake, such as automobile brakes or pacemakers, must be provably reliable. An application where high production runs are planned must also be highly reliable, because the costs of replacement are much higher than the costs of making sure the product is reliable.

A key component of reliability is simplicity: the simpler an RTOS is, the faster you can prove its reliability because there are fewer interactions to test. So the time-to-market you may gain in fast prototyping with RTLinux, you may lose proving that your product is reliable.