June 19, 1997

Taming the Universal Serial Bus

Richard A Quinnell, Technical Editor

Last year, the Universal Serial Bus was an untamed technology. Now, EDN's hands-on USB project gets the bus under control.

One problem with emerging technologies is the difficulty in determining when they're ready to be harnessed. When EDN first looked at the Universal Serial Bus (USB), it was still wild and unruly (Reference 1). The technology has since settled down, and we can now accurately evaluate its performance.

The USB aims to replace the plethora of back-panel peripheral connectors on the PC with one four-wire serial bus (see box, "USB basics"). The bus allows live insertion of devices, automatically configures the PC and the device upon attachment, and can provide the device with power through the attachment cable.

The intent of the USB design is to meet the attachment needs of common PC peripherals as well as emerging still-camera and computer-integrated-telephony equipment. The bus has potential for embedded systems as well. Its ability to automatically configure and power attached devices, for example, makes USB useful for adding nonintrusive diagnostic circuits to systems. A USB-based data-acquisition circuit can provide a test port in a system without consuming any of the target system's power, computational, or communication resources.

My purpose in this hands-on project was to examine the bus's operation from the embedded-system designer's viewpoint. In particular, I was interested in the bus's achievable data rates for a data-acquisition system. The bus operates at a top speed of 12 MHz, but you cannot use all of that bandwidth for data transfer. In addition to the bus-protocol overhead, the host's processing of data-transfer requests can cause system delays.

Data moves across the USB under the host system's control. With bulk-data transfer, the host initiates the transfer by sending a command that prepares the target device to either send or receive data (Figure 1). Once the data-transfer receipt is complete, the receiver sends an acknowledgment (ACK) token to the sender to indicate that the transfer was successful. After the transaction is complete, the host prepares the next data transfer.

Host delay is key

In addition to the overhead of addresses, CRC characters, and synchronization patterns, there are delays inherent in the USB protocol. The delays between parts of a transaction allow for signal propagation and reversal of bus-driver direction. These delays have upper limits that the USB specification imposes (Reference 2). Following a transaction, another delay allows the host system to determine and prepare for the next transaction. The specification does not limit host delay. It was this host delay that I wanted to investigate. My attempt last year to make such measurements ran into software problems.

USB's theoretical data rate comes from the following formula:

Transaction time (nsec)= 9107+(83.34·Floor(3.167+BitStuff·(512)))+Host_Delay,

which describes the duration of one bulk-data transfer of 64 bytes. The BitStuff factor is data-dependent. USB's NRZ-invert signaling scheme demands the insertion of a dummy zero bit after six successive data ones to permit reliable clock recovery. The worst-case factor for BitStuff is 1.1667 (1 stuff bit for every 6 data bits), but a value of 1.008 is a more likely average value.

The formula accounts for most of the delays in Figure 1, using the maximum values that the USB specification defines. The factor Host_Delay, however, is system-dependent. A minimum host delay allows the USB to handle bulk-data-transfer rates as high as 1.2 Mbytes/sec. The goal of this hands-on project was to see how close to ideal the bus really operates by estimating the host's delays.

Having a specific goal is only part of the exploration process. Like any expedition, my attempt to explore the USB needed the right equipment. My previous foray into the USB jungle proved that hardware and software must have compatible revision levels and work well together.

USB development

You can choose from a lot of development equipment (Table 1). A variety of USB microcontrollers are available, including some implemented in programmable logic, on which to base a design. Software-development and hardware-debugging tools also abound.

For this project, I elected to stay with the Intel 82930 USB microcontroller development board and Production Language Corp (PLC) Compass/251 software-de-velopment tool that I used in the first project. I stayed with these earlier choices mainly to avoid the learning curve for new equipment. I had to upgrade both of them, however, to capture the changes and improvements of the last eight months. The development board now used a daughtercard to update the USB processor to the latest version, the 82930AXD4. The onboard ROM monitor program had updated to version B2-2.1. As a result of these hardware changes, I had to upgrade the PLC software to version 3.07.

Host equipment has become more widely available since the last project. At that time, only two USB-enabled PC families were in production. By the beginning of 1997, however, more than 75% of new PCs carried USB ports and contained versions of Windows 95 that provided bus support. I picked a host based on who was first to volunteer a loaner PC, ending up with a Digital Equipment Venturis GL 6200.

The version of Windows 95 that comes preinstalled on new computer systems, version 4.000.950B, is part of Microsoft's OEM Service Release 2.1, code-named "Detroit." Although it contains USB support, this version does not have all the class drivers for devices such as keyboards and mice that later versions of Windows will offer. These drivers, as well as refinements to the USB host software, are available through Microsoft's developer's programs in prebeta versions of Windows 9x, code-named "Memphis." Atten- dees of the Windows Hardware Engineering Conference (WinHEC) received trial copies of Memphis.

Host-system software in flux

I chose to start this project using Detroit, the released and widely distributed version of Windows 95 that supports USB. Although missing many class drivers, Detroit's host-controller software is complete and functioning and works with USB devices that have their own device drivers. My project needed its own drivers anyway, so Detroit would work just as well as later versions and would represent what new bus users would have available for their own efforts. The next release version of Windows with USB support will not be available until 1998.

For test equipment, I chose to use the FuturePlus USB preprocessor and Hewlett-Packard 65500 logic analyzer. This combination of devices would allow me to monitor and interpret bus traffic. It also would provide detailed timing information, which I needed for my analysis.

The final items I would need for my project were the tools for developing the device drivers that would tell the host system how to communicate with my USB peripheral. Device drivers for Windows 95 are similar to drivers for Windows NT, and the driver-development tools run under Windows NT. Therefore, I needed a Windows NT system.

Creating a device driver for Windows NT requires several tools. Microsoft has a device-driver developer's kit (DDK) package that starts the process. The DDK helps you design drivers in C, but it doesn't generate executable code. For that you need a separate compiler, such as Microsoft's Visual C. You also need a debugger, such as the one that comes with the Win32 software developer's kit (Win32 SDK). An alternative debugger is the NuMega Technologies SoftIce, version 3.01.

My experiences with driver development during the last project convinced me that device-driver development was outside my skill set. My background is assembly-language programming of microcontrollers, not interacting with PC operating systems. Operating-system driver-software development requires a different skill set from that required for microcontroller-firmware design. Most embedded-system teams will find the same division in their engineers and should plan on having separate engineers for USB-driver and-firmware design.

To help me with driver development, I wanted a guide through the Windows NT driver labyrinth. Fortunately, such guides have become more available in the eight months since my last expedition. SystemSoft offers both training and consulting services aimed at USB developers and can provide custom-driver development. BlueWater Systems offers design tools that work with the Microsoft Windows NT DDK and have libraries dedicated to creating USB drivers. I chose to work with BlueWater Systems on this project because it was willing to send engineer Joshua Buergel to help develop the driver I needed. Intel engineer Sharma Upadhyayula also gave me extensive help with the 82930AX microcontroller firmware.

As I prepared to make this expedition into USB territory, the value of experienced guides became immediately obvious. I had planned to use as my starting point the USB loopback-test firmware that Intel posts on its Web site. Upadhyayula quickly informed me that this firmware needed an update and provided me with a new firmware so that the expedition started off in the right direction.

Rather than use Intel's sample loopback driver, I wanted a custom driver that would let me receive long strings of data from the microcontroller. Buergel quickly put together a driver and DOS-based test program that gave me control over the host's interactions with the evaluation board. The test software allowed me to read and write single 64-byte blocks of data, alternate read and write transactions in a loop, and read an unlimited amount of data from the evaluation board.

Our combined efforts quickly took me beyond the territory I had explored in my previous effort. In that first project, my evaluation board never completed the enumeration sequence. With my guides' help, I was able to see why. The host system executes an allowed, but unexpected, transaction sequence during enumeration.

Upon system initialization, or whenever a new USB device attaches to a running system, the host must query the device to obtain the device's description of itself. The USB host-controller software uses that description to find and load the appropriate device drivers. After obtaining the description, the host assigns an address to the device and reads the device's configuration data.

As implemented in my system, however, the host twice queries a device for its description. The first time, the host aborts the transaction after receiving only 8 bytes. The second time, it completes the enumeration sequence according to the specification.

The reason for the aborted first query is unclear, but the host always made the same two-step enumeration. Possibly, the host sends the first query merely to verify that the attached device will respond correctly before starting enumeration. The specification allows this operation; a USB device must be able to recover from aborted transactions. The aborted query is simply an extra step that the specification does not require. In my first project, my evaluation board did not react properly to the aborted transaction. The updated evaluation-board firmware worked per-fectly.

Batch operation kills bus speed

I performed several tests with my USB device. The first test consisted of running a batch program that repeatedly wrote a single 64-byte block and then read a single 64-byte block. The purpose of this test was to see how quickly a batch program could obtain data from a USB device when incurring the full overhead of the USB software chain (Figure 2). In this situation, my system took 110 to 140 msec to initiate each read or write. Thus, the software overhead of running in DOS batch mode had slowed the achievable data rate to only 450 bytes/sec.

To obtain data rates closer to the 1.2 Mbytes/sec theoretically possible on the USB, requests for multiple 64-byte transactions must come from lower in the software chain. By configuring the driver to request 6400-byte transfers from the host controller, I was able to run the experiment again at a speed limited only by the host controller.

Buergel set the driver to alternate read and write requests to the USB device until 6400 bytes had transferred each way. I expected the evaluation board to accept 64 bytes of data and then to load that data into its output buffer for transmission. Ideally, then, the system would alternately execute 100 read and 100 write transactions with only the host-system delay between transactions.

In practice, my USB device wasn't fast enough to sustain these repeated transactions. It would accept several 64-byte blocks before turning around and returning the first block. Then, it would return several blocks before accepting any more. The device's average data rate was 540 kbytes/sec.

The evaluation board's internal firmware, not the host system, set that limit, however. Measuring the delay between successive transactions gave me an estimate of the data rate the system could have achieved if the board had been able to keep up. The average value for Host_Delay was 4.76 µsec following a read transaction and 3.21 µsec following a write transaction. Those values translate into a sustained data rate of 1.088 Mbytes/sec.

To estimate the long-term average data rate that my test setup achieved, I ran a program that caused the driver to loop through its 6400-byte read-and-write transfer routine and display a count of completed loops. A run of 1000 loops (6.4 Mbytes read and 6.4 Mbytes written) required 23 sec to complete, an average data rate of 556 kbytes/sec.

Old system bug

While executing the extended loop test, the host system would occasionally lock up and need to be rebooted. Buergel explained that some of the early releases of the USB host-controller IC had this problem with long bulk transfers. Later hardware versions have corrected the problem, and the Memphis version of Windows 9x had a software fix for the problem. Developers planning to use the current release of Windows 95, however, should be aware that older host hardware may lock up with sustained bulk transfers.

My initial goal for this USB project was to see what data rates a data-acquisition system on the USB could achieve. To explore that question, Upadhyayula and I modified the loopback code of the USB evaluation board to make the board continually load its output buffers so that I could perform a sustained read from the board. As with the loopback test, the evaluation board's firmware limited the average data rate to 540 kbytes/sec.

I performed all of my tests on a system that was running only the USB test application. In practical applications, however, the host system may be running other programs or servicing keyboard and mouse entries, in addition to transferring data over the USB. The Host_Delay factor accounts for the times when the host is too busy to initiate the next USB transaction.

In a brief experiment, I ran the 6400-byte read-and-write program with the system quiet and with the mouse active. A single measurement of data rates showed a 1.088-Mbyte/sec rate on a quiet system, dipping to 960 kbytes/sec when the mouse was active.

1-Mbyte/sec transfer rate

The results of my experiments have several implications for embedded-system developers. The first is that USB is now ready for developers to begin work in earnest. The system software and version problems that derailed my first project are much more settled. Al-though the released version of Windows with USB support has some problems, the more robust prebeta version of Windows 9x is readily available for developers looking to create products that will work with the 1998 Windows release.

Development teams that expect to develop their own drivers will need to have expertise in Windows NT driver development. This expertise is not the same as Windows driver expertise; Windows NT uses a driver model different from Windows 3.1. Help is available to those who need it, however, in the form of advanced development tools and consulting services.

You should be able to readily attain bulk-transfer data rates of 1 Mbyte/sec in systems dedicated to the transaction. Designs should provide adequate buffering, however, for those times when the instantaneous data rate drops. Such drops result from the host system's internal activity or the occasional need to resend data because of system noise. Attempts to achieve a sustained data rate of 1.088 Mbytes/sec, as I measured in short bursts, should be made with caution. Achieving such data rates may require that the designer carefully control the host system's operation as well as the USB-device design.

Finally, be aware that, although the USB is settling down, it is far from a domestic animal. The updated host-system software is still in prebeta testing. Many published examples of USB software are out-of-date, and some are just plain wrong. Nonetheless, the USB is ready to begin taking its part in the PC architecture and can serve as a useful port for embedded-system designs.

References

1. Quinnell, Richard A, "USB: a neat package with a few loose ends," EDN, Oct 24, 1996, pg 38.

2. Universal Serial Bus Specification Version 1.0, Jan 19, 1996.

Acknowledgments

I would like to thank BlueWater Systems, Digital Equipment Corp, Hewlett-Packard, FuturePlus Systems, Intel, Logitech, Microsoft, and PLC for the generous loan of equipment, personnel, and expertise that made this article possible. Special thanks go to Joshua Buergel of BlueWater Systems, Sharma Upadhyayula of Intel, and Susan Shaw of the USB's Implementer's Forum for their time and talents.

| EDN Access | Feedback | Table of Contents |