Managing a Real-Time Hardware Interface with INtime and Windows XP Embedded
TenAsys Corporation
September 2003
Applies to:
Microsoft® Windows® XP
Microsoft Windows XP Embedded
Microsoft Windows XP Embedded with Service Pack 1
Contents
Overview
Hardware Configuration
Accessing Hardware from the Real-Time Application
Interrupt Configuration
Timing Services
Overview
Microsoft® Windows® XP Embedded is a good platform to consider in designing a dedicated application from the point of view of features, footprint management, and the wealth of support and applications available. However, when an application requires real-time performance from a hardware interface, a real-time extension is required, along with some partition of the platform and the application. Time-critical threads must be executed under a real-time kernel, and interrupt resources must be dedicated to the hardware under that scheduler.
Hardware Configuration
INtime software, from TenAsys Corporation, allows a real-time operating system to run on the same platform as Windows XP Embedded by encapsulating each system in a virtual-machine architecture. Each operating system operates independently of each other, and the architecture is such that all real-time activities take precedence over all Windows activities. Time-critical processes run on the INtime system and those that are not time-critical processes run on the Windows system.
A simple INtime application typically consists of a Windows process and a real-time process, with some communication between the two for control and data flows. The real-time process typically controls a hardware interface. It is necessary to configure the hardware so there is no interference from any Windows components while the real-time application is accessing it.
In pre-plug and play (PnP) days it was possible simply not to install a driver for the interface and assume that there was no difference to Windows. Since Windows 2000, however, the Windows PnP manager detects all hardware and attempts to configure a driver for it. If it is unsuccessful, then it actively attempts to power the device down and to make sure that it cannot interfere with the Windows system.
In order to work around this, Windows must be given the impression that it has control of the device, but it is not going to touch it after that. This feat is accomplished by installing a dummy PnP driver for the hardware in question, which takes care of power management issues also.
Accessing Hardware from the Real-time Application
Now that the hardware is effectively isolated, it can be accessed from a real-time application. In the INtime application environment, all threads operate in user mode (IA32 Privilege Level 3) but direct access to the input/output (I/O) space is granted. Each real-time process operates in a flat address space, so physical memory addresses must be mapped to the local virtual address space before they can be used. Following this process, it is fully accessible. Finally, an application can install an interrupt handler for a given interrupt request (IRQ) resource in order to handle interrupts from the device.
Interrupt Configuration
One of the primary reasons for installing INtime software is to control interrupts in real time. An interrupt-driven device must be configured so that its IRQ is not shared with any Windows devices. The reason for this is that although the INtime kernel can handle the first interrupt on an IRQ in a deterministic manner, if it is being shared with Windows devices then the system is dependent on the Windows driver to handle the IRQ before the INtime application can be interrupted again on the same level. Because Windows is not deterministic, the sharing of IRQs cannot be allowed.
Again, the software must function within the bounds of the Windows PnP manager which is responsible for routine device interrupts to IRQs. The problem is worse with Peripheral Component Interconnect (PCI) devices, especially on platforms with a mixture of Industry Standard Architecture (ISA) and PCI slots. In this case, the PnP manager attempts to assign all PnP interrupts to the same IRQ, leaving as many free for any ISA devices which might be installed (which cannot share interrupts).
The dummy device driver we used to isolate the device is helpful again here. When it is offered interrupt resources by the PnP manager, it requests a unique IRQ, which the PnP manager is obliged to attempt to fulfill. Of course, this is not always possible because it is often the case that PCI interrupt sources are hardwired together on the motherboard. Often, it is necessary to select a PCI slot for your device where the interrupt line is not shared with a Windows motherboard device. Careful hardware evaluation and selection is necessary here.
Timing Services
Of course, interrupts are not the only method of being notified of a device request. INtime software also offers a range of timing services so that hardware may be polled at regular intervals. The design of the INtime system is such that the jitter of the system clock is very low (in the order of a few microseconds, depending on the platform chosen) so this ensures accurate polling times. Thread jitter depends on the priority of the polling thread.