|
The Universal Serial Bus
(USB) was first implemented to to replace serial and
parallel ports on computers and has been shipped on most new
PC's since Windows 98 in June of 1998andhas significant
advantages over its older cousins
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 127 devices can theoretically be
used on a single USB port
It simplifies the connection to external devices. USB
supports "plug and play" 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 keyboardsNot what your after maybe its
here
|
|
|
USB Specifications and Operating support Program
How USB works - An
overview
Windows Supplied Drives
User supplied drivers
Communication modes
Tools
Acknowledgements
|
|
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
Back to Top
|
|
|
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.
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.
Back To Top
|
|
|
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 transferswhich 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.
Back To Top
|
|
|
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.
Back To Top
|
| |
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.
Back To Top
|
|
|
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/.
Back To Top |
|
|
|
Many thanks to the author of the above piece, Danny
Simpson of Pegasus Technologies - taken from
http://www.sss-mag.com/
Back To Top
|
|
|
