 |
 |
 |
|
|
|
| What
is USB ? Universal Serial Bus |
Presented by: |  Copyright 2000© |
|
|
The Universal Serial Bus was invented and standardized by a group of computer and peripherals manufactures in 1995.
The
idea was to take the whole area of serial port and serial bus and update
it with the twenty-first century technology.
It
is true that there were many standards of communication between host
computers and peripherals, but the goal was to create a technology that
combines low speed and high speed bus activity. The technology enables
shared access for both speeds, a technology which provides robust
protocol, automatic configuring of devices and a serial bus which is
simplified and easy to plug into. All those requirements were met with
the USB standards.
The
USB has become a very popular expansion to the personal computer. It is
important to remember the USB isnt a serial port it is a serial bus,
a fact that enables a single port on the computer to be a link for a
myriad of devices, (up to 127 devices in a USB system). We can easily
chain one device to another and use one port as a connecting point of
many devices by using a hub. All
these enables us to look at the USB system as a small network of
devices.
The
plug and play capability
of the USB is one of its advantages over other serial buses. This
capability enables automatic detection of a new
device, which is attached into the system, an automatic configuration of
it by the host, and an automatic detection of it's detachment from the
system. The flexible attachment and detachment of devices to and from
the system allows mobility on the bus and adjustment of the system to
new devices without the need of restart the whole system each time a new
device is detected.
Another
important aspect of the USB is it's mid
and high speed flexibility. This feature refers to the ability of
the USB to support simultaneously medium-speed devices, (which work in
1.5Mbps), and high-speed devices, (which work in 12Mbps).
The
simultaneously work of the USB system finds expression also in the dual
support in both isochronous and
asynchronous bandwidth
allocation methods. Isochronous means that the necessary bandwidth is
guaranteed, whenever the device requires it it will be available.
Asynchronous on the other hand means that there is no guarantee the
data will be sent whenever it will be possible to send it. Devices, such
as video and audio multimedia, that use stream transfer, will use the
isochronous method while devices that use bulk transfer, such as
printers and scanners will use the asynchronous method.
The
USB is robust. Through
all the different protocol layers there is an error detection and
recovery mechanism, which guarantees low error rate. The USB provides
detection of faulty devices and flow control mechanism, which is built
in the protocol.
A
typical USB system consists of:
 |
One
host
there is only one host in the USB system, which is responsible
to the whole complexity of the protocol (simplifies the designing
of USB devices). The host controls the media access no one can
access the bus unless it got an approval required from the host. |
|
Hub like the hubs used for computer network. The hub provides an interconnect point, which enables many devices to connect to a single USB port. The logical topology of the USB is a star structure, all the devices are connected (logically) directly to the host. It is totally transparent to the device what is its' hub tier (the number of hubs the data has to flow through). The hub is connected to the USB host in the upstream direction (data flows up to the host) and is connected to the USB device in the downstream direction (data flows down from the host to the device). The hubs' main functionality is the responsibility of detecting an attachment and detachment of devices, handling the power management for devices that are bus-powered (get power from the bus), and responsibility for bus error detection and recovery. Another important role of the hub is to manage both full and low speed devices. When a device is attached to the system the hub detects the speed, which the device operates in, and through the whole communication on the bus prevents from full speed traffic to reach low seed device and vice versa prevent from low speed traffic to reach full speed device. |
|
Device
everything in the USB system, which is not a host, is a device
(including hubs). A device provides one or more USB functions.
Most of the devices provide only one function but there may be
some, which provides more than one and called compound devices. We
refer to two kinds of devices - self powered or bus powered
devices. A device that gets its power from the bus is called bus
powered and on the other hand a device which supplies its own
power is called self powered. As was mentioned before there are
two kinds of devices: |
Following
the USB communication layers model as shown in the specifications:
The
logic communication between the client software on the host and the
function on the device is done through pipes. A pipe
is the association between a specific endpoint on the device and the
appropriate software in the host. An endpoint
is the source or destination of the data that transmitted on the
USB cable. An interface is
composed of endpoints grouped together into a certain set. The client
software whishes to transmit data between the buffers in the host and
the endpoints in the device and by that manages the specific interface
(which is associated with specific endpoints).
Communication flow on the bus can be done is two directions:
OUT - data flows from the host to the device.
IN
- data flows from the device into the host.
The
physical layer is the physical interface to the USB cable. The main
responsibility of the physical layer is to transmit 0 as 0
and 1 as 1 and to receive 0 as 0 and 1 as
1.
The
USB cable is 4 wire cable, signaling on the bus is done by signaling
over two wires (differential pair). There is a D+ wire and a
D- wire, in a way that if we want to transmit 0 over
the bus we will keep D+ low and D- high and vice
versa to transmit 1 we need to keep D- low and D+ high.
The other two cables are Vbus (+5v) and GND (5v) to deliver power to
the device. Bits are send into the bus LSB first.
There are few unique types of signaling on the bus, which are identified as special cases:
|
Reset signaling: The host can reset the device. This is done by signaling SE0 (single ended zero - D+ andD- are kept low) for more than 2.5΅sec. Whenever the device recognizes such a signaling on its upstream port of the bus it treats it as a REST signal. |
|
Suspend signaling: the host can enter the device into a suspend mode, in which the device won't respond to the USB traffic. A device will begin the transition to a suspend mode whenever it will recognize an idle state on the bus for more than 3msec, the device will actually be suspended no more than 10msec bus inactivity. Recognizing signaling on its upstream ports will take the device out from the suspend mode. |
|
Resume signaling: A device, which in suspended state, will resume its operation whenever it will recognize a K signaling (differential "0" for full speed devices and differential "1" for low speed devices) on the bus. Whenever the host wishes to wakeup the device it sends RESUME signaling for at least 20msec. A device can also wakeup itself - we call that feature "remote wakeup capability", which allows the devices, which in suspend mode, start sending K signaling on the bus and resume its own activity. |
|
EOP
signaling:
EOP is
transmitted as SE0 for 2 bit times (defined differently for
low-speed/ high-speed devices) followed by J
signaling(differential "1" for full-speed devices and
"0" for low-speed devices) for 1 bit time. |
Data
encoding and decoding is done using NRZI
method. In NRZI coding if we want to transmit 1 we dont change
the level of the signaling (if the differential pair represented logic
1, it will remain in this level also for the next clock), on the
other hand if we want to transmit 0 we will flip the value of the
differential pair. (There will be toggle in the level in a way that if
the current value represented is differential 1 the next value
will be differential 0).
One
of the affects of the data encoding represented above, is that sending a
string of ones will cause a continuous mode of transmission (the
transmission lines will stay static with no change for that period).
In order to prevent such a continuous state, bit
staffing is performed before the NRZI decoding. The bit staffing
is made by inserting a zero after six successor ones. In the decoder
that zero is recognized as part of the bit stuffing and is ignored.
The SIE is part of both the host's and the device's physical layer. Data is transmitted on the bus as a serial bit stream. The SIE is responsible for the serialization and deserialization (converting the data stream to a parallel one) of the USB transmissions. Incoming data stream is NRZI and bit stuff decoded, the outgoing traffic is NRZI and bit stuff encoded, the SIE is responsible for those operations of decoding and encoding. The SIE is also responsible for generating CRC for the outgoing data and verify CRC for the incoming stream. The SIE also detect the PID (packet's id) as well as SOP, EOP, RESET and RESUME signaling on the bus.
The
host is the "smartest" element in the USB system and plays a
unique role in the system. The host initiates all the transactions,
controls the media access and is the main engine for the protocol's
flow, as we will se later on. That is why the host controller, an
additional hardware, is required to ensure that everything, which is
transmitted on the bus, is correct and within the specifications.
The
host controller serves both the USB and the host and has the same
functionality in every USB system.
Following
some of the HC functions:
|
Frame
generation: The
host controller is responsible to partition the USB time into time
units, in a way that each time unit is 1msec and is called a
"frame". The host controller issues, periodically, SOF
(Start Of Frame) packet every 1msec (after the transmission of the
SOF the HC can transmit any other transaction for the rest of the
frame period). The SOF contains the current frame number, which is
maintained by the HC. |
|
Data
Processing:
The HC handles the requests for data to and from the host.\ |
|
Protocol
Engine:
Handling the USB protocol level interface. |
|
Error handling: The HC handles errors such as: |
Timeout
- the function in the device is not responding
CRC
error
Unexpected data payload
The
middle layer in the communication layers model has an important role.
The layer is responsible for the translating the data between the
application layer (client software on the host and function on the
device) and the USB transactions protocol. The layer wraps and unwraps
the data according to the protocol.
The
layer is referred differently in the USB host (is called the "USB
system software" layer) and in the USB device (is called "USB
logical device" layer), which is quite reasonable due to the
different roles the two components perform in the system.
Beside
the responsibilities described above, the USB system is also responsible
for the bandwidth allocation and bus power management in order to enable
devices to access the bus.
The
USB System SW is composed of the host software and two additional
software interfaces:
|
The
Host Controller Driver (HCD): is an interface to the host
controller. The purpose of using such aninterface is to make it
transparent for the host software which host controller the device
is connected to. |
|
The
USB driver (USBD): The client software (the top layer of the host
communications layer) request data from the USBD in a form of IRPs
(I/O Request Packets) which consist of a request to send/ receive
data through a certain pipe.
The USBD handle those requests. Another important role of the USBD
is to supply the client software a general description of the
device which the software is about to handle. The USBD is required
to handle the enumeration process (a process which is activated
the moment the device is attached to the bus and in the end of it
the device is fully configured, is a part of the USB system and
can response to the traffic on the bus), investigate the different
configurations of the device and supply this knowledge to the
client software. As a part of this role the USBD owns the default
pipe, since when a device just enters the system, the only way to
communicate with it is through the default pipe. |
The
USB logical device is composed of a collection of independent endpoints.
Each endpoint is given a unique address (endpoint number) at the design
time, the USB logical device is also uniquely addressed at the end of
the enumeration process. An endpoint is unidirectional (except from
endpoint number zero), it may be IN type (supports data transfer from
the device to the host) or OUT type (supports data transfer from the
host to the device), this means that for bi-directional flow we need two
endpoints each for a different direction. The combination of the USB
logical device address, the endpoint number and the direction of the
endpoint define uniquely a certain endpoint. An endpoint is
characterized with a transfer type. As we will see later on, there are
four types of transfers on the USB, each endpoint is associated with
only one transfer type, and by that characterized with its bandwidth
allocation requirements.
All
USB devices must support communication through the default pipe. The
default pipe plays an important role in the enumeration process, and is
the only communication channel to the device at attachment. The default
pipe is associated with endpoint number zero (that is why endpoint
number zero must be included as part of the device and must be of a
control type). Endpoint number zero is and composed of two endpoints
(one IN and one OUT) that share the same endpoint number and are
referred as one.
Low
speed devices can support two additional endpoints (beside endpoint
number zero) which may be control or interrupt type. Full speed devices,
on the other hand, can support up to maximum of 15 additional IN
endpoints and 15 additional OUT endpoints. The additional endpoints can
be used only after the devices has been fully configured.
The
application layer appears as the client software in the host and as the
function in the device. The function in the device is composed of
collection of interfaces and controls the functionality of the device.
The client software manages the appropriate interface by transferring
data from its buffers to the endpoints associated with the appropriate
interfaces. The client software works with a specific device function,
independent of the other device functions in the system.
The
USB host handles most of the complexity of the USB protocol, which makes
the peripherals design simple and low cost. Data flow can be from host
to device and from device to host.
USB
transactions are done through packets. Each transaction is composed
usually from three phases:
The
USB uses a polling protocol. Whenever the host whishes to receive data
from the device it issues a token (a packet types that we will discuss
later) addressed to that specific device. If the device has data to send
it sends it after receiving the token and the host (if the handshake
phase is included on the transfer) will respond with handshake packet.
It the device doesn't have anything to send the host issues the token to
the next device. If, on the other hand, the host whishes to send data to
the device, it will send the appropriate token and data packet following
it. The device will response by a handshake packet (if handshake phase
is included). Once again, the moment the host finishes transmitting data
to that device, it issues a new token to the next one.
When
we talk about the USB protocol, we can't ignore its robustness. The
protocol includes handshake mechanism, timeout rules (to prevent
deadlock in the system), low control mechanism and very low physical bit
error rate (< 10-10 ). Each packet transmitted on the bus
includes check bits and CRC protection.
There
are four main USB transfer types:
|
Isochronous
transfer:
Isochronous transfer, as was mentioned previously, is used for
multimedia devices such as audio, video, etc. Important
characteristic of the transfer is that bandwidth is guaranteed -
the required bandwidth is reserved for the devices uses this
transfer type. In isochronous transfers there is less attention to
the success of the transfer (whether or not the whole data arrived
on time) since the traffic included in this transfer type has a
high tolerance for errors. |
|
Bulk
transfer:
Bulk transfer
is consisted of massive amount of data and is used by devices
requires it such as printers, scanners, etc. The bandwidth
allocated in each transaction of the transfer varies according to
the bus resources at the time. Bulk transfers are done in reliable
mode - there is great deal of awareness to errors.
|
|
Interrupt
transfer:
Interrupt
transfer is a limited-latency transfer and used for devices such
as mouse, joystick that needs to report short event notification,
characters or coordinates. A USB device that works in an interrupt
transfer mode defines, as part of its configuration, the time
interval it wants to send or receive information. The host is
responsible to turn to device at that specific rate, and then the
device is allowed to send or receive the necessary data.
|
|
Control
transfer:
Control transfers are used to configure a device. The
configuration is done at the enumeration process but can be done
also at any state of the communication process. When a device
enters the system the host needs to learn about it and configure
it at the appropriate configuration, all this communication is
done using the control transfers. Control transfer can also
includes special messages defined by the vendor. |
Low-speed
devices support control and interrupt transfers while full-speed devices
support all of the above transfers.
Before
learning the different types of packets used by the protocol, let us
view the different fields in the packets:
The SYNC field appears at the start of each packet. It appears on the bus as idle followed by "KJKJKJKK" (encoded in NRZI encoding). The SYSC (synchronization) field allows the receiving peripheral synchronize its internal clock to the incoming data. The following packets description will ignore this field (for simplicity) but we mustn't forget its existence.
The
PID field contains the identity of the packet, Since there are many
types of packets we need to indicate at the start of the packet, which
packet it is. The PID field is composed of eight bits as is shown in the
following diagram. The first four bits are used to notify the actual id
of the packet, and the next four are used as check bits (are one's
complements of the first four bits) and used for error detecting.
The
PID types are divided to three main groups:
·
OUT
token
indicates that the following data will be transmitted from the host to
the device.
·
IN
token indicates
that the following data will be transmitted from device to host.
·
SOF
token
indicates start of frame.
·
SETUP
token indicates
that the following packet will be sent from host to device and will
contain setup command (used for configuration).
·
ACK:
The receiver
received error free packet.
·
NAK:
The receiver is
unable to receive the data (for example due to overflow problem), or the
sender is unable to send data (underflow problem for example).
·
STALL:
The specific
endpoint is halted or the specific SETUP command is not supported.
The
address field is divided into two fields:
|
Endpoint
Field (ENDP):
The endpoint number field contains the number of the endpoint
referred. Each endpoint in a specific function is identified
uniquely with an endpoint number. In low-speed device there can be
two additional endpoints (beside endpoint number zero) and for
full-device there can be up to 16 endpoint at any type (including
endpoint number zero). The endpoint field is used in OUT, IN and
SETUP tokens. |
The
frame number field is composed of 11 bits indicating the number of the
current frame. The filed is contained only in SOF token indicating the
start of the frame.
The
data field contains the data transmitted in the transaction. The data
field can contain up to 1023 bytes.
The
CRC (cyclic redundancy check) field is uses to protect all the fields in
a token packet (except of PID field) and to protect the data in the data
packets. The CRC field in a token packet is composed of 5 bits while in
data packets is composed of 16 bits.
Let
us view the different packets format:
As
was mentioned before, each transaction begins by issuing a token by the
host. The ADDR and ENDP field uniquely defines the endpoint that is
about to receive the following data packet in SETUP or OUT transactions,
and on the other hand specifies the endpoint that is about to send data
in IN transactions.
The
host issues a SOF packet every 1msec±0.0005msec. the packet contains
the frame number field which indicated the number of the current frame.
SOF token can be used as a trigger to process isochronous OUT endpoints.
Data
packets are composed of PID (indicating that the packet is a data
packet), data field, which contains the actual data to be transmitted
and CRC16 to protect the data field.
Handshake
packets are composed only of PID indicating the results of the previous
stage. ACK, which indicates that the packet was received with no CRC or
bit stuff errors, can be used at the handshake phase of a SETUP, OUT
transfers (sent by the device) or in IN transfer (sent by the host).
NAK,
which is used for flow control, can be sent in the handshake phase of
OUT or IN transfers.
STALL,
which indicates some problem in the transfer (endpoint halted or control
command not supported), is not allowed to be used by the host.
A
control transfer is composed of three or two phases: setup, data
(optional) and status, each of those phases is composed of three phases
(token, data, handshake).
The
setup stage role is to indicate the device which setup command the host
whishes to send. There are many kinds of SETUP commands such as:
|
SET_ADDRESS
: setting a permanent address to a
function. |
|
GET_DEVICE_DESCRIPTOR: the host whishes to get the device descriptor, which contains details concerning the device - how many configurations, interfaces it has, is the device is self/ bus powered etc. |
|
GET_CONFIGURATION_DESCRIPTOR:
the host whishes to learn about a specific configuration of a
device. |
|
GET_CONFIGURATION:
the host detects which configuration is active at the moment in
the device. |
|
SET_CONFIGURATION:
the host sets a specific configuration on the device. |
At
the beginning of a setup stage the host issues a SETUP token, followed
by the setup command packet, The device must response with an ACK
packet.
The
data stage (if included) contains the flow of the data, which direction
(from host to device of from device to host) indicated in the setup
stage. The data stage is composed of one or more IN or OUT transactions
(all the transactions in the data stage must be in the same direction -
all IN or all OUT). Each transaction in the data stage begins with
IN/OUT token issued by the host, afterwards data is sent (in the
appropriate direction) and the transaction ended with a handshake
packet.
The
status stage reports the host the results of the previous stages: setup
and data stages. The report is always from the device to the host.
Important characteristic of this stage is that the data flow
direction in it is opposite to the one in the data stage (if there
wasn't data stage the direction will be IN).
If
the direction of the status stage is IN then the report is done in the
data phase of the transaction, if it is OUT then the report is done in
the handshake phase.
Example of Control transfer: (Get_Device_Descriptor as SETUP command)
Bulk
transfers are composed of one or more three phases transactions.
Each
transaction starts with a token sent from the host indicating the
direction of the data transfer in the following phase. In the next
phase, data is transmitted according to the direction indicated by the
token. If there was no detection of data error while receiving the data,
the last phase is the handshake phase, in which a report concerning the
success of the transaction is being sent. If error was detected no
handshake packet is sent.
There
are two kinds of bulk transfers:
|
IN
transfer
- in which the host asks for data
from the device - data flow direction is from the device into
the host. |
|
OUT
transfer
- in which the host whishes to send data to the device - data
flows from the host out
to the device. |
Whenever
the host whishes to receive data from the device, it initiates an IN
token and sends it to the device, when the device receives the token, it
sends data as response to the token and the host responds with an ACK
packet if the data was received error free and doesn't send any
handshake in case of error detection. In
case the device can't send the required data (underflow - data needs to
be sent but the transmit FIFO is empty, or any other function problem),
the device won't responds with a data packet but with NAK or STALL
indicating its inability to answers the host demands. This situation
results two phase transaction.
If,
on the other hand, the host wishes to send data to the device, it
initiates an OUT token and sends, in the next stage, the data it wished
to send. The device, after receiving the data response with a handshake
packet.
There
are three kinds of handshake responds by the device: ACK indicates that
data was received without any errors, and was accepted by the device.
NAK indicates that data was received error free, but could not be
accepted by the device, due to temporary problem in the device
(overflow, underflow, etc.), the host should retry the transmission.
STALL indicates that the device could not accept the data due to error
condition on the function, the host should not retransmit the data.
Bulk
transfers are highly reliable due to the handshake and timeout (which
was mentioned earlier) mechanisms. If there is any problem in the USB
system, the host will detect it and prevent deadlocks in the system.
Interrupt
transfers are very similar to bulk transfers. As in bulk transfers data
can be sent from host to device and from device to host.
If
the host wishes to know which interrupt is pending on the device, it
initiates an IN token to the appropriate endpoint. If there is a pending
interrupt, the function will send details concerning the interrupt, as a
data packet in the following stage. If the information was received
error free by the host, it will initiate an ACK packet in the handshake
phase. In case of error detection no handshake will be transmitted.
If,
on the other hand, the host has initiated an IN packet but there are no
pending interrupts and the endpoint has no information to send, the
function will return a NAK packet. In case of an error condition in the
function a STALL packet will be sent.
The
host will initiate an OUT token in case it wishes to transmit data to
the device (data to serve the interrupt for example), following the
token a data packet will be sent. The device, upon receiving the data,
detects for errors, if the data is error free the device will response
with ACK, NAK or STALL (as in bulk transfer). If the data was corrupted
no handshake will be sent.
Example of Interrupt transfer:
Isochronous
transfers are composed of one or more two phases transactions. As was
mentioned earlier, there is no handshake phase in isochronous transfers.
The host initiates either an IN token, in order to receive data from the
device, or an OUT token to send data. In the next stage data is
transmitted in the direction indicated by the token which was sent
before.
Example
of ISO transfers:
USB
Explained by Steven McDowell
& Martin D.Seyer 1999.
Universal
Serial Bus Specification Revision
1.1 Sep 1998 (Compac, Intel, Microsoft,
NEC)
For
more details you can refer to USB Implementers Forum web page at:
Submitted by:
Revital Almagor
Shiri Earon
Uri Canari
Neta Kopelman
|
Home
| Search
| About |
Offices
| Manufacturers |
Products
| Services |
Ordering |
| Copyright© 2008 [Pulse, Inc.]. All rights reserved. Tel: (toll free): 888-785-7393 Int'l: 1-951-694-1173 Fax: 1-951-694-1173 Sales: sales |
