Embedded systems go Linux
Microprocessor-based embedded control systems traditionally have used proprietary real-time operating systems (RTOSs) to attain the real-time or near-real-time response needed in such applications as automotive engine control systems. Proprietary RTOS, however, involve some particularly thorny issues.
One major issue is simply the engineering cost to develop an RTOS. Proprietary RTOS development is up to the system designer, who usually has more pressing issues to deal with-for example, focusing on developing the algorithms for a particular application-than engineering background software. Even with a previously developed RTOS, there are maintenance issues.
To take advantage of new, better performing hardware, the system engineer has to make more or less major revisions to the RTOS. Chip makers have no motivation whatsoever to help system engineers update a proprietary RTOS to run on their new hardware, so the task, once again, falls on the system engineer. System designers can avoid these issues by designing their applications around a widely disseminated commercial operating system. Currently, two such OSs on the market have enough presence to make them attractive: Microsoft Windows and Linux.
According to Brian Handley of Macraigor Systems , embedded system designers are voting with their feet overwhelmingly for Linux. Macraigor provides a suite of hardware and software debugging tools used for all aspects of embedded development from hardware debug through manufacturing and test. The company is, therefore, uniquely situated to see embedded-system OS trends. 'Microsoft products just aren't seen,' he reports.
Why should the most commonly used operating systems on the planet be invisible in the embedded systems space? The answer is latency. Most embedded system applications require real-time response rates. OSs designed for office- and Internet-oriented use are the opposite of deterministic. They respond to interrupts when they get to them.
Linux, on the other hand, is an open-source product. That is, the source code is freely available for use, re-use, and modification by anyone with the wherewithal and desire to do so. Specifically, there has long been a cadre of Linux users interested in applying the OS in real-time situations.
MontaVista Software has optimized Linux for various environments-including real time. 'What real time means,' says Paxton Cooper, MontaVista's director of product marketing, 'depends on your application.'
The key is to know how fast your embedded system needs to react. Windows is effectively real time for desktop jobs, such as text editing. The computer is usually waiting for you to press the next key and few users type fast enough to tax Word's type-ahead feature. A few hundred milliseconds latency in an antilock braking system (ABS) controller, on the other hand, would likely lead to disaster.
The figure shows the latency requirements in various use requirements and compares them to existing Linux implementations. Applications that most users would consider 'real time' range from 1 ms to below 10 ms. MontaVista's 4.0 version Real-Time Linux, with latency in the tens of microseconds range, provides sufficient 'real-time' performance for nearly half of embedded applications, including nearly all mobile phone and industrial applications, and most telecom applications. Further improvement is needed for automotive control applications, such as engine control modules and, especially, safety systems (ABS, air-bag triggers, etc.).
The upshot is a real win for the Linux community. As processor speeds increase and more responsive versions of the open-source OS become available, the need for 'roll your own' RTOSs for embedded systems is going away except at the high-performance end.
— C.G. Masi , senior editor,