When embedded systems need to handle high-speed analog signals, employing a data-acquisition module can save considerable design effort. Vendors of such modules are increasingly turning to the Universal Serial Bus (USB) as their interface. It offers a combination of high performance and application simplicity that helps minimize the integration effort when adding data acquisition to an embedded design.
USB offers several advantages over other standard buses for connecting a data-acquisition module. One is simplicity; USB requires only four wires while parallel buses typically require 20 or more. This low wire count also provides flexibility in module placement. Devices on the USB can be located as far as 5 m from the controller or hub to which it's attached and can receive its power through the interface (see the box "USB basics"). The use of cascaded hubs can increase the separation even further.
|
USB basics Originally conceived as a replacement for the multitude of cables that connect a PC to its external peripherals, USB offers a flexible connection scheme that can support up to 127 devices. Architecturally, the USB is a master-slave structure with a host controller on the PC acting as the bus master and initiating all communications over the bus. During power-up, or upon connection of a device to the bus, the host controller enumerates the devices on the bus, assigning physical addresses to each of the ports and allocating bandwidth among the devices. Physically, the USB offers a tiered-star architecture. Devices on the bus connect either directly to the host controller's root hub or to a secondary hub controller, using one port per connection. Hub controllers serve as fan-out points for the bus and connect to the host's root or to a secondary hub, just like peripherals. The bus supports as many as five hub-to-hub tiers between the most remote peripheral and the host controller. The bus itself is a four-wire connection with a maximum length of 5 m. Two wires form a half-duplex differential pair for signaling. The other two wires supply power and ground to devices that don't have their own power source. The USB can source up to 500 mA at 5 V (nominal). Logically, each USB peripheral enjoys a one-to-one link between endpoints on the device and applications software. The driver software and the host, hub, and peripheral-controller hardware handle the complexity of translating between a software call to a peripheral endpoint and the physical addressing and communications protocols. The application software simply moves data to or from the endpoints on the peripheral without needing to know the connection details. To support various of data-handling needs, the USB offers four types of data transfers: bulk, interrupt, isochronous, and control. The host interleaves these various types of transfers within a repeating time interval called a frame. The exact allocation of bandwidth among the transfer types within a frame depends on the system configuration and is set by the host controller during device enumeration. At the very least, once per frame, the host sends a control transfer requesting status to each bus device and reserves enough bandwidth for devices to respond with an interrupt transfer if needed. Isochronous transfers, when allocated, receive a fixed portion of each frame (up to 90%) for data streaming. Bulk transfers occur during any otherwise unallocated time in a frame. The speed of the USB depends on the peripheral's functionality. Devices conforming to the original USB 1.1 have two signaling speeds: low speed at 1.5 Mbits/s and full speed at 12 Mbits/s. Devices conforming to USB 2.0 can also offer a high speed (480 Mbit/s). |
This separation carries an additional advantage—higher accuracy. Because the data-acquisition module doesn't need close proximity to the main CPU, the module is less susceptible to interference. Modules tied to a parallel bus often pick up switching noise from the bus, which can be difficult to protect against, as well as receiving noise from other system components.
Bus noise on the USB is minimal because it uses low-noise differential signaling. In addition, a module on the USB can be provided with considerable isolation from system noise both through physical separation and protective circuitry. At the same time, the module can be located nearer to the signal source, minimizing the pickup of noise in the wiring between the sensor and the module.
Performance is another advantage of USB. Version 2.0 of the standard allows data rates as high as 480 Mbits/s, much faster than RS-232 and other common serial standards and comparable to most parallel buses. The host controller automatically handles bandwidth allocation among multiple devices sharing the bus, ensuring that devices will utilize the bandwidth efficiently. Modules currently available achieve performance rates as great as 2 Msamples/s on two simultaneous channels and 250 ksamples/s on 12 channels.
The accuracy and bandwidth of these analog channels has been steadily increasing, with 16-bit converters becoming common and resolutions as high as 22 bits becoming available. In addition, analog-to-digital converters (ADCs) have dropped significantly in price, allowing the data-acquisition modules to offer one converter/channel rather than multiplexing a series of sample-and-hold circuits. This one-to-one mapping allows modules to offer simultaneous sampling of all channels, preserving phase relationships.
Multifunction modules handle all I/O
The modules need not only be data-acquisition elements. Multipurpose modules (like the one shown in Figure 1) can provide all of an embedded system's analog and digital I/O in one unit. Such modules have ADCs, DACs, and digital I/O all together, each separately controllable as unique logical endpoints. The USB's performance is great enough that all of these channels can operate at speeds of several hundred kilohertz simultaneously.
Using the USB for data acquisition is not without its challenges, however. Embedded system developers need to take care when using modules that receive their power over the bus. Developers will also need to consider the isolation needs of their installation. If the embedded system doesn't use a Windows-based operating system, driver software can also be an issue for developers to address.
The challenge of powering the data-acquisition module over the USB has two components: voltage and current. The voltage issue arises as a result of the cabling between the host and the module, and is aggravated by the use of intervening hubs. As shown in Figure 2, the voltage supplied by the host controller can be as low as 4.75 V and still be within specifications. Each connector and cable segment adds resistance, making the nominal voltage at the bus-powered hub as low as 4.5 V, and the effective voltage at a downstream device as low as 4.35 V. An embedded system using a USB-based data-acquisition module must account for these allowed voltage drops. The voltage changes in the ground reference may also cause a problem if the data-acquisition module uses single-ended analog signals.
The current component of the power challenge comes from the specification's power-up restrictions. While the root hub can source as much as 500 mA to downstream devices, these devices can't draw more than 100 mA total during the enumeration phase. This limitation gives the host controller an opportunity to identify the potential for excessive demand and disable devices that would cause the system to exceed the 500 mA limits before they attempt to draw that power. Thus, the module and support circuitry will need to offer a two-stage power-up sequence.
It should also be noted that the use of an intervening hub between the host and the module reduces the power available to the module. The hub itself will need power, and that can be drawn from the 500 mA that the root controller sources. Downstream devices will thus only be able to receive 400 mA from a bus-powered hub.
Isolation protects hardware, performance
Isolation of the data-acquisition module is another challenge that designers face. Many modules offer isolation on their signal I/O lines, but USB isolation may not be as common. External isolation of both the signal and power lines of the bus from the module may be needed. This isolation has two purposes. One is to protect the host system from damage by external signals, such as lightning-induced transients. The other purpose is to eliminate the possibility of ground loops in single-ended analog signals that might otherwise contribute significant errors to the signal measurement.
Software may also be a challenge when using USB-based data-acquisition modules in an embedded system, especially if the design uses a non-Windows OS. USB was originally created for use in a Windows-based PC. Much of the bus' ease-of-use as well as its plug-and-play operation depend on the host-controller software as well as the module-specific device drivers that the OS loads during device enumeration.
This software dependence isn't a major concern when the embedded OS is Windows or one of its derivatives. These OSs already offer robust USB host-controller software and the device drivers that vendors supply with their modules always target Windows. The challenge comes when the design uses a different OS.
The degree of challenge that software represents depends on what's available from the module and OS vendors. Large OSs, such as Linux, may also offer robust host controllers, but smaller embedded OSs often don't. If the preferred OS doesn't come with USB support, designers will have to acquire or create their own controller software.
A software challenge for embedded operating systems
Creating host-controller software can be a significant effort requiring considerable USB expertise. An improperly designed host-controller routine can seriously limit bandwidth utilization on the bus by adding excessive overhead. Further, the embedded controller may create problems during final integration if developers created and initially tested the device drivers and applications software on a PC before porting it to the embedded design. Even minor deviations from the USB host-controller spec can produce undesirable module behavior in the final system.
Even if the embedded OS already offers USB support, developers will probably need to create device drivers to go with their system OS. Support for embedded systems among USB data-acquisition module vendors is orders of magnitude less than support for user OSs. Typically, vendors offer only registration maps for their modules, identifying the internal addressing of module resources, and example programs of bare-bones drivers. System developers can use these as a starting point, but may be in for an intense development effort to generate an effective driver. Because the driver works in conjunction with the host software to allocate bus bandwidth, weaknesses in the driver can severely reduce a module's in-system performance.
Despite these challenges, however, embedded data acquisition over the USB is growing in popularity. The ability to plug in hot-swap modules, power them over the bus, and place them at a distance from the host system are compelling advantages for many applications. While software development may be an issue, it only needs to be faced once for each module's device driver and once for each OS. Once the host controller and device drivers are created, they can be re-used in other designs, bringing the benefits of USB-based data acquisition to new generations of design.
Richard A. Quinnell is a contributor to many publications, including EDN, Test and Measurement World, and EE Product News. He has covered electronic technology for more than 15 years, drawing on his experience as an embedded system designer for nearly as long. He can be reached at [email protected].
