Feature Archives | Feedback

Does Windows CE Matter?

by Jim Ready
Mentor Graphics, Microtec Division--San Jose, California

Microsoft recently entered the embedded software market with its Windows CE offering. With a smaller footprint than Windows 95 and a promise of additional real-time capability in the future, Windows CE has sent some shock waves through the industry.

Reaction typically falls into one of two extremes: Windows CE will wipe out all existing real-time operating system (RTOS) products, or, Windows CE is a non-event and will not affect the usage of current RTOSs. As usual, the truth is somewhere in between. The fact is, the industry has already "survived" such incursions by Microsoft; they just weren't as visible.

Most agree that MS-DOS was and maybe still is the most successful operating system for embedded systems (i.e., non-desktop computers). From DOS-based devices such as Hewlett-Packard's (HP) handheld calculators, to various medical, analytical, laboratory and measurement instruments, and other embedded systems, MS-DOS was designed into hundreds of applications. For the most part, these were best served by the capabilities of MS-DOS rather than a true RTOS. But it is equally true that thousands of designs employed a commercial RTOS because the application requirements called for the capabilities of an RTOS, not MS-DOS. The present situation should prove the same for Windows CE. Unless you believe all operating systems that declare themselves multi-tasking and real-time are the same, the application requirements, not someone's marketing department, will ultimately determine what kind of operating system (OS) is selected.

The recent announcements by HP about its embedded Java Virtual Machine (JVM) illustrates perfectly how the embedded market is not easily served by a "one size fits all" approach. HP, one of the world's largest producers of embedded systems (found in printers, fax machines, etc.), observed that Java, pulled by the requirements of the desktop and the Internet, was heading in a direction incompatible with its own embedded software needs. HP's solution was to specify and build a JVM designed for more classic or "deeply embedded" real-time applications. Not surprisingly, a number of RTOS developers quickly signed up for the HP technology because it more closely met their own customer requirements.

Just as there was the need to develop a Java more appropriate for embedded use, there is a need for different RTOSs to serve the various segments of the embedded market. Features required for handheld and other consumer electronic devices will pull Windows CE away from other deeply embedded designs. These designs are and will continue to be significantly different from designs targeted by Windows CE. The truth is, deeply embedded designs remain the domain of such leading RTOS companies such as Mentor Graphics' Microtec Division, with its VRTX RTOS, WindRiver Systems with its VxWorks, and others. These RTOSs are specifically tailored to meet the stringent requirements of deeply embedded devices, such as:

• Minimal memory footprint: In some configurations RTOS memory footprints may be measured in a few kilobytes of ROM space and as little as a few hundred bytes (yes, just hundreds of bytes) of RAM. Even fully configured RTOSs with networking and file systems still have relatively modest memory requirements (under 1 Mbyte).

• High throughput: Considerable effort is expended to minimize or eliminate interrupt disable times, to schedule disable times, and to make the RTOS kernel itself preemptible to maximize responsiveness and throughput. The requirement is to meet the response needs of other high performance hardware elements of the system, not the vastly slower response needs of a human user.

• Hard real-time performance: Besides high throughput requirements, another common requirement is to ensure that the system can meet deterministic or "hard" real-time response requirements. Many traditional software approaches that are suitable for consumer electronics, such as variable block size memory allocation, fail to meet the hard real-time requirements of deeply embedded applications.

• Configurability of system services: It is important to configure the OS to include just those services used in the application, not only to save memory but also to reduce testing requirements. In some systems all the software must be 100% tested, making it useful to eliminate unused code.

In the end, savvy RTOS companies will leave the palmtop designs to Microsoft, focusing their efforts instead on meeting the needs of the hard real-time and deeply embedded application developers. This leaves a huge supply of other opportunities and plenty of business for both Microsoft and the traditional RTOS companies to continue to grow and prosper in a large and growing embedded software market.

JAMES F. READY
CTO AND TECHNICAL STEERING COMMITTEE CHAIRMAN
THE MICROTEC DIVISION OF MENTOR GRAPHICS CORPORATION

James F. Ready joined Microtec in December 1993 as vice president, chief technical officer. Ready, a founder of Ready Systems, served as director and vice president of Ready Systems from 1981 to the merger with Microtec Research in 1993. Before founding Ready Systems, he held engineering and marketing positions at ROLM Corporation. Ready holds a bachelor's degree from the University of Illinois and a master's degree from the University of California, Berkeley.

Ready is best known as the inventor of the VRTX RTOS and is widely credited with starting the off-the-shelf RTOS industry. He has published numerous technical articles and papers, and has lectured worldwide on the principles of real-time software design. Ready has also served as a featured speaker at many conferences and industry trade shows.


		Click here to get your listing up.