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.
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
Introduction
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 ...
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.
Tools
There are some software tools available from the USB.org Developer's section
of the USB Implementer's Forum to help verify your software. USBComp.exe,
available from
http://www.usb.org/developers/developers/tools/, 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
http://www.usb.org/developers/docs/.
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!
