Unlike devices residing on other common bus structures
USB devices do not directly consume system resources
Not mapped into memory or I/O address space
Do not use IRQ lines or DMA channels
All transactions originate from host system
Only system resources needed
USB memory locations used by
USB system software
Memory and I/O address space and IRQ line used by
USB host controller
Design eliminates much of difficulty encountered
With standard peripheral implementations
Communications Flow
USB client initiates transfer
When it calls USB system software and requests transfer
USB client drivers supply
Memory buffer used to store data when
Sending or receiving from device
Remember 472 model
Each transfer between
Register or endpoint and Client driver
In USB device
Occurs via communication pipe
Established by USB system software during device configuration
USB system software
Splits client’s request into individual transactions
Consistent with bus bandwidth requirements and
USB protocol mechanisms
Requests passed to USB Host Controller Driver
Transaction to be performed then scheduled
Host controller performs transaction
Based upon contents of transfer descriptor build by HCD
HCD knows all information necessary to perform required transaction
Key information
Host controller fetches transfer descriptors
That have been built by HCD
Each descriptor defines given transaction that must be performed
To satisfy client’s transfer request
Each transaction results in data being transferred
From client’s buffer to USB device
From USB device to buffer
When entire transfer completed
USB system software notifies client driver
Information Transfer
Transfers initiated by client driver
When it issues transfer request to USB driver
Ultimately transaction performed via lowlevel packetized transactions
Let’s examine each layer involved
Transfers
Each USB function designed with collection
Registers or endpoints
Used by client driver to access that function
Each endpoint
Has particular transfer characteristics it supports
Example
Information transferred to speaker
Must continue at constant rate
Prevents distortion
Other endpoints may have different characteristics
Require different transfer types
Transfer Types
Following transfer types supported by USB
Isochronous
Bulk
Interrupt
Control
High speed transfer
Supports all 4
Low speed transfer
Supports only last two
Client drivers understand nature of transfer
Related to each endpoint associated with its particular function
Information determined by reading descriptors from device
USB Driver IRPs and Frames
When client driver wishes to perform transfer to / from endpoint
Calls USB driver to initiate transfer
Requested transfer called
IO Request Packet - IRP
Some transfers require movement of large block of data
USB is shared bus
Cannot typically perform large block transfer
All at one time
To accommodate such transfers
Transfer split up into smaller segments over longer period of time
Segments called transactions
Such scheme ensures USB bandwidth can be
Allocated amongst other USB devices on bus
USB communication based upon transferring data
Regular intervals called frames
Each is 1 ms
Each USB devices requires portion of USB bandwidth
Be allocated to it during each 1 ms frame
Allocation depends upon
Required throughput of device
As specified in device descriptor
Available bandwidth not required by other devices
As device is attached and configured
System software parses device descriptors
To determine required bandwidth
If requirements can be met
Device is configured
Otherwise
Device not configured
User notified
Host Controller Driver and Transactions
Host controller driver
Receives packet requests from USB driver
Schedules them to be performed
During a series of frames
Scheduling order based upon algorithm
Defined by host controller driver
Algorithm
Based upon transfer capabilities other limitations of system
Scheduling performed by building series of data structures
Called transfer descriptors
These define each sequential transaction to be performed
Host controller
Reads and interprets the descriptors
Executes the USB transaction described
USB transaction comprises three phases
1. Token phase
Define type of transaction
2. Data packet phase
3. Handshake packet phase
All USB transfers implemented to guarantee data delivery
Except isochronous
Provides feedback to sender
Whether or not data received without error
Device Descriptors
Device describes itself to host software
Number of descriptors
Descriptors include
Device Descriptor
Each device has single descriptor
Contains information about
Default communication pipe used to configure device
General information about device
Also identifies number of possible configurations device supports
Configuration Descriptor
Device has configuration descriptor
For each configuration device supports
Example
High power device may support low power mode
Has configuration for each power mode
Descriptor contains general information
About configuration
Defines number of interfaces for device
When used in this configuration
Interface Descriptor
Given configuration may have
Multiple interfaces it supports
Example
CD Rom
May require 3 device drivers
Driver for devices mass storage capability
Audio device driver for playing music
Video image driver for displaying images
Interface descriptors
Provide general information about interface
Indicates class of device
Supported by this interface
Number of endpoint descriptors used when communicating with interface
Endpoint Descriptor
Device interface contains multiple endpoints
Each defines point of communication
Descriptor provides information such as
Transfer type supported by endpoint
Isochronous
Bulk
Interrupt
Control
Maximum transfer rate supported
String Descriptors
Can be defined for
Overall device
Given configuration
Each interface definition
Describe configuration and interfaces
In unicode
Can be displayed and read by user
Class Specific Descriptors
Provide means of developing descriptors not covered by USB standard
Analogous to pragma statements in C or C++
Share with your friends: |