Using Linux in Embedded and Real-Time Systems

When you need an embedded operating system, Linux is a good place to start. Here's why.
Small-Footprint Linux

For many embedded systems, the main challenge in embedding Linux is to minimize system resource requirements in order to fit within constraints such as RAM, solid-state disk (SSD), processor speed and power consumption. Embedded operation may require booting from (and fitting within) a DiskOnChip or CompactFlash SSD; booting and running without a display and keyboard (“headless” operation); or loading the application from a remote device via an Ethernet LAN connection. There are many sources of ready-made, small-footprint Linux. Included among these are a growing number of application-oriented Linux configurations and distributions that are tuned to specific applications. Some examples are routers, firewalls, Internet/network appliances, network servers, gateways, etc. You may also opt to create your own flavor of embedded Linux, starting from a standard distribution and leaving out modules you don't need. Even so, you should consider jump-starting your efforts by beginning with someone else's working configuration, since the source code of their version will be available for that purpose. Best of all, this sort of building on the efforts of others in the Linux community is not only completely legal—it's encouraged!

Real-Time Linux

Many embedded systems require predictable and bounded responses to real-world events. Such “real-time” systems include factory automation, data acquisition and control systems, audio/video applications and many other computerized products and devices. The commonly accepted definition of real-time performance is that real-world events must be responded to within a defined, predictable and relatively short time interval. Although Linux is not a real-time operating system (the Linux kernel does not provide the required event prioritization and preemption functions), several add-on options are available that can bring real-time capabilities to Linux-based systems. The most common method is the dual-kernel approach. Using this approach, a general-purpose (non-real-time) OS runs as a task under a real-time kernel. The general-purpose OS provides functions such as disk read/write, LAN/communications, serial/parallel I/O, system initialization, memory management, etc., while the real-time kernel handles real-world event processing. You might think of this as a “have your cake and eat it too” strategy, because it can preserve the benefits of a popular general-purpose OS while adding the capabilities of a real-time OS. In the case of Linux, you can retain full compatibility with standard Linux while adding real-time functions in a non-interfering manner.

Of course, you could also dive in and modify Linux to convert it into a real-time operating system, since its source is openly available. But if you do this, you will be faced with the severe disadvantage of having a real-time Linux that can't keep pace, either features-wise or drivers-wise, with mainstream Linux. In short, your customized Linux won't benefit from the continual Linux evolution that results from the pooled efforts of thousands of developers worldwide.

Who Needs Real-Time?

In any case, how many applications actually require real-time enhancements to Linux? Bear in mind that “real-time” is a relative, not an absolute, expression. As mentioned before, a real-time system must handle real-world tasks within acceptable—and predictable—time windows. Although CPUs run at ever-increasing speeds (approaching 1GHz), the world around them goes on at a constant speed. Therefore, real-time performance is becoming ever easier to achieve. Back when the “traditional” RTOS were first developed, embedded systems depended on 4- and 8-bit CPUs clocked at single-digit megahertz speeds and running out of kilobytes of RAM. Now, with CPUs speeding along at up to 1GHz and with memories measured in the hundreds of megabytes, real-time performance is becoming less of a concern. The greater concern has become speed to market and sophistication of functionality. Where execution efficiency was the watchword of the CPU-bound past, protocols are the key to the Internet-centric future.

Going Soft

There's a term to describe the use of ordinary operating systems in real-world applications with acceptable results: “soft real-time”. In many systems, you can ensure that the real-world constraints of your application can be achieved without resorting to using a specialized RTOS. However, this tends to be practical only when required response times are in milliseconds—not microseconds. Assuming that's the case, a minimally configured Linux on a reasonably fast processor (486-133 or faster) without special real-time add-ons may well suit your needs. If soft real-time sounds like what you need, you may want to check out a Linux add-on called Linux-SRT (soft real-time). On the other hand, your system may indeed require microsecond-level response times. In that case, you can either dedicate an inexpensive microcontroller or DSP to handling the time-critical events, or you can use one of several available real-time Linux add-ons (e.g., RTLinux or RTAI).