What Does a Driver Do For You, Anyway?

When you use a printer, your application program sends data to software called a print driver. The print driver translates messages about a page from the application program into messages that tell the printer where to place the dots on the page. The print driver processes other messages, too, such as one that forces the printer to eject the current page.

Each printer requires a unique print driver on its host computer, but that driver doesn’t directly control the electrical signals on the printer port. Instead, the print driver sends commands to a lower-level driver, often called a device driver in Windows 3.1/95/98 or a kernel-mode driver in Windows NT. I’ll use the term "device driver" to mean either type throughout this article. The device driver in Figure 1 converts its incoming messages into data that controls the printer port.

Because the low-level device driver resides in the operating system, you never have to know it’s there and you can think of the printer driver as the only driver needed. Test instruments, however, often have several software layers between application programs and hardware. Here’s where the confusion comes in. Some people call just the lowest layers "drivers." Others call all the layers a driver.

If you define a driver as the I/O library and the device-driver layers in Figure 2, then calling any layer above the I/O library a driver is inaccurate. If you call all layers between your application program and your hardware a driver, then any layer is a component of the driver. What you call a driver may also depend on what type of instruments you use—PC-plug-in boards, parallel-port instruments, IEEE 488 instruments, or VXIbus instruments. For clarity in this article, I’ll define a driver as an I/O library and a device driver only. I don’t include higher layers in my definition of a driver.

As an engineer, you develop applications that control instruments. Chances are, you’d rather send commands like "take 100 samples on channel 1 at 10 ksamples/s with gain of 10’’ than have to write commands that send hex codes to a board’s registers. Drivers translate instrument-related commands that you understand into 1’s and 0’s that an instrument or board understands. Depending on how much translating you need and how much control you want, you may have several transitional layers of software between your application program and your instruments. The more layers you have, the higher the level of abstraction you’ll get and the more your commands will read like test and measurement actions rather than instrument commands.

The easiest instrument to understand from a software-layer perspective is a PC plug-in card. Typically, just two layers of software reside between an application program and a card. The "driver" that the manufacturer supplies with a card typically contains two files: an I/O library file and a device-driver file. The I/O library, usually supplied as a Windows’ dynamic-link library (DLL), contains functions that you call from your program. You should never have to send commands directly to the device driver that resides below the I/O library.

A function in an application program telling a digitizer board to take multiple samples from one channel might look like this (the function names vary among manufacturers):

daqAdcRdN(channel, bufferSize, scanCount, triggerSource, trigDirection, trigLevel, freq, gain)

Manufacturers of data-acquisition cards often claim that they have "drivers" that let you use their cards with specific programming languages, usually graphical languages. For graphical languages, most card manufacturers wrap their I/O library DLLs in graphical objects so you can send commands to the DLL through graphical code.

Unlike plug-in instrument cards, IEEE 488 instruments reside outside the PC and require an internal interface card. The interface card comes with its own driver containing an I/O library and device driver.

If you control IEEE 488 instruments, your software model probably resembles the one in Figure 3. You may have a layer that some people call an "instrument driver" that resides above your IEEE 488 interface card’s I/O library. An instrument driver supplied with an instrument translates commands such as DmmMeasure (DC_Volts,Reading) to function calls in the IEEE 488 interface card’s I/O library.

According to my definition of driver, an instrument driver isn’t a driver at all. It’s a collection of instrument-specific functions. So for clarity, I’ll define instrument drivers as "instrument libraries," a term that also applies to the graphical wrappers around PC plug-in card DLLs.

DmmMeasure(DC_Volts,Reading) into a statement such as gpibWrite(gpibAddress,command$). The instrument library might substitute a command string such as "MEAS:VOLT:DC? 10,0.003’’ for the variable command$. The instrument library would send a gpibRead command to the IEEE 488 interface card and would then retrieve the instrument’s data and store it in memory.

Instrument libraries bundle several SCPI commands into one function call. For example, you could set up a function generator with three SCPI commands such as:

FUNCTION SQUARE
FREQUENCY 1E6
VOLTAGE 1

With an instrument library, you can send all three commands in one line such as:

SourceSignal(address,SQUARE,1E6,1)

VXIbus instruments may have even more software layers than IEEE 488 instruments, if the system complies with VXIplug&play standards.1 A test system built before VXIplug&play-compatible software was available will have a driver model similar to IEEE 488 instruments. The instrument library in Figure 4 converts commands from the top-level application program into commands for the I/O library, which may be National Instrument’s NI-VXI, Hewlett-Packard’s Standard Instrument Control Library (SICL), or any other I/O library.

VXIplug&play standards introduce another layer (see Fig. 5) between the instrument library and the I/O library: virtual instrument software architecture (VISA). The VISA standard defines a fixed set of commands (such as viRead or viWrite) and a VISA DLL converts them to commands compatible with an I/O library. National Instruments, Hewlett-Packard, and other companies have developed their own versions of the VISA DLL. Each version works only with that company’s slot-0 controllers. The VISA standard also defines calls for IEEE 488 instruments. So, you can’t use one company’s version of VISA with an IEEE 488 controller from another company, either.

The VXIplug&play standards also define two different types of instrument libraries for textual and graphical languages. All VXIplug&play-compatible textual instrument libraries must come as a compiled DLL, but the instrument maker must also provide the source code as well. Instrument makers may also supply a graphical-language instrument library with source code so you can program within the graphical environment. Instrument makers and users may call these libraries "plug-and-play instrument drivers."

Paslay purchased the module because it used an interrupt for each of the module’s 8-bit ports. Unfortunately, the manufacturer’s instrument library wouldn’t give him access to those interrupts. So, Paslay wrote a register-based routine in HP VEE that communicated with the instrument using VEE’s direct I/O capability. He then had access to the interrupts, but he couldn’t perform data transfers fast enough for his application.

To decrease the delay in data transfers, Paslay wrote a function in C that he compiled into a DLL, and he calls the DLL from VEE. The C function communicates with SICL directly. To test each method for speed, he toggled a bit on one of the data ports and measured its pulse width. Using the register-based routine, Paslay couldn’t get a pulse shorter than 15 ms. With the C function communicating with SICL, Paslay reduced the pulse width to 3 ms.

Paslay’s exercise shows that while instrument libraries make programming easier, they don’t always give you access to every instrument function, nor do they always give you the performance you need. Programming with instrument libraries is analogous to writing programs in Basic as opposed to writing programs in assembly language. Assembly language gives you more control over the computer, but it increases the complexity of programming. For example, code that configures HP E1328A VXIbus analog-output module requires one line of code with its VXIplug&play-compatible instrument library. That same functionality requires six lines of code if your application program writes directly to the SICL I/O library.

Software layers provide a higher-level programming interface than you’d get if you had to control instruments at the device-driver level. Some engineers want not only simplicity in programming, but also compatibility in programming from one instrument to the next. For example, they want to replace IEEE 488 instruments from one manufacturer with those from another without changing their application program code. Although two oscilloscope makers may use the SCPI command set, the two scopes may require different programming to accomplish the same task. So, these engineers want to add another layer that provides a standard programming interface for several types of instruments.

The ActiveX technology encompasses several types of programming objects, one of which is the Component Object Model (COM). COM objects form programming interfaces for lower-level programs such as DLLs and can contain both the programming interface and the DLL in one object. Those who favor the COM objects claim the objects create a "contract" with the host programming language that specifies the functions of the COM object’s programming interface. So, when you change instruments, you substitute one instrument and its COM object instrument library for another that must have an identical programming interface.

With COM objects, you program an instrument by setting properties in its instrument library. For example, instead of making a function call like gpibWrite(address, "FREQency 1E6:FUNCtion SQUARE: VOLTage 1’’), you’d change properties. If you program with COM objects, your code might look this.

MySource.Frequency = 1E6 MySource.Function = SQUARE MySource.Voltage = 1

Or the instrument library could let you combine the three commands into one line of code such as:

MySource.Source(1E6, SQUARE, 1)

COM objects may also find a use in standardizing the control of data-acquisition boards. I mentioned earlier that I/O commands vary among manufacturers. An organization called the Open Data Acquisition Association (www.opendaq.org) has proposed a standard set of object properties to control data-acquisition cards. For more information, see "Will Data-Acquisition Standard Become a Reality This Time?" at Test & Measurement World Online, www.tmworld.com/articles/12_daq_standards.htm. T&MW