The presentation was “The Interrupt Driven PC” by Dennis Morin of Raytheon.

He started out by remarking on how nice our weather was compared to Massachusetts at this time of the year, with sunlight instead of 0 degrees, 3 feet of snow and ice. He is from a hardware group, although he has a degree in Computer Science. He grew up in a world where he could do anything he wanted on his machine and everything was interrupt driven.

Customers keep saying: “We want PC’s. We want PC’s”. If the customer wants something he gets it. They got into it, but had problems and hit snags. They didn’t have all of the capabilities they had before with the other machines. PC’s have a list of what you can do and what you can’t do. Dennis has done this presentation, The PC Interrupt, for many groups throughout the country. PC’s have touched everyone’s lives and are found everywhere. PC’s are a logical solution for test stations as they are economical. Industry offers I/O cards/peripherals to solve any problem. Consumers/users come with a ready skill due to the PC’s popularity. PC’s are supported by many operating systems such as DOS, MS Windows, LINUX, QNX (UNIX like) and OS2.

A very controversial subject in academia and among software developers is Bill Gates or The Penguin (LINUX)? Dennis believes that whether you like Windows or not it is here to stay so this presentation is Windows based. Interrupts in Windows are difficult, but Windows makes many other PC features simple and convenient. PC’s are supported by a wide variety of compilers: MS Visual Studio, National Instruments CVI, Green Hills, Borland and many more. It appears that Microsoft has become the number 1 choice in the compiler business. Why use interrupts? The primary reason is to avoid polling. Polling usually employs tight loops to check I/O changes and monopolizes CPU time. Interrupts can be used to control timing as external clocks can be configured to generate inputs at precise times. Interrupts allow you to ignore the device unless it has work to be performed.

The computer’s interrupt structure consists of the hardware and software components that integrate to successfully process interrupt requests. Hardware components include the IRQ bus lines, interrupt controllers, processor, BIOS and RAM. Software components include Interrupt Descriptor Table and Interrupt Service Routines (ISR’s). PC’s started with a single 8259 chip that supported 8 interrupts. A secondary controller was later cascaded to the primary 8259 and supported 15 IRQs. The Windows operating system determines interrupt priorities. Each of the IRQ’s can be programmatically masked by the PIC (Programmable Interrupt Controller). Masking is implemented through a register called the IMR (Interrupt Mask Register). The solution to the interrupt barrier of 15 is to use shared interrupts. Shared interrupts can be managed through an ISR (Interrupt Service Routine) that is a subroutine called asynchronously by external hardware during the execution of a background application. Interrupt response is immediate so this can simplify data synchronization. ISR’s perform assigned work and in a shared interrupt configuration the ISR also has to determine if the interrupt was from its assigned device. It checks the device’s interrupt register to see if it triggered the interrupt. If it did not, it checks the interrupt register of another shared device, does assigned work for the required device, and resets the interrupt bit. This seems like a perfect solution, but if Windows decides it has something more important to do just before the interrupt fires then it could miss its interrupt. Windows also controls the interrupt priorities so if you have multiple devices there is no way to prioritize them. In most cases there is plenty of time to do what you want but Windows is still in charge.

Just like the processor evolution there has been an evolution of interrupt controllers. The previous description covered the ISA PIC (Industry Standard Architectural Programmable Interrupt Controller). Evolution has now taken us to the APIC (Advanced Programmable Interrupt Controller), which has the advantage of supporting multiprocessors. The APIC consists of two components, the IOAPIC and the LAPIC (Local Advanced Programmable Interrupt Controller). Each logical CPU in the system will have a LAPIC. If you have one of the new HyperThreaded Processors you will have 2 LAPICs because there are 2 logical processors per HyperThreaded Processor. In a multiprocessor configuration, the system is designed to be able to pass interrupts back and forth across the system bus. These interrupts are referred to as IPI’s (Interprocess Interrupts) and they increase performance by allowing either CPU to respond to the interrupt. The IOAPIC is part of Intel’s support chipset and a system with a Pentium IV or later can have any number of IOAPICs. The system can be designed to support up to 64 IRQ’s but the most common is 24. The big advantage is the design eliminates the need for shared interrupts which directly equates to improved performance. However, as before, Windows sets the priorities.

Every device must have a driver program. In the Windows environment (XP), drivers have a .sys extension. Windows has mystified the Driver along with interrupts to something that can be described as “Very Complex”. Programmers have a great deal of difficulty trying to gain control of I/O devices. National Instrument’s LabWindows is a development tool very common in the test community. National’s support site says LabWindows cannot support kernel mode drivers and only kernel mode applications can capture an interrupt. They suggest using Microsoft’s DDK (Device Development Kit) to develop a device driver that will capture the interrupt and leave it to you to figure out how to write what is usually a very complicated driver. Once the device driver is developed set up an inter-process signaling scheme that will signal your LabWindow’s call back function and this will do the work of an ISR. I/O hardware vendors are all starting to offer drivers with this type of solution. Vendors provide a suite of API’s (Application Program Interface) that work in conjunction with their driver. One type of API is used in a Thread, where the API function call waits for the driver to signal that it has received an interrupt. This is a close to polling as it gets. There are many work arounds but the only true solution is Kernel Mode code as Kernel Mode code is the only way to gain direct access to the hardware. An application running in user mode such as LabWindows needs to pass through a Kernel Mode Driver before I/O hardware can be controlled.

The problems with interrupts on Windows are that driver development is complex, interrupt latency is not deterministic and interrupts cannot be prioritized. However, Windows provides economy, has many educated users and has extensive I/O solutions. What is wanted is Windows with all its conveniences, device control without the complexity of a Windows Device Driver, deterministic interrupt latency, and prioritized interrupt control. You want Windows doing things you want when you want.

One solution to the problem is RTX (Real Time Extension) by Venturcom that puts the developer in control and provides Real Time capability. Real Time doesn’t mean fast, it means deterministic. Deterministic means that events will happen in a predictable time frame. Windows thinks RTX is a Driver and when RTX is running, Windows believes it is servicing an interrupt. The most important part of RTX is the HAL (Hardware Abstraction Layer) extension. This is an extension of the Windows HAL, not a replacement. RTX uses its HAL extension to take control of Windows and mask all the Windows interrupts. The RTX HAL extension is also where the high speed timers are implemented. Windows provides timers with a minimum period resolution of 1 millisecond while RTX lowers the time to 100 microseconds. RTX interrupt latency speeds are also greatly increased. Interrupt latency speeds are hard to benchmark, but tests showed Windows averaged 41.8 microseconds with a minimum value of 39.4 and an unbounded upper value. The RTX machine averaged 4.1 microseconds with a minimum value of 3.3 and a maximum value of 22.6 microseconds. Determinism is the most critical attribute and the RTX machine has a tighter and faster distribution.

The RTX benchmarks sound very fast, but the truth is they don’t mean much to the Test Station Computer where the majority of the work is I/O out on the bus. The most common bus is the PCI bus which is a 32 bit 33 mhz bus. Industrial PC’s are now available with a 64 bit 66 mhz PCI bus, although there are not many 64 bit 66 mhz peripherals available. Bus speeds are much slower than processor speeds. Benchmarks showed that I/O is magnitudes slower than processor speeds. The RTX development environment leverages off the popularity of Microsoft’s Visual Studio and more recently Microsoft Visual Studio.Net. RTX plugs into the Microsoft Visual Studion.Net development and becomes one of the choices that the user makes when declaring what type of project will be built. RTX projects have a .RTSS file extension versus a .exe for a Windows application. RTX programs are developed in C and use a suite of API’s to perform/simplify a wide variety of tasks. Applications are easily debugged with all the standard tools such as step and watch. The kernel mode debugger does not work with .net2003 but Venturcom promises a fix later this year. RTX is a Windows XP extension so wherever XP can run so can RTX.

There is only one important hardware feature that is needed, Advanced Configuration and Power Interface (ACPI). The primary purpose of ACPI is to shut off power to peripherals when not in use. A secondary function of ACPI provides controls and information so that the OS can direct Plug and Play devices. The ACPI description table includes information on hardware resources each device needs and those currently in use. Plug and Play uses this information to dynamically configure resources to support each device. What this means to RTX is that it can move IRQ assignments around to prevent RTX/Windows resource conflicts.

Most contemporary desk-top PC’s have ACPI but industrial PC’s are all suspect. PICMG is a PCI Industrial Computer Manufacturers Group consortium of over 600 companies who collaboratively develop open specifications for high performance industrial computers. The big problem is the PICMG spec does not include ACPI so buyer beware.

Windows driven PC’s are the most logical and economical solution to today’s test stations but Windows is a preemptive non-deterministic operating system. Windows interrupts lack determinism and are complex to implement. Products that provide Real Time Extensions to Windows such as Venturcom’s RTX can provide Real-Time capabilities in conjunction with the desirable features of Windows such as networking and file sharing. If you need to use interrupts, you should be thinking Real-Time. Recently Venturcom, Inc. has changed their name to Ardence, Inc.

They can be reached at http://www.ardence.com

Dennis Morin presented an excellent talk with diagrams that were extremely useful in describing the problems of using Windows in a Real Time environment. This was an overview that told you what you needed to do to successfully overcome these problems without going into the depth of detail you would need to actually accomplish the design. This made the presentation understandable to people who understand basic computer concepts. His talk discussed where you needed drivers without (fortunately) trying to give you lessons on how to write them. It is the kind of a talk that a technical group that is about to try to use Windows in a Real Time environment should be given before they tackle the messy details of designing and testing it.