Manufacturers of test-and-measurement equipment have long recognized the need to allow for automated testing. So, they usually build equipment with some type of I/O interface. The General-Purpose Interface Bus (GPIB) described in the IEEE-488 standard and RS-232 are two of the more common interfaces. But because today's computers work with the high-speed Universal Serial Bus (USB) 2.0, manufacturers and designers should consider USB as an alternative or additional I/O to the aging GPIB and RS-232 interfaces.
In manufacturing-test applications, USB's 480-Mbit/s data rate will cut test times. In an R&D environment, USB's ease of use will let engineers quickly construct a test system and characterize a design over frequency or temperature. This article presents an overview of USB benefits in automated test, possible ways to use USB to communicate with test-and-measurement equipment, and some USB design guidelines.
To understand the benefits of USB in automated test, consider how an automated test application is created. Two main tasks are involved: making the physical connection between the computer and the test equipment, and developing the test application software that executes on the computer.
The Physical Connection: To set up an automated test using GPIB, a GPIB host bus-adapter card and GPIB software drivers must be located and installed in the computer because GPIB isn't built into any standard PC. Fortunately, many manufacturers offer GPIB cards. However, they're expensive (costing $300 or more) and unavailable at the nearest consumer electronic store. This is also true for GPIB cables (about $100).
After purchasing and installing a GPIB host bus-adapter card and the necessary GPIB cables are in hand, the cables must be connected from the computer to the test equipment. GPIB cables are thick, containing 24 wires. Sometimes it's difficult to fit and maneuver them into tight spaces. After the cables are connected, GPIB addresses for the equipment must be manually configured. The GPIB addresses chosen must be unique and not conflict with the address of the GPIB card in the computer. A maximum of 15 devices can be installed in any GPIB topology, and typically achieved data rates are approximately 750 kbytes/s.
To set up an automated test using RS-232, the proper RS-232 cables must be located, which is usually easier than finding GPIB cables, although many types exist. If an RS-232 test system doesn't work, many first try a different cable. In cases where that doesn't work, many try to change RS-232 parameters, like baud rate, parity, start/stop bits, flow control, and so on. There are too many variables, which leads to frustration.
The good news is that RS-232 is built into computers, eliminating the need for host bus-adapter installation. Yet, it limits the number of available RS-232 ports to two. Because RS-232 is strictly point-to-point (with no ability to daisy-chain from device-to-device), two RS-232 ports means that only two devices can be connected. If more than two RS-232 ports are necessary, multiport RS-232 host bus adapters must be used. Due to baud-rate limitations, typical data rates with RS-232 are much slower than GPIB.
Compared to GPIB and RS-232, making the physical connection at the computer end with USB is a snap. Hundreds of millions of computers have been shipped with USB hardware over the last several years. "Universal" in the USB name is certainly appropriate. Most USB-equipped computers offer at least two USB ports. Soon, this will grow due to Intel's 845G chip set, which handles six high-speed 480-Mbit/s ports.
Each USB port is a "root port" and supports a topology (if external hubs are added) of up to 127 devices. So USB will enable new kinds of test systems, with many more instruments connected to one computer. USB hubs are readily available (about $25) and don't introduce significant delays.
With USB, making the physical connection to the test equipment also is simple, whether or not it has a USB interface. When test equipment lacks a USB interface, a converter is required. For example, if test equipment has a GPIB interface, several companies now provide USB-to-GPIB converters. These converters typically contain a general-purpose USB chip, firmware, and GPIB hardware. They convert a protocol on the USB side into the necessary signaling on the GPIB side (Fig. 1).
The benefit of employing a USB-to-GPIB converter is that an expensive GPIB host bus-adapter card no longer needs to be installed to communicate with the GPIB test equipment. Moreover, applications written for GPIB don't even have to change, as the converter can be made to appear like a GPIB host bus-adapter card. USB-to-GPIB converters also eliminate a GPIB cable because they can plug directly into the GPIB interface on the test equipment. Using such a converter may be the only solution when no expansion slots are available on the computer.
Also, if several engineers occasionally need to run an automated test, it's much easier to share a USB-to-GPIB converter with others than to share a GPIB card. When transferring large amounts of data, the performance of even 12-Mbit/s full-speed USB-to-GPIB converters matches the 25-year-old GPIB's performance. But if the test application has a critical need to perform many short transfers, such as writing to an electronic switch, then the performance of USB-to-GPIB converters may affect the overall test time. To optimize short-transfer performance, connect the USB-to-GPIB converter to a high-speed USB port.
If the test equipment has an RS-232 interface, several companies offer USB-to-RS-232 converters. The operating system (OS) sees them as extra COM ports.
Test equipment with a USB interface just needs a USB cable (about $10) from a USB port on the computer to the test equipment. Cables are readily available at consumer electronics stores. Because USB is plug-and-play, there are no concerns about setting up unique addresses, which the OS assigns.
After making all of the USB connections, but before turning everything on, software should be installed on the computer. This is true for any USB device not natively supported by the OS because USB is plug-and-play and the OS automatically detects when a new device is added to the topology. The OS enumerates the newly attached device, reading the device descriptor, configuration descriptor, interface descriptor, and endpoint descriptors. Then it tries to find the most suitable driver.
In cases where software hasn't been installed, a suitable driver won't be found and the OS will give up. It may display a dialog box to the user. At this point, some users might not know what to do, so it's best to install software first.
For test-and-measurement equipment, this means installing I/O library software, which sets up files so that the OS can associate the correct driver with the USB device. I/O libraries also make it possible to write test applications that communicate over USB.
Developing The Test Application: Typically, a test application is developed using I/O library software that implements the Virtual Instrument Software Architecture (VISA) standard. Already, VISA supports GPIB, RS-232, and other interfaces. Test-and-measurement companies are currently working together to add VISA support for USB. This effort builds on the effort of another group working within the USB Implementers Forum (USB-IF) Device Working Group (DWG) to create a USB test-and-measurement class specification. Developing a new USB device class specification was necessary due to the unique needs of test-and-measurement devices.
One requirement is mapping out-of-band GPIB messages, such as clear, trigger, srq, and remote/local to USB. Another is defining how interrupts get communicated from the device to the computer. The USB test-and-measurement class (USBTMC) specification defines what USB endpoints a device needs, the way to send program messages, and how response messages are read. See www.usb.org for the most current information on the specification and the USB488 subclass specification. The site is sponsored by the USB Implementers Forum Inc., creators of the USB technology.
Addressing the communication requirements of a broad range of test-and-measurement devices—from simple sensors to mainframes with multiple measurement functions—is the USBTMC specification's goal. The USB488 subclass specification addresses the need to move the GPIB communication model to the USB. Figure 2 shows the communication paths (USB pipes) between a host computer and a USB488 implementation.
The group working on the next version of the VISA standard will define syntax for obtaining a handle on a USB test-and-measurement device (using the VISA viOpen() API), as well as specific attributes for USB devices. Once a handle is obtained, VISA applications can write to the device and read from it just as any other VISA supported interface.
Switching an application from a voltmeter with a GPIB interface to a voltmeter with a USB interface will only require changing the viOpen() syntax and recompiling. The USB-IF DWG and VISA standards efforts enable I/O library software to handle USB test equipment from multiple vendors—just as one I/O library handles GPIB and RS-232 test equipment from multiple vendors in the same test system.
Designing In USB: To begin designing USB into test-and-measurement equipment, the following questions immediately arise:
- Should the design be low-speed (1.5 Mbits/s), full-speed (12 Mbits/s), or high-speed (480 Mbits/s)?
- What other factors should one consider when choosing USB device silicon?
The speed should be full- or high-speed, not low-speed. According to the USB 2.0 specification, the low-speed mode is defined to support a limited number of low-bandwidth devices, such as mice, because more general use would degrade bus utilization.
Full-speed may seem like an obvious choice, given that most computers today support full- and not high-speed. But remember that USB 2.0 is designed to be fully backward compatible with USB 1.1. USB 2.0 handles low-, full-, and high-speed communications. So a high-speed device will work when connected to a USB 1.1 full-speed-only computer. It will simply operate at full- rather than high-speed. Plus, a high-speed USB 2.0 computer will communicate at full-speed to a full-speed device.
Also keep in mind that high-speed USB 2.0 support on PCs should grow rapidly. PC manufacturers already use the Intel 845G chip set on motherboards. It also is easy to upgrade an existing computer with high-speed USB 2.0 by purchasing a USB 2.0 host bus-adapter card (about $50). The choice of full- or high-speed shouldn't be based on compatibility, but rather on the data rates required by applications.
For large transfers, full-speed implementations realistically provide about a 1-Mbyte/s transfer rate. High-speed implementations will offer anywhere from 6 to 40 Mbytes/s, depending on the device's architecture and firmware—and the USB software on the computer. Data will burst at 480 Mbits/s (60 Mbytes/s), but sustained data rates are lower due to USB, computer software, and device overhead. After picking full- or high-speed, the choice of USB device silicon still depends on several other criteria:
- Device class: Some USB silicon is built for specific device classes. For example, a USB chip may be targeted to mass-storage devices, and therefore be optimized for the mass-storage device class. Others are general-purpose. Firmware can determine the device class that gets reported to the OS when the device is enumerated. To implement USBTMC specification, use a general-purpose chip. No matter the device class to be implemented, consult the class specification to understand any extra requirements or opportunities for optimization.
- Number of endpoints: Most general-purpose USB chips supply the required control endpoint and two or more configurable endpoints. Firmware configures the endpoints to be bulk, interrupt, or isochronous. USBTMC requires three endpoints (Control, Bulk-OUT, Bulk-IN). A fourth endpoint (interrupt-IN) is necessary for the device to communicate interrupt conditions (similar to GPIB service requests) when measurement results are ready, or when an error occurs. Most USB silicon will run with at least this number of endpoints.
- Amount of endpoint FIFO memory: When the computer sends data to the device, the data is stored in Bulk-OUT endpoint FIFO memory until device firmware reads it. While the computer reads data from a device, the data is read from Bulk-IN endpoint FIFO memory. The more FIFO memory provided, the more efficient the data flow.
- Endpoint FIFO memory access method: Some USB silicon will provide both programmed I/O and DMA (direct memory access) methods. DMA relieves the device processor from moving all bytes, so it can perform other tasks. The most efficient designs will DMA multiple bytes at a time.
- On-the-go (OTG) support: The new OTG USB specification lets a device temporarily act as a USB host. This is a great idea for many applications, like a USB digital camera sending pictures directly to a USB printer. Test-and-measurement equipment frequently produces images. It would be nice to send them directly to a printer. But OTG silicon and the necessary OTG software infrastructure must mature in the consumer market before adoption by OTG in test-and-measurement equipment, which frequently requires support for a long time.
Another design decision involves how users will connect the device. A USB device can be designed to use a captive cable, a standard-B plug, a mini-B plug, or an alternative plug (Fig. 3).
In a captive cable design, the cable is an integral part of the device. USB mice and keyboards are designed this way. The free and unattached end of the cable has a standard-A connector plugged directly into the computer USB port. One disadvantage of a captive cable design is that an assumption must be made about the optimal cable length.
Many devices use the original standard-B plug. The benefit to standard-B is that most cables today use standard-B. Size is the disadvantage.
The mini-B connector and plug were created to meet the needs of small portable devices. Therefore, it has a much smaller footprint. Also, mini-B is specified to last through 5000 insert/remove cycles, while the standard-B is specified at only 1500.
An alternative plug is the last option to consider. This makes sense if the USB device will be used in a harsh environment and must withstand vibration and shock, or if it's important to prevent accidental disconnect of the device. Alternative plugs can provide latching capability. Any device with an alternate plug should be shipped with a suitable cable.
Because USB provides power on the bus, a choice must be made whether a product will be self-powered or bus-powered. Of course, there's a limited amount of bus power available. Typically, only smaller, portable, less complex test equipment could be bus-powered.
Finally, every device requires a 16-bit vendor identification and 16-bit product identification. The USB-IF currently supports two options for getting the vendor identification (see www.usb.org). The vendor manages the product ID values.
The bottom line is that supplying USB as an additional or alternative I/O on test-and-measurement equipment will give test engineers an easier and faster path to measurement results. USB is simpler to use because it's pervasive, and cables, hubs, and converters are readily available. Plus, USB is faster than other interfaces thanks to the 480-Mbit/s speed supported in USB 2.0—which is ready now. Also, most computer users have now gone through the experience of connecting a USB peripheral of some kind. The experience with test-and-measurement equipment shouldn't be any different.