Those All-Important Device Drivers
Back to top

What's the definition of a device driver? A device driver is the software interface between a computer's OS (such as Windows) and hardware attached to the computer (such as a data acquisition plug-in board, GPIB instrument, or Ethernet communication interface). The driver is the abstraction layer that shields the program developer from the complexities of a hardware device.

All the commands to and from the hardware are ultimately executed by device drivers. Therefore, they're key elements in both the development and implementation of test application software.

Let's examine the role of a driver in more detail. Much like a printer or mouse device driver, a data acquisition driver is essential to the hardware's operation. It permits communication with the data acquisition device.

The parts of a PC each hardware device needs to use, such as RAM and I/O addresses, are protected by the OS. A user cannot communicate directly with these areas, but requires a device driver that acts as mediator between the test application and the OS kernel. (The kernel is a set of OS programs that implement primary system functions).

Some of the reasons for the layered architecture are robustness, portability, maintainability, flexibility, and other features that computer users demand. Imagine if the OS didn't prevent direct access to its sensitive areas, and every device user had to write their own protocols to gain access to hardware functions. Such an OS would be intolerable.

Driver Development
Back to top

A Windows device driver is written in Microsoft Visual C/C++, and is a special extension of the core OS. A device driver (typically a .SYS file) is executable code that loads in the PC's RAM and runs in kernel mode, or Ring 0, which is the level closest to the primary OS functions that manage the PC.

Kernel mode operations have higher priorities in the OS, and therefore provide device drivers with more attention, flexibility, and full unprotected access to the system memory and hardware. We'll discuss this in more detail shortly.

Device drivers must follow very specific rules and guidelines for interfacing to the rest of the OS. The Windows Driver Model (WDM) is the latest specification by Microsoft for coding common binary device drivers that are compatible with Windows 98 and Windows 2000.

The multitasking, multithreading, and multiprocessing (the Three Ms) of today's PCs further elevate the role of device drivers. A device driver should, as a minimum, handle the most likely multitasking scenarios that could effect operation of its hardware device. It must also preserve system integrity and not interfere with other drivers.

Since a typical PC has many drivers running (such as video, mouse, printer, keyboard, Ethernet, and hard disk controllers), each one should be a "good citizen" and not consume too much memory or processing time.

As you might expect, developing a robust device driver is a challenging task, due to the sensitive interrelationship between it and the OS, and the unlimited variety of multitasking conditions where it's used. Developing a good device driver requires intimate knowledge of both the hardware device and the OS software. Many Windows crashes are caused by unpredictable conflicts and malfunctioning device drivers.

The DOS to Windows Evolution
Back to top

The DOS to Windows evolution, plus today's more complex test systems, have increased the demands placed on software and its development. Programming a device was relatively easy in DOS. The program had to do one thing at a time and one thing only. Direct access to the I/O address space was available with relatively simple commands in C language (inp and outp) or BASIC (peek and poke).

With the multitasking paradigm of Windows, Microsoft had to establish a new set of rules for managing communication with peripheral devices. A Windows driver is no longer just a single .EXE file that gets loaded in memory or copied to a special directory.

A Windows driver is a package consisting of many files (inf, sys, vxd, DLLs, exe, and Lib files, for example). These require a specific installation process, registry modification, plug-and-play implementation, power management setup, and resource management, to name only a few. There are many other considerations too.

This process isn't just a matter of copying files to a hard drive; it actually is an algorithm that handles the different versions of Windows appropriately, including Win95 (versions a, b, c), Win98 (1st and 2nd Edition), Win NT (SP1 to SP6), and Windows 2000. When Windows is upgraded from one version to another, it can easily affect driver installations. It's expected that device driver developers follow suit and upgrade installations as necessary.

A test-and-measurement application may simultaneously acquire data from multiple devices, control a process, graph data, save it in a database, and make it available on the Internet. The more demanding the test requirements, the greater the complexities of PC-based test systems, which in turn impose more conditions on the drivers and other system software.

In most cases, it will not be necessary for a programmer to develop the necessary drivers. They will be available from hardware and software suppliers, and can be interfaced by the application program.

The Application Programming Interface
Back to top

A developer sees and interacts with the API when creating an application program. The API greatly simplifies common tasks the developer performs with the hardware, and makes communications between the two transparent.

Since the API acts as liaison between the device driver and the test application, end-users rarely have to communicate directly with the driver. Therefore, it's important for a driver developer to know how users will program or configure the hardware device, before building the driver foundation under the API.

The API typically is part of the driver package; it should be the first piece designed when developing a device driver. An example of an API is the ActiveX control interface, which plays a significant role in simplifying development of test programs.

Other types of APIs are COM objects, DLLs, libraries, and support modules for Visual BASIC, Visual C/C++, and other programming languages.

The Role of an API
Back to top

From its definition, it follows that the API can be a major factor in the results obtained from a test application, successful or otherwise. By way of analogy, analog and digital characteristics are major determinants of hardware performance, and the API is a major determinant of software performance.

A typical test-and-measurement application requires careful consideration of both. For example, streaming digital data to disk at 100 kHz requires not only high-speed data acquisition hardware, but also proper API tools to take advantage of this speed by transferring data efficiently.

Similarly, accurately logging of temperature data requires not only good measurement techniques and cold-junction sensors, but also a cold-junction compensation algorithm in the API.

Ideally, hardware features are automatically supported by the software. However, both developers and end-users need to pay close attention to the features offered by the API and its possible limitations.

Hardware Independence
Back to top

An important feature of the ActiveX API mentioned previously is its hardware independence. This factor has the potential to increase the longevity of your test application software. It's also a critical cost issue due to fast-moving PC technology and frequent data communication hardware obsolescence. For example, look how quickly the transition from RS-232 to USB to FireWire is occurring.

The key question to ask is: Does the software have to be rewritten with every hardware upgrade? The answer depends on the portability of the API.

ActiveX Controls
Back to top

Even though a device driver must change with a significant hardware change, the API exposed to the user doesn't have to change, especially if ActiveX-based.

ActiveX is a set of rules governing how different applications or software components should interact and share information in the Windows environment. Because developers have been rapidly shifting to component-based software architectures, ActiveX is one of the most important features in an API.

An ActiveX control (formerly known as an OLE or OCX control) is a user interface element created using the standards for information exchange and functional modularity among Microsoft Windows-based applications. ActiveX controls are based on Component Object Model (COM) technology, a software architecture that enables applications to be built from software components.

COM technology provides many benefits, including easier integration, scalability, and reusability, as well as language independence, cross-platform compatibility, and context-sensitive help.

The Benefit of ActiveX
Back to top

A major benefit of ActiveX is its use of a single, simple object to replace many lines of code for common functions. This lets programmers create reusable software components that can be interchanged without having to rewrite entire applications. Interchangeability reduces development cost and extends the life of an application.

For example, an application originally written for a 16-channel 100 kHz analog I/O board could be used with a 64-channel 300 kHz analog I/O board by simply replacing an ActiveX control that describes the characteristics and functionality of the data acquisition device.

The following snippet of code uses three different ActiveX controls. ActiveX1 acquires the data from the measurement device, ActiveX2 performs the analysis, and ActiveX3 graphs the data.

This code shows the simplicity of programming with ActiveX controls. In this component-based open architecture model, each of the ActiveX controls is an independent entity, which could be supplied by more than one vendor.

Test-and-measurement manufacturers and third parties have developed thousands of ActiveX controls, which strongly support the concept and benefit of open architecture software systems. These properties of ActiveX and its underlying model protect your software investment by making applications more portable and hardware upgrades easier.

For instance, DriverLINX is a standard data acquisition software driver for Keithley's data acquisition hardware. Its design is based on the common object model and therefore is truly hardware independent across all Keithley's boards.

While it's natural for a given test-and-measurement vendor to maintain the same driver interface and syntax across all its hardware and languages, software reusability remains a challenge when using multiple vendors.

Besides the tools mentioned, there are certain programming and hardware designs that improve the performance of a test application. We'll look at some of the more important ones in the next part of this ChipCenter 2-part article. We'll examine the role of FIFOs and DMA operations in automated applications, and explore the tradeoffs between polled versus event-driven programming.

About the Author
Back to top

Mike Bayda is a Data Acquisition Marketing Engineer with Keithley Instruments. Bayda holds an MSEE degree from Cleveland State University and a BS in Physics from the University of Orleans, France. In the past, he worked as a test engineer at NASA's Lewis Research Center, and now has ten years of experience in test-and-measurement under his belt. E-mail: bayda_mike@keithley.com. Phone: (440) 542-8026.

		Click here to get your listing up.