September 12, 1997

Tackle real-time applications with Windows NT

Richard A Quinnell, Technical Editor

Following the precedent of the PC architecture, the Windows NT operating system has entered the embedded-systems arena. For the right applications, it can be a contender.

The architecture of the x86-based PC has been making steady inroads into embedded-system hardware designs. Now, the Windows NT operating system is poised to challenge real-time operating systems (RTOSs) for PC-based embedded systems. Several approaches have emerged for adapting Windows NT to real-time operation. Choosing the right approach for an application, however, is more a matter of impact than performance. Designers should closely examine the underlying technology as well as its effect on design and maintenance efforts.

The reasons for using a Windows OS in an embedded-system design are analogous to those for using the PC architecture in the design. Both choices seek to take advantage of the tremendous amount of product and application support available for a Windows PC. Experienced designers abound, applications are legion, and inexpensive, first-class development tools are available for the Windows-PC architecture. Further, companies are looking to standardize on only a few architectures and OSs to keep development costs manageable. Using the same OS for both internal and product use has great managerial appeal.

The Windows OSs have added appeal for embedded-system designs: Users are familiar with Windows. That familiarity means that systems with the look and feel of Windows in their control interfaces are popular with end users. The Windows OSs also can simplify system development. Windows offers graphical displays and networking facilities as part of the package, freeing developers to focus on the applications instead of the interfaces.

What has prevented Windows from seeing substantial use in embedded systems has been its lack of real-time capability. Designed for a desktop environment, the Windows OSs lack many of the features that bring deterministic behavior to RTOSs. New product offerings that augment Windows' capabilities are changing that situation.

NT gets real-time boost

Although virtually every member of the Windows family has real-time extensions available (see box "Other Windows onto real time"), Windows NT is at the center of the most intense activity. It is the most suitable of the Windows OSs for large, industrial applications. Unmodified, Windows NT provides a reliable, 32-bit OS with pre-emptive, priority-based multitasking and a host of networking and security mechanisms. For some systems, it is sufficient to handle real-time applications by itself. Appropriately configured, Windows NT running on a high-speed CPU can keep up with events needing a 5- to 10-msec response time.

For more demanding applications, however, Windows NT needs some help. Windows NT pre-empts all tasks with any interrupt. Its interrupt handler then uses a deferred procedure call, performing only minimal action in the interrupt-service routine and placing the rest of the task into a queue for execution. Tasks execute in the order received without regard to priority. It is this FIFO structure that makes the Windows NT worst-case response times so slow.

An interrupt for a high-priority task can circumvent the queue and place its deferred task at the front of the line. This action cannot suspend an executing task, however, and may not gain much advantage. Jumping to the head of the line also may push back an earlier task of the same or higher priority.

The products that seek to apply Windows NT to real-time applications concentrate on altering or bypassing this structure. These products provide, instead, more traditional, multilevel prioritizing as well as control over the priority of both interrupts and tasks. Three basic approaches are available, each with differing levels of intrusion into Windows NT.

Hyperkernel: least intrusive

An approach from Imagination Systems Inc (a subsidiary of Nematron Corp, Ann Arbor, MI) makes the least intrusion. Hyperkernel 4.21 injects real-time responsiveness into Windows NT by taking over the interrupt structure at the hardware level (Figure 1). It then alternates between real-time tasks and Windows NT tasks at programmable intervals (typically 100 µsec). Windows NT tasks run unaltered and unblocked; they simply get less of the CPU's time than before. The real-time tasks run under Hyperkernel.

Hyperkernel provides communication between Windows NT and the real-time applications through the use of shared memory. This communication allows the Windows NT user interface to communicate with the real-time application. Application data for display in a Win NT window, user responses, and other interactions between Windows NT and the application occur by passing their data through the shared-memory space.

In addition to the memory it shares with Windows NT, Hyperkernel needs its own private memory space. It takes the memory it needs from the top of Win NT's stack and then locks the memory to protect it from Win NT's intrusion. Hyperkernel requires a minimum of 1 Mbyte for the OS. Application-memory needs are additional.

Hyperkernel's method for providing real-time behavior under Windows NT means that application developers must divide their design into two parts. The real-time part runs under Hyperkernel; the rest, such as a display window, runs as a Windows NT application. To help simplify this dual- soft- ware -development approach, Imagination Systems structured Hyperkernel to accept programs developed using Microsoft's (Redmond, WA) C compilers. Thus, users can develop both parts of their code on the same system.

INtime adds iRMX to Win NT

A slightly more intrusive product than Hyperkernel is INtime from Radisys Corp. INtime also adds a real-time kernel to the system but makes some alterations to the Windows NT hardware-abstraction layer (HAL) during its INtime's installation. The modifications trap attempts to modify the real-time and time-of-day clocks so that the real-time kernel controls the system timebase. The modifications also reserve some interrupts for the real-time kernel's use and block attempts to assign or mask those interrupts. The real-time kernel is a version of Radisys' iRMX OS.

INtime adds its real-time kernel to Windows NT by using a hardware feature of the Intel (Santa Clara, CA) CPUs. This feature allows the CPU to run multiple independent tasks in separate memory spaces. The CPU hardware protects the two sets of tasks from interacting. In effect, then, INtime can run the iRMX OS in parallel with Windows NT as though they were on separate computers. The only common point is the CPU's interrupt handler, which does not support independent tasks. INtime takes control of the interrupt handler, however, to prevent Windows interrupts from interfering with real-time processes.

Communications between the real-time and Windows NT processes occur through the NTX and RT application-programming interfaces (APIs) and the NTX device driver (Figure 2). Non-real-time processes interact with the real-time processes by making calls to the NTX API. The RT API is the real-time processes' mechanism for calling on Windows NT functions. The NTX device driver passes data between the two OSs. A block of code, the OS-encapsulation mechanism (OSEM), coordinates between the two OSs and provides additional memory protection. Mailboxes and shared memory allow the OSs to communicate.

Like Hyperkernel, INtime requires developers to divide an application into two parts. Two tools, both hosted under Windows NT, provide the development environments for the two parts. Microsoft's C/C++ Developer Studio with an integrated debugger handles the real-time code. Radisys provides a dynamic Windows NT debugger that is aware of the INtime constructs, so developers using the two tools together may simultaneously view and debug both parts of the application.

RTX makes Win NT real time

To avoid the need for two-part application programs, VenturCom made its RTX 4.1 real-time extensions a native Windows NT operation. Installing RTX on a Windows NT system changes the HAL and adds to the Win32 API. The Windows NT kernel, executive, and device drivers remain unaffected.

The modifications to the HAL make the system's interrupt response more deterministic. They add fast-clock and high-precision timer services for precise task scheduling. The HAL modifications also allow RTX to intercept Windows NT STOP conditions to prevent Win NT "blue-screen" crashes from halting real-time operations.

The additions to the Win32 API form VenturCom's real-time API, RTAPI. The RTAPI provides constructs essential to deterministic operation, such as process and thread management, fixed-priority scheduling, and interrupt management. It also provides I/O-area access to eliminate the need for some device drivers as well as memory management to allow processes to lock memory.

VenturCom implements the core functions and resource management of RTX as a Windows NT device driver. The driver provides the services necessary for a real-time subsystem (RTSS), including a process and thread scheduler and interprocess communications between Windows NT and RTX. Interprocess communication uses two FIFO message buffers, one for each direction of information flow.

Collectively, the RTAPI, RTSS, and modified HAL alter Windows NT so that it can handle both conventional and real-time processes (Figure 3). Programmers use the Win32 API calls for non-real-time functions, use both Win32 and RTAPI calls for functions that deal with both processes, and use RTAPI and a real-time-compatible subset of Win32 for processes that need real-time operation in less than a millisecond.

Because RTX runs as part of Windows NT, rather than as a second OS, developers create the applications as one program, not two separate pieces. However, to use the appropriate API when programming, developers still need to know which tasks need real-time performance.

Interrupts: Win NT's weakness

The VenturCom, Radisys, and Imagination Systems approaches to running real-time applications with Windows NT all differ, but they share a common weakness: the interrupt. All three approaches take control of interrupt response to ensure that the system quickly handles critical interrupts. Unfortunately, they cannot control what the system does to interrupts when Windows NT has control.

Sections of the BIOS and the Windows NT kernel, in addition to some device (such as video-card or disk-drive) drivers, disable interrupts during critical sections of code. Some poorly written device drivers disable interrupts for an excessive time period. While interrupts are disabled, real-time processes are locked out. Thus, the potential exists for a Windows NT device or application to halt real-time processes indefinitely.

The BIOS and Win NT-kernel operations that mask interrupts keep real-time operations on Windows NT to a worst-case interrupt response time of 20 to 50 µsec. The effect of device-driver masking, however, is unbounded. The only way to avoid the effect is to ensure that the system running real-time code has only well-behaved drivers. That necessity means that you have to thoroughly test final system configurations in addition to controlling system configuration at the customer site. This added burden of controlling system configuration is one of many logistical and behavioral factors that designers should evaluate before choosing real-time Windows NT.

A behavioral factor with which designers should concern themselves is the system's behavior in the event of a software failure. Both Hyperkernel and INtime run the RTOS independently of Windows NT. If Windows NT suffers a system failure, resulting in the dreaded blue-screen shutdown, the real-time portions keep running.

System response to failure

This persistence can be good or bad, depending on how you write your application. If the system keeps running normally but without the operator interface that Win NT provided, it could fail to receive critical operator commands. Systems need to detect Windows NT failures and provide a transfer of user interface or a controlled shutdown. Windows NT cannot reboot without also rebooting the second OS.

The flip side of the coin is that Windows NT may keep running while the real-time portion crashes. Unless designers plan for such an event, users may unknowingly interact with displays and controls that appear normal but have no validity.

VenturCom's RTX approach doesn't face the same issue, because it runs as part of Windows NT. A software failure in Win NT also affects the real-time portion. To prevent catastrophic failure, RTX traps Windows NT STOP commands, giving the real-time portion an opportunity to execute an orderly system shutdown.

Another factor in the decision to use Windows NT is the cost, both in license fees and memory requirements. Windows NT runtime licenses cost approximately $150 to $200. That cost is in addition to the license costs of the real-time portion (Table 1). The memory requirements for implementing Windows NT in an embedded system are around 10 Mbytes without applications.

Tools help Win NT scale down

This memory cost has at least a partial solution. Both VenturCom and Radisys offer tools that help pare Windows NT to the essentials that an application needs. VenturCom's Component Integrator tool analyzes application code and builds only the parts of Windows NT that the application uses into a ROMable image. Radisys provides Intrinsyc's Integration Expert (IX) as part of its development package. IX analyzes the application code, automatically calculates code dependencies, profiles code use, and helps developers target a trimmer Windows NT to their systems.

If the cost and failure-response behavior of real-time Windows NT is acceptable, field-maintenance issues may become the deciding factor in which real-time approach a Win NT-based project needs. Although not normally part of a designer's concerns, field maintenance can be a significant part of a company's product-life-cycle cost.

One important aspect of field maintenance that applies to Windows NT is the need to upgrade installed systems with new software and hardware. Hardware changes resurrect for field engineers the specter of driver-induced interrupt masking that haunted de-signers. Software upgrades to Windows NT can be worse. If Microsoft makes substantial changes to new releases of Win NT, those changes may compromise the real-time system. In case of this event, the degree to which the real-time approach modifies Windows NT is the concern. The Hyperkernel approach, operating below the HAL, is least impacted by revisions to Windows NT. The RTX approach is most at risk of being adversely affected.

Another aspect of field maintenance is the need to handle customer problems. Dual-OS approaches can add to maintenance costs because they need higher level support personnel. Customer-service engineers need to be familiar with two OSs to identify and fix system bugs.

The many concerns associated with using Windows NT in a real-time system require serious attention. If you can live with the drawbacks, however, using real-time Windows NT can benefit both your product and your organization. Standardizing on one OS for both tools and product can streamline design. Automatic inclusion of drivers, graphics, and networking features means that developers can focus their attention on applications instead of interfaces. In addition, users gain a system that feels familiar and comfortable. Just watch those drivers.

| EDN Access | Feedback | Table of Contents |