circuitcellar.com
Magazine Support   Digital Library   Products & Services   Suppliers Directory 
 
 





 

April 1999, Issue 105

Win32 and Real Time


by Peter Petersen and Tom Schotland
Tempted to use Windows NT or 95 as an RTOS? Peter and Tom have an alternative. They create a Win32-compatible environment with dedicated embedded-system development tools—less overhead, no real-time deficiencies.

Start A Solution? Best of Both Worlds Two Approaches A Win32 Compatible RTOS Development Process Scalability Software & Sources

There are many arguments for using Windows NT or 95/98 for embedded systems. Mass production has led to decreasing prices for PC hardware and software. Both Windows systems support true 32-bit flat-address programs and allow full utilization of current 32-bit CPUs.

Software development tools are available and have been tested by countless developers. And, CPU vendors offer a range of 32-bit Intel i80386-compatible microcontrollers like Intel’s ’386EX, AMD’s Élan series, and National Semiconductor’s NS486SXF.

But, there are problems, too. Windows NT and 95 need a lot of computer resources. Windows 95 needs at least 16 MB to run smoothly, and Windows NT needs 32 MB to perform well (not counting the application’s needs).

Both systems require 100–150 MB of hard disk space. Even Microsoft’s Windows NT Embedded variant requires 16 MB of RAM and 20 MB of ROM or other permanent storage.

Another important issue is real time. Windows was designed for home and office applications, which (except for games or multimedia applications) have weak or no real-time requirements.

The ability to assign real-time priorities to a process may mislead developers to believe that Windows 95 and NT support real-time processing. But, Windows dynamically changes priorities at runtime to achieve a more equal or fair CPU time distribution. Sharing the CPU equally is not the goal of a real-time system.

Win32’s priority scheme implementation is also subject to priority inversion for application threads and deferred procedure calls of device-driver interrupt-service routines.

And, nonpreemptable system calls can use a nondeterministic amount of time. The internal timer resolution is fixed at 10 ms—too coarse for many systems. Besides, Windows does not guarantee that timer callbacks can be serviced within a maximum delay.

Application speed is another issue. Demon processes to implement various OS services such as virtual memory management can steal CPU time from a time-critical application.

Multitasking with Windows NT and 95 is not as efficient as in dedicated real-time systems. For example, running the code in Listing 1 under Windows NT, Windows 95, and an RTOS yields the results graphed in Figure 1.

9901021fig1.gif (5699 bytes)

Figure 1—The benchmark performs 400,000 semaphore operations with 200,000 task switches. The times shown here are for a 120-MHz Pentium.

Last but not least, licensing costs are a crucial factor for embedded systems development.