usbintro.sgml

来自「usb develop guide」· SGML 代码 · 共 325 行

<chapter>
<title>USB Introduction</>
<para>
This chapter provides a brief introduction into the Universal Serial Bus
(USB) in general, and may be skipped if you are already familiar with the
bus, and its software and hardware architecture.
</>


<Sect1><title>The Universal Serial Bus</title>

<para>
In 1994 an alliance of four industrial partners (Compaq, Intel, Microsoft
and NEC) started to specify the Universal Serial Bus (USB). The bus was
originally designed with these intentions:
<itemizedlist>
<listitem><para>Connection of the PC to the telephone</para></listitem>
<listitem><para>Ease-of-use</para></listitem>
<listitem><para>Port expansion</para></listitem>
</itemizedlist>
</para>

<para>
The specification (version 1.0) was first released in
January 1996 and the latest official version 1.1 was released in September 1998
The document is still under development and a version 2.0 was
announced in 1999. The USB is strictly hierarchical and it is controlled by one
host. The host uses a master / slave protocol to communicate with attached USB
devices. This means that every kind of communication is initiated by the host
and devices cannot establish any direct connection to other devices. This seems
to be a drawback in comparison to other bus architectures but it is not
because the USB was designed as a compromise of costs and performance.
The master / slave protocol solves implicitly problems like collision
avoidance or distributed bus arbitration. The current implementation of the
USB allows 127 devices to be connected at the same time and the total
communication bandwidth is limited to 12Mbit/s. Howewer use of low speed
devices, management of USB "interrupts" and other overheads mean that actual
throughput cannot exceed about 8.5Mbit/s under near ideal conditions, and
typical performance may be around 2Mbit/s.
</para>

</Sect1>

<Sect1><title>Host Controllers</title>

<para>
Most modern motherboard chipsets provide a USB host controller. Older machines
which are not equipped with a USB host controller can be upgraded using a PCI
cards with a host controller built in. 
</>

<para>
USB host controllers are
compatible with either the Open Host Controller Interface (OHCI, by Compaq) or
the Universal Host Controller Interface (UHCI, by Intel) standard. Both types
have the same capabilities and USB devices work with both host controller
types. Basically the hardware of UHCI is simpler and therefore it is
cheaper, but needs a more complex device driver, which could cause slightly
more CPU load. </para>

</Sect1>

<Sect1><title>USB Devices and Transfer Characteristics</title>
<para>
There are a wide range of USB devices intended for a wide range of
purposes, and this means that implementation details can vary widely. 
</para>

<para>
A device can be self powered,  bus powered or both. The USB can provide
a power supply up to 500mA for its devices. If there are only bus powered
devices on the bus the maximum power dissipation could be exceeded and
therefore self powered devices exist. They need to have their own power
supply. Devices that support both power types can switch to self powered mode
when attaching an external power supply. </para>

<para>
Even the maximum communication speed can differ for particular USB devices.
The USB specification differentiates between low speed and  full speed devices.
Low speed devices (such as mice, keyboards, joysticks etc.) communicate
at 1.5MBit/s and have only limited capabilities. Full speed devices (such
as audio and video systems) can use up to 90% of the 12Mbit/s which is about
10Mbit/s including the protocol overhead.
</para>

<figure id="FigTopology"><title>USB Topology</title>
<graphic srccredit="Deti Fliegl" fileref="topo">
</graphic>
</figure>

<para>
Version 2.0 of the USB specification is being developed, and is expected to
deliver up to 480Mbit/s raw throughput.
</para>

<Sect2><title>Hubs</title>
<para>
Physically there exist one, two or four USB ports at the rear panel of a
computer. These ports can be used to attach normal devices or a hub. A
hub is a USB device which extends the number of ports to
connect other USB devices. The maximum number of user devices is reduced
by the number of hubs on the bus (i.e. if you attach 50 hubs, then at most 
77 (=127-50) additional devices can be attached. Hubs are always full speed
devices. If the hub is self powered, then any device can be attached to it.
However if the hub is bus powered, then only low power (100mA max) devices
can be attached to it. A bus powered hub should not be connected to another
bus powered hub - you should alternate between bus powered and self powered
hubs.
</para>

<para>
Normally the physical ports of the host controller are handled by a
virtual root hub. This hub is simulated by the host
controllers device driver and helps to unify the bus topology. So every port can
be handled in the same way by the USB subsystem's hub driver (see
<xref linkend="FigTopology">).
</para>
</Sect2>

<Sect2><title>Data Flow Types</title>

<para>
The communication on the USB is done in two directions and uses four different
transfer types. Data directed from the host to a device is called
downstream or OUT transfer. The other direction is called
upstream or IN transfer. Depending on the device type different
transfer variants are used:

<itemizedlist>
<listitem>
<para><Emphasis>Control transfers</emphasis> are used to request and
send reliable short data packets. It is used to configure devices and every one
is required to support a minimum set of control commands. The 
standard commands are:
<simplelist>
<member>GET_STATUS</member>
<member>CLEAR_FEATURE</member>
<member>SET_FEATURE</member>
<member>SET_ADDRESS</>
<member>GET_DESCRIPTOR</>
<member>SET_DESCRIPTOR</>
<member>GET_CONFIGURATION</>
<member>SET_CONFIGURATION</>
<member>GET_INTERFACE</>
<member>SET_INTERFACE</>
<member>SYNCH_FRAME</>
</simplelist>

Further control commands can be used to transfer vendor specific data.

</para>
</listitem>

<listitem>
<para>
<emphasis>Bulk transfers</emphasis> are used to request or send
reliable data packets up to the full bus bandwidth. Devices like scanners or
scsi adapters use this transfer type.
</para>
</listitem>

<listitem>
<para>
<emphasis>Interrupt transfers</emphasis> are similar to bulk
transfers which are polled periodically. If an interrupt transfer was submitted
the host controller driver will automatically repeat this request in a specified
interval (1ms - 127ms).
</para>
</listitem>

<listitem>
<para>
<emphasis>Isochronous transfers</emphasis> send or receive
data streams in realtime with guaranteed bus bandwidth but without any
reliability. In general these transfer types are used for audio and video
devices.
</para>
</listitem>
</itemizedlist>

</para>

</Sect2>
</Sect1>

<Sect1><title>Enumeration and Device Descriptors</title>
<para>
Whenever a USB device is attached to the bus it will be enumerated by the USB
subsystem -  i.e an unique device number (1-127) is assigned and then the
device descriptor is read. The desciptor is a data structure which
contains information about the device and its properties. The USB standard
defines a hierarchy of descriptors (see <xref linkend="FigDescriptor">).
</para>


<figure id="FigDescriptor"><title>USB Descriptor</title>
<graphic srccredit="Deti Fliegl" fileref="descr">
</graphic>
</figure>

<Sect2><title>Standard Descriptors</title>

<para>

<itemizedlist>
<listitem>
<para>A <emphasis>Device Descriptor</emphasis> describes general
information about a USB device. It includes information that applies globally to
the device and all of the device s configurations. A USB device has only one
device descriptor.
</para>
</listitem>
<listitem>
<para>
The <emphasis>Configuration Descriptor</emphasis>  gives
information about a specific device configuration. A USB device has one or more
configuration descriptors. Each configuration has one or more interfaces and
each interface has zero or more endpoints. An endpoint is not shared among
different interfaces within a single configuration, although a single
interface can have several <emphasis>alternate settings</emphasis>
which may use the same endpoint. Endpoints may be shared among
interfaces that are part of different configurations without this restriction.
Configurations can only be activated by the standard control transfer
<systemitem>set_configuration</systemitem>.
Different configurations can be used to change global device settings, such as
power consumption.
</para>
</listitem>

<listitem>
<para>An <emphasis>Interface Descriptor</emphasis>  describes a
specific interface within a configuration. A configuration provides one or more
interfaces, each with zero or more endpoint descriptors describing a unique set
of endpoints within the configuration. An interface may include alternate
settings that allow the endpoints and/or their characteristics to be varied
after the device has been configured. The default setting for an interface is
always alternate setting zero. Alternate settings can be selected exclusively by
the standard control transfer <systemitem>set_interface</systemitem>. For example a
multifunctional device like a video camera with internal microphone could have
three alternate settings to change the bandwidth allocation on the bus.

<Simplelist>
<member>Camera activated
</member>
<member>Microphone activated
</member>
<member>Camera and microphone activated
</member>
</simplelist>

</para>
</listitem>

<listitem>
<para>An <emphasis>Endpoint Descriptor</emphasis>  contains
information required by the host to determine the bandwidth requirements of each
endpoint. An endpoint represents a logical data source or sink of a USB device.
The endpoint zero is used for all control transfers and there is never a
descriptor for this endpoint. The USB specification uses the
terms pipe and endpoint interchangably.
</para>
</listitem>

<listitem>
<para><emphasis>String Descriptors</emphasis>  are optional and
provide additional information in human readable unicode format. They can be
used for vendor and device names or serial numbers.
</para>
</listitem>

</Itemizedlist>
</para>
</Sect2>

<Sect2><title>Device Classes</title>
<para>
The standard device and interface descriptors contain fields that are related
to classification: class, sub-class and protocol. These fields may be used by
a host system to associate a device or interface to a driver, depending on how
they are specified by the class specification. Valid values
for the class fields of the device and interface descriptors are defined by
the USB Device Working Group.
</>

<para>
Grouping devices or interfaces together in classes and then
specifying the characteristics in a Class Specification allows the development
of host software which can manage multiple implementations based on that
class. Such host software adapts its operation to a specific device or
interface using descriptive information presented by the device. A class
specification serves as a framework defining the minimum operation of all
devices or interfaces which identify themselves as members of the class.
</para>
</Sect2>

<Sect2><title>Human Interface Devices (HID)</title>
<para>
The HID class consists primarily of devices that are used by humans to
control the operation of computer systems. Typical examples of HID class devices
include:

<simplelist>
<member>Keyboards and pointing devices for example, standard mouse devices,
trackballs, and joysticks.</>
<member>Front-panel controls for example: knobs, switches, buttons, and sliders.</>
<member>Controls that might be found on devices such as telephones, VCR remote
controls, games or simulation devices for example: data gloves, throttles,
steering wheels, and rudder pedals.</>
</simplelist>
</para>
</Sect2>
</Sect1>

<Sect1><title>USB Device Drivers</title>
<para>
Finding device drivers for USB devices presents some
interesting situations. In some cases the whole USB device is handled by a
single device driver. In other cases, each interface of the device has a
separate device driver.
</para>
</Sect1>

</Chapter>