Instrument Systems: Drivers Needed

Engineers take it for granted that add-in instrument and I/O boards for a PC will come with driver software—the instructions that link an application to specific board-control operations. Even stand-alone instruments that furnish Ethernet, USB, or other connections also come with drivers. In effect, drivers isolate application programs from the details of how a PC controls an instrument.

Prior to the availability of drivers, users often had to wade through manuals and then code low-level I/O operations in C, or another language, to let a computer and an instrument communicate. The resulting code transferred individual bytes of data to and from I/O ports, established configuration states, set up buffers for incoming and outgoing data, and so on. This sort of low-level code required many hours to debug and test. In contrast, today's drivers provide libraries of high-level functions users can call from within an application to manage instruments and other devices. Consider a simple command:

AnalogIn(BoardNum, Channel, Range, DataValue)

This line of code calls a function that reads an analog value from a specified channel on an analog-to-digital converter (ADC) board. The command sets the input range for a selected ADC channel and moves the analog signal's value to a location named DataValue. A driver library may contain dozens of such calls that perform a variety of operations.

Engineers who plan to program in a specific language should first seek drivers native to that language. Thus, if you want to buy a digital multimeter (DMM) add-in board for a PC, and you plan to program in C or C++, look for drivers written specifically for those languages. Most instrument suppliers will offer drivers for popular programming languages such as C, C++, Visual Basic, LabVIEW, and a few others. But if you plan to write an application using PASCAL or FORTRAN, you may have to search the web for third parties, such as universities and independent developers that offer specialized drivers. (National Instruments supports an Instrument Driver Network that lists over 2,200 drivers for products from over 150 vendors—see www.ni.com/idnet.)

In some cases, users face a situation in which they'll program using, say, Visual Basic (VB), but drivers for the instruments they plan to use exist only for C/C++ programs. The use of such non-native drivers can cause problems because VB, for example, can require extra programming effort—and testing—to get it to work with non-native drivers written for C/C++ code. Still, using a non-native driver takes less work than writing a driver from scratch.

The incompatibilities arise because languages use different means to call functions, pass data, and perform other operations. A C driver may operate as a dynamic linked library (DLL), but a Visual Basic driver usually must conform to Microsoft's component object model (COM).

Thankfully, equipment suppliers and third parties have recognized the need to let drivers written for one programming language work with several non-native languages. Developers may find a C/C++ driver in a software "wrapper" that lets it easily work in a VB application program (see above image). For all intents and purposes, the VB program "sees" a native VB driver for a particular instrument. A wrapper lets a vendor maintain the same underlying driver code for several programming languages. But wrappers have a limit: they prevent users from accessing all the low-level functions available in the encased native driver.

Wrap it up:  A software wrapper lets a driver written for one language operate with an application written in another language. Unfortunately, using a wrapper blocks an application from accessing a driver's low-level function calls.

Wrapped in a NET

Lately, the driver picture has gotten cloudy, due to Microsoft's introduction of the .NET (dot-net) software architecture. The .NET "programming environment" relies on what Microsoft calls managed code, which runs on a computer under Microsoft's Common Language Run-time execution engine. This engine provides layers of security and it lets programs written in languages such as Visual Basic .NET and Visual C++ .NET share drivers written using managed code. Unfortunately, the .NET managed code does not communicate easily with older drivers written in what Microsoft now calls "unmanaged code." So for now, suppliers furnish drivers with .NET wrappers that allow their use with .NET software. According to one source, developing native .NET drivers takes much work, so users shouldn't expect to see native .NET drivers soon.

Some equipment suppliers offer the source code for their drivers, so programmers who want to can delve into specific instrument-control tasks at the lowest level. But who needs to "get under the hood" this way? If a manufacturer discontinues a product, access to the source code for the product's driver may help users adapt the old driver to a new product. In some cases, it can take less time to rewrite the innards of a driver and leave the function calls as they were than to develop a completely new driver.

Making a driver's source code available also will let a programmer modify operations or measurements, because a vendor's driver may not control every feature its instrument provides. As with any programming project, though, programmers who modify driversmust carefully document their work so others will understand what the driver changes do and what they affect.

Thanks Microsoft: Managed code written in a Microsoft.Net language may have difficulty working with drivers written for earlier, unmanaged code. To ease this problem, instrument providers offer special.NET wrappers for older, but useful, drivers.

Order, Order

To bring some order to the area of drivers as they relate to high-end test-and-measurement markets, instrumentation vendors founded the Interchangeable Virtual Instruments Foundation (www.ivifoundation.org) in 1998. This group comprises 30 members, and it has defined an architecture for drivers that lets users easily change instruments without requiring changes in application software. Thus, if an older oscilloscope dies, people who maintain the test system can substitute a newer scope and have it perform the same functions as the older instrument, all without modifying the original test software. That's the theory, at least, but some driver compatibility issues still exist (see a related Test & Measurement World article at http://rbi.ims.ca/3844-545).

The IVI Foundation's initial specification now covers eight instrument classes, which include digital multimeters, oscilloscopes, and function generators.

The IVI spec applies across many types of instruments, and IVI drivers come in two flavors—C drivers written in ANSI C and distributed as DLLs, and COM drivers.

The IVI drivers work with the Virtual Instrument Software Architecture (VISA), which helps ensure compatibility between similar instruments, regardless of the bus they use; IEEE-488.2, USB, Ethernet, PCI, and so on.