Return to Design Topics Menu Page
Spread Spectrum Scene 
  Universal Serial Bus (USB) Information, Page 2
  Home || Navigation Help || Sign our Guestbook || Leave a Comment

This page continues our coverage of information on the astonishingly useful Universal Serial Bus, which provides connectivity between an array of electronic devices. On this page, we provide more basic information on USBs, links to related topics on SSS Online, and a search feature.

Contents of USB page 1

"An Overview of the USB, Part I"
Some Useful USB Links
Reference Books on USB

Contents of USB Page 2 (This Page)

"An Overview of the USB, Part II"
Explore SSS Online
Search This Site or the Web

An Overview of the Universal Serial Bus (USB), Part 2
-- by Danny Simpson, Pegasus Technologies

Editor's Note:This article was originally published in SSS Online's March 2001 issue.

The USB Seal

In Part I, we reviewed the history of USB, going over some of the communication advantages of USB over RS-232, and then touching on the various USB data transfer protocols. USB is a somewhat complex communications protocol but like many things, if you take it one step at a time, it can be digested. In this issue, we will recap some of the basics as well as get into more of the details involving the Windows drivers and their requirements. Also, we will go over some of the capabilities, shortcomings, and limitations of USB. Again, we are covering here the USB 1.x spec dealing with the low speed 1.5Mbps and high speed 12Mbps transfer rates. USB 2.0 devices (480Mbps rates) are not expected to have support from Windows until late 2001.

USB came into existence because of the need for interfacing a number of relatively fast peripherals to host systems such as a personal computers. Many peripherals must be installed inside the computer. In the past, just about the only way to add a new device to a computer was to turn off the power, remove the cover from the computer, find an empty PCI or ISA slot in which to install a 'printed circuit card', install the new card, replace the computer cover, turn the power back on, get the computer to install the driver(s) for the card, and hope that the computer system still works properly after your efforts. Many of today's computer systems only have 2 or 3 'spare' slots for new PC cards which can be a big limitation for some folks. Also, with PCI bus, there are limitations where some PC card slots share interrupts, and some card slots cannot be used with a PCI bus mastering card installed in them. As many PCI cards these days do have bus mastering built into them, these cards often will not work in those particular card slots. Theoretically, with USB you can install up to 127 different devices per USB port. Most PCs have 2 USB ports yielding up to 254 devices connected to a single PC! In reality, it can get a little sloppy on your desktop with this many USB devices, cables, and the hubs taking up room. Also, if you try this route you are probably going to run up against USB bandwidth limitations ...

A USB industrial touchpad module fromCirque Manufacturing

You cannot connect two computers directly together for communications purposes using a USB connection. However, you can hook two computers together using a peripheral called a USB bridge, also known as a USB to USB adapter. USB is not intended to be used like a LAN, so if you need to connect up two or more PCs together, you need to use Ethernet or something equivalent. If you need to connect USB devices to a host farther away than the maximum cable length of 3 meters for low speed (1.5Mbps) USB or 5 meters for high speed (12Mbps) USB, you will need to use hubs to extend the connection distance up to a maximum of 25 meters (5 hubs maximum, with 5meter cables between each hub).

When a device is added to a USB port, Windows on the PC side recognizes the connection and adds the proper previously installed driver to support the device. Many hardware devices that are plugged into the PC's USB port need to have a specialized driver written to support the device. Also, in some cases, specialized software applications will need to be supplied with the device to make it functional on the PC.

USB Driver Development

There are at least a couple of ways to get drivers that Windows can use for communications with a USB device: you can 'roll your own,'or you can make use of a set of USB drivers that the newer versions of Windows have included either on the Windows CD or that are available from resources such as those included in the Win DDK. Device descriptors inside each USB device contain information that Windows needs to know about the device before it can be used. Descriptors for a minimal device are mentioned below.

Windows Supplied Drivers

There is a set of drivers included in the newer versions of Windows that support certain devices called 'human interface devices' or HIDs. These devices include keyboards, mice, game controls, remote controls, and joysticks. In general, these devices don't require a great deal of data to be transferred to or from the host computer. The firmware inside these peripheral devices must support the Windows HID protocol if you want to use the existing HID drivers. The data that is transferred to and from these devices to the computer are called reports. Using HID, transactions can contain up to 64 bytes of data per transfer in high speed mode and 8 bytes of data in low speed mode using the HID drivers. Maximum speed of data transfer is also limited. A high speed device can only transfer 64K bytes per millisecond and a low speed device can only transfer 800 bytes per 10 milliseconds. Also, HID uses the control and interrupt pipes for data transfers (see our first article on USB for a discussion of this topic) which the USB protocol defines. As a result, HIDdoes not guarantee timely data transfer. If you need data to be delivered at a certain critical time, HID is probably not the way to go. As usual, the computer is the host and initiates all transfers. Even with these limitations, if you only require low volume data transfers, you can save a bit of time by using the Window HID-supplied drivers instead of writing your own software drivers.

A fairly rigid protocol must be adhered to when using the HID drivers with your device. Windows needs to determine which driver to load into memory to support a particular device that has been inserted into the USB port. It does this by issuing what is called a Get_Descriptor command to the device. What is returned to the PC host from the device is a block of information that tells the PC certain facts regarding its operation such as what class the device is, the number of logical interfaces it has, the size of its endpoints (data buffers), the vendor ID, product ID, and possibly serial number information. It is the class information that determines whether Windows can use its existing HID drivers.

After the Windows device drivers have been installed and the devices are connected to the host's USB port, Windows uses the Windows Device Manager to determine which USB driver to use with which device. It makes this decision based on a user-supplied .INF file that contains information such as manufacturer and product data, if the device is a non-HID device. If it is a HID device, it will use the .INF file named hiddev.inf for information on the device. This file also contains information that will be added to the registry once the device has initially been installed in Windows. Windows then uses data from all the .INF files (located in the \Windows\INF directory which is normally hidden) to catalog the data into two files named drvdata.bin and drvidx.bin for quick access to the proper .INF files to retrieve data for a particular device. If you do change the data inside an .INF file, you must go through a specific procedure to get Windows to change the entry for the device in the registry by using the Device Manager or else the changes will not be made when you expected them to. An .INF file has a format similar to the familiar .INI file.

User Supplied Drivers

If you cannot live with the limitations that the Windows HID driver imposes on you, you will need to write your own Windows drivers to communicate with your USB device. This can get quite involved and you may need to have access to several additional tools.

As discussed in the previous article, you will need to determine your devices' data transfer requirements -- such as which data transfer formats that you require for its use. You can have one or more of these data transfer formats identified in your device. Control mode is needed as a minimum for all USB devices for the query and setup of your device with Windows. If any of the following modes are required, Control mode also needs to be included. If data accuracy is important, you will need to use bulk mode, but you will need to give up guaranteed timing of data delivery as USB tends to give bulk mode its lowest priority. Bulk mode transfer is only available in high speed mode and includes error checking. If guaranteed timing of data delivery is more important than data accuracy, then you need to use isochronous mode of transfer. Isochronous mode transfer is also only available in high speed mode. You need to sacrifice one primary need for the other in these cases, i.e., transfer rate verses accuracy. If you need to be 'serviced' from the host at irregular intervals, you can use interrupt mode where the host will query you at regular intervals to see if you have an 'interrupt' pending to the host. You cannot interrupt a host in the usual sense, as it needs to ask you if you have anything pending. The host initiates almost all transfers except for remote wakeup.

Windows drivers typically 'isolate' applications from the details of the physical and logical aspects of the data transfer protocols. Much of the handshaking used is not seen by the application program, and neither is the structure of the packets and error checking. Drivers are seen as 'layered' between the hardware and the application program. You can use existing Windows drivers and write a mini-driver which adds to the capabilities of the existing driver. There is also a generic driver that is available called bulkusb.sys that can be used as a starting point for performing bulk mode transfers. Windows allows drivers greater privilege than applications programs by letting them have unrestricted access to system resources using IRPs (I/O request packets) to communicate with the lower level Windows USB drivers. Applications, which use the Win API to communicate with Windows, run in user mode while the drivers can run in kernel mode.

Communication Modes

There is a strict structure when using USB as a communications medium. After a device has been detected by the host, its device descriptors have been read, and it has been enumerated and assigned a handle by Windows, then an adherence to the set mode of communication mode must be kept. The control mode is the initial point of contact between the host and the connected device. Control mode in addition may be used for very limited user data volume between the host and the device. It is here where the host determines the device's setup such as communications modes, IDs, and general configuration. Control mode is the most complex mode of the four communication modes and has quite a bit of overhead on top the actual data transfers. There are many packets of data initiated by the host in this mode to the device and also packets of data are sent back by the device in response to the host. There are also several stages of communication such as Setup, Data, and Status stages, all which are structured. There are a total of eleven different USB standard requests in control mode where the host can set or get various parameters from the device. The USB standard also allows vendors to define their own additional requests in addition to the eleven provided.

The other three communication modes are generally used for user data transfer between the host and the host's connected devices. The basic 'gives' and 'takes' between these different modes has already been discussed above. Obviously, if you are using a custom Windows driver to communicate with a device, the device's firmware must be written to support the communication modes of the driver. It is imperative that good documentation be kept to document the different communication modes or the software and firmware development could get pretty 'outta whack' especially when working in a larger team project. The USB bus drivers that come with Windows are based on the WDM (Win32) drivers, and drivers written for your device should also be written based on the same WDM model. Remember, there are 'layers' of these drivers communicating with each other as well as the 'top' layer driver communicating with the application and the 'bottom' layer driver communicating with the USB hardware itself. Each driver has a limited set of tasks that it performs in conjunction with other drivers that also have assigned tasks.

Also remember that hubs need to be involved in the communication chain. They also have their internal firmware 'smarts' to make various decisions such as when to disconnect a downstream device that is not behaving properly. There is a hub driver within Windows that is used in the above-mentioned 'layers' that does the direct communication with the downstream hubs and also handles the enumeration. The USB bus-class driver assumes the responsibility of hub driver and the host-controller driver. It is this host-controller driver that does the direct communication with the hardware. You can see how the different tasks that are defined in the USB protocol are assigned the different tasks. When an application closes or no longer needs a USB device, it closes the device's Windows assigned handle to free up limited system resources -- which is imperative in Windows applications.


There are some software tools available from the Developer's section of the USB Implementer's Forum to help verify your software. USBComp.exe, available from, contains a series of several test programs that allow you to check out your device to see how it functions when connected to USB, whether you're using HID or your own Windows driver. This at present is only for computers running under Windows 2000. In particular, have a look at USBCheck which is included in USBComp.exe. There also are several USB protocol analyzers available which will allow you to see all traffic on the USB port. Using one of these is probably the best way to assist you in the development stages as well as thoroughly checking the operation of your device. As always, you can download the latest USB specs and current important documentation from

We have covered quite a bit regarding the basics of USB in these two articles. There are more details available at the USB Implementer's Forum web site that was mentioned above. Also, the web has many other resources to help educate you further on USB or provide USB development tools available for either lease or purchase. Be sure to check out SSS Online's USB Links information for more information and listings of some of these sites. At Pegasus / SSS-OnLine, we strive to help you with all your communication needs!

Back to Part I"

Back to Contents

Explore SSS Online:

Click on a topic below to explore SSS Online:

Back to Contents

Search This Site or the Web

Search WWW Search Search

Back to Contents

Search E-zine Menu Pegasus Tech Welcome Home
  Tel: 865-717-9339   ||   FAX: 865-717-9904    ||   E-Mail:
This site © 1995-2008 by SSS Online, Inc. All rights reserved.
Revised September 14, 2008