The Universal Serial Bus is an astonishingly useful way to connect large numbers of peripherals
together. It is becoming increasingly important in today's electronics world. On this page,
we provide basic information on USBs, links to more USB resources, and book references. Take a
look!
An Overview of the Universal
Serial Bus (USB), Part 1
-- by Danny Simpson, Pegasus
Technologies
Editor's Note: Part 1 of this article was originally published in the
December 2000 issue of SSS Online.
Introduction
With increasing use of the Internet, cellular telephones, and communications in general,
communications interconnectivity has been growing at a rate that no one could
have imagined five years ago. As a result, problems have arisen in the wireless industry
related to limited bandwidth as well as connections to "wired" devices. The RS-232D
standard has been a staple in "wired" communications for a
number of years. Generally, this standard limits the rate of communication speed to 115,000 bps,
which is not adequate for today's technology. Also, RS-232 does not allow daisychaining multiple
devices that are attached to one main device, unless a special design is implemented for the
purpose.
Of the many new serial protocols that have popped up in response to these problems,
USB (Universal Serial Bus) currently seems to be reigning supreme. One of the reasons that USB
was implemented was to replace existing serial and parallel ports on computers. USB has several
advantages for this application, which is why it has been included in
most of the new PCs that have been shipped since Windows 98 was released in late June of 1998:
It uses a much higher data transfer rate than many common serial data formats.
It allows a large number of devices to be attached to a single host USB connector. Up to 127
devices can theoretically be used on a single USB port, but realistically this could cause bandwidth
problems and other potential complications.
It simplifies the connection to external devices. USB supports "plug and play" -- the
operator does not need to be heavily involved in the set-up process. When a device is connected to a
host's USB bus, it is immediately recognized by the host, dynamically enumerated, and assigned
an address by the host. Once the host knows what kind of device has been plugged into it, it
interrogates the device to understand how to communicate with it. While a device driver needs to
be loaded on the host PC, some operating systems have "generic" drivers embedded in them
that will work for some common USB devices such as keyboards.
USB Specifications and Operating Program Support
USB Implementers Forum, Inc. is a non-profit
corporation formed by a group of companies that developed the initial USB specification. Among
their activities is the development of a testing and certification program for compliance with the
USB specification. Before a device can use the USB logo or icon, it must undergo rigorous
testing and be certified as USB compliant.
While this compliance testing goes a long way toward ensuring device compatibility, there are
no guarantees, however, that all USB certified devices will be able to work together
compatibly over a particular USB bus. This is not only because of differences in interpreting and
implementing the USB standard and failure by some manufacturers to adhere to the standards, but also
because of the rapid development of technology itself. For example, because of the limited bandwidth of the USB 1.x standard,
care must be exercised when combining devices compliant with that specification where data receipt is time-sensitive --
such as several devices on one bus that all transfer video simultaneously.
There are several different editions of the USB standard that have been released:
USB 1.0, the first edition, was released in January 1996. It supported 1.5 Mb/s (low speed)
and 12 Mb/s (high speed) transfer rates. Note that this is Megabits per second and not
MegaBytes per second -- a common misunderstanding. A percentage of this data rate is
reserved for USB protocol overhead, so the actual data transfer is less than the
indicated speed. How much less depends on the transfer type and the packet sizes.
USB 1.1 was released in September 1998. This edition fixed many of the problems in release 1.0.
USB 2.0 was released in early 2000 and has increased the maximum transfer speed by a factor of
14 up to 480 Mb/s! USB 2.0 is backwards compatible with USB 1.x. Although the USB 2.0 specification has been released,
operating programs for personal computers are not expected to have USB 2.0 support until about the fourth quarter of 2001.
A few peripherals supporting USB 2.0 have already begun to show up on the market in late 2000.
Windows 95 (and earlier versions of Windows) has no USB support. A sub-release of
Windows 95 (OEM Service Release 2) was issued to computer manufacturers only and it added
somewhat limited support for the USB protocol. Windows 98 added additional support and
fixed some problems that were in the 95 OEM Service Release 2. Windows 98se
(98 second edition) released in early June of 1999 had more robust support for USB.
Both Windows 2000 and Windows Me released in early 2000 added additional features.
Apple Computer's OS 9.0.4 was released late summer of 2000 and added much better
support for USB for the Mac. Many problems associated with USB can be solved by using the
latest version of the appropriate operating system.
In this article, the term USB includes all the above revisions as a general protocol. However,
the operating details described below refer to USB 1.x (both USB 1.0 and 1.1) unless
otherwise specified. Also, when a "device"
is mentioned here, it is referring to a USB-compliant peripheral.
How USB Works: an Overview
USB uses a four-wire cable interface. Two of the wires are used in a differential
mode for both transmitting and receiving data, and the remaining two wires are power and ground.
The source of the power to a USB device can come from the host, a hub, or the device can
be "self powered." There are two different connector types on each end of a USB cable.
One of these connectors is for upstream communications, and the other for downstream. Each
cable length is limited to about 5 meters.
USB has four types of communication transfer modes:
control,
interrupt,
bulk, and
isochronous.
Control mode is initiated by the host. In this mode, every data transfer must send data
in both directions, but only in one direction at a time. The control mode is used mainly
for initialization of devices, but it can also be used to transfer small amounts of data.
In interrupt mode, interrupts do not occur in the usual sense. As in control
mode, the host has to initiate the transfer of data. Interrupt mode works by the host
querying devices to see if they need to be serviced.
Bulk mode and isochronous mode complement each other in a sense. Bulk mode
is used when data accuracy is of prime importance, but the rate of data transfer is not
guaranteed. An example of this would be disk drive storage. Isochronous mode sacrifices
data accuracy in favor of guaranteed timing of data delivery. An example of this would be
USB audio speakers.
These four modes will be discussed in more detail below.
Above is an example of USB ports found on PCs and on some USB peripherals including
keyboards and monitors. (Thanks, USB Forum, for this picture!)
The PC host typically has connections for two external USB ports. Each of these two connectors
on the PC is actually a connection to a separate root hub inside the PC. If either of the two
root hubs needs to have more than one device connected to it, a downstream USB hub is required
to expand connections. Hubs are used to add to the number of devices that can be connected
to one USB port. They can be considered to be a repeater of sorts and also a controller.
When a device is connected downstream of a hub, the hub does the connect detection of the
new device and notifies the host.
Hubs can be inside the device itself -- for example, in a keyboard that may have an additional
two downstream USB connectors for additional devices. A hub can have a combination of high and
low speed devices connected to it, up to a maximum of four additional hubs downstream from itself.
A hub's upstream port to the PC must be high speed. The hub acts as a traffic cop,
handling communication to downstream devices as either high or low speed. A hub can
ignore a downstream device that is not behaving properly. Hubs can be either self-powered
or receive power from the USB bus. USB 1.x hubs support both low and high-speed data
transfers.
There are several hardware requirements for devices that are placed on the
USB bus. Five volts is the nominal supply voltage on the bus. A device that requires
100mA or less can be powered from the host or any hub, provided that the total available power
hasn't already been exhausted by other devices. A device on the bus can
draw up to 500mA from it. However, not all USB hosts (especially a battery powered PC)
or bus-powered hubs will allow a device to draw more than 100mA from the bus. For this reason,
a USB device that draws more than 100mA should, in most cases, be self-powered .
A device tells the host how much current is required for
its operation. Self-powered devices usually get their power from a separate power supply
or batteries. A battery-powered device plugged into the bus can get its power
from the bus if it meets the tests above, and it can then switch back over to battery
power when it is disconnected from the bus or when the host is shut down. When a device is
in suspend mode, it cannot draw any more than 500uA from the bus if it is bus-powered.
Also, if a device has not seen any activity on its bus in 3 mS, it needs to go into
suspend mode. A host can initiate a resume command to a device that is in suspend mode.
A device can also issue a remote wakeup to an inactive host to make it active.
All devices have endpoints, which are memory buffers. An endpoint can be as
simple as an addressable single register, or it can be a block of memory that is used to store
incoming and/or outgoing data. There may be multiple endpoints inside a device.
Each device has at least one endpoint -- "endpoint 0"-- which is used as a control
endpoint. It must be able to both send and receive data, but can only communicate in one direction
at a time. Typically, when a device receives data such as an
Out or Setup command from the host, this data is stored in the
endpoint and the device's microprocessor is interrupted and works on this data. When a
device receives an In command that is addressed to it from the host, data for the host that is
stored in the endpoint is sent to the host.
The host is considered to be the master in most all cases. One exception is when a
device issues a remote wakeup to the host as discussed above. There are time limits
for both the host and device to respond to each other. For example, if the host
requests data from a device using an In command, the device must send the data back to the
host within 500mS, in some cases. Depending on the transaction type, the host and/or the device may
respond to data received with an acknowledgement. Data transfer involves quite a bit of
error-checking and handshaking. The different types of data packets sent and received
use different ways to verify correct data transfer.
A logical connection link needs to be set up between the host and a device before a
transaction can occur. This connection is referred to as a Pipe. It is set up as soon
as possible after a host has recognized a device as being connected. When the host responds to
a connect signal from the device, one of the parameters that is sent to the host is
the device's required data transfer type and speed. The host can refuse to establish
a Pipe if the host does not have enough bandwidth to support the
device's request or if its power requirements cannot be met. The device at its discretion can
lower its requested data rate and try
again until the host accepts it and initiates a Pipe.
When a device is connected, it also sends to the host descriptor
information on the types of endpoints in the device, the type of data transfer
it uses, size of data packets, endpoint addresses within the device, and if used, the
time required between data transfers.
The following describes a typical data flow for a device when it is initially plugged into a
host's bus while the host is active. Remember here that the host has an internal USB hub, and
additional hubs may be connected downstream from the host's hub.
The host recognizes that a device has been attached to one of its USB hubs. It realizes this
by a simple resistive divider that is connected to the differential data pair of wires in the
USB bus. These resistors are inside the USB hubs and devices.
The host sends a Get_Port_Status request to the hub to find out more about what
has been plugged in. It could be another hub, a device connected directly to the host
hub, or a device that has been plugged into one of the downstream hubs.
After receiving a response from the hub, the host issues a Set_Port_Feature command
in which the hub issues a reset over the data pair but only to the newly connected device on
the USB bus.
The host then checks to see if the device has come out of the reset state by issuing
a Get_Port_Status command to the hub. After reset, the device is in the Default state and can
only draw a maximum of 100mA. In Default state, the device can communicate with the host
through Endpoint 0.
The hub now detects the device's speed by using the resistive dividers that are
attached to the USB bus. The hub sends the speed of this device back to the host.
The host then sends a Get_Descriptor command to the hub in which the hub gets the
packet size needed from this particular device and sends the result back to the host.
The host now issues a Set_Address command to the hub which sends this information to
the device. The device in turn acknowledges the command back through the hub to the host and
sets up this address internally.
To learn more about this device, the host sends a Get_Descriptor command to the address
that the device has been given. The information that is returned to the host consists of various
details of the device that the host needs to know for its operation. These queries by the host
continue two more times to retrieve all the information needed.
Based on the information received from the device, the host determines the best device
driver to use for communications with it.
The device driver in the host now takes over by requesting a Set_Configuration command.
There can be several configurations for one device, and the device driver determines which to use
based on information received from the device in response to the Get_Descriptor command.
The device is now ready for use.
As you can see, the USB protocol is a fairly complex arrangement. This strict pattern of query
and response, however, is important in alleviating potential conflicts on the bus.
In part two of this article, we will continue our exploration of USB basics.
Jungo, Ltd. — makers of
USB (Hi-Speed 2.0/USB 1.1) driver development tools, including WinDriver
and KernelDriver that automate and simplify the development of device
drivers for the Windows, including NT 4.0 (which does not natively support
USB), Linux, Solaris, and VxWorks operating systems.
USB-Ware.com — an online reseller of all types and brands
of USB products including adapters, interface cards, video capture devices,
external hard drives and external drive kits, plus DVD drives and authoring products.
