USB +Client Driver Technology

USB

The Universal Serial Bus (USB) is a high speed +data transport mechanism that uses a 4 wire cable attached to a USB Host to +transfer signals and bus power to low cost peripherals (clients). Theoretically, +up to 127 devices (such as keyboards, video cameras etc.) can share the bus, +although less than four devices is more typical.

There are two versions +of the USB standard in use: V1.1 and V2.0. The following table shows the speeds +supported by the different versions:

USB Speeds

+ + + +

Name

Rate

USB Version

+ + +

High Speed

480Mbit/s

2.0 only

+ + +

Low Speed

12Mbits/s

1.1 and 2.0

+ + +

Full Speed

1.5Mbits/s

1.1 and 2.0

+ + + +

As the table shows USB V2.0 adds support for the higher speed +of 480Mbit/s.

The USB system consists of single USB host controller +(the USB Host) connected to a number of USB peripheral devices. The host is +the bus master, initiating all transactions over the bus.

A client +device is a USB peripheral device. It is connected to a USB Controller and +responds to transactions addressed to it from the Controller. The Universal +Serial Bus Specification 1.1 describes how a USB Host sends commands to a +peripheral and how data can be transferred from and to a Client. The main +points are:

USB is a Host polled +bus. This means that a peripheral cannot send a data packet unless the Host +has requested it. The request must either be accepted, and the data packet +sent within a given time period, or refused.
Every peripheral attached +to the USB is allocated a unique device address. The Host uses the device +address to direct its communication to a particular device. In fact, the Host +sees the peripheral as a collection of endpoints. Each endpoint is an address +within the peripheral to which the Host sends packets or from which the Host +receives packets.
Endpoints are grouped +together by the peripheral into Interfaces. The Host regards each peripheral +as a set of functions and communicates with each function via its Interface. +Simple devices, such as mice, contain only one function, other devices may +contain more than one function, e.g. a monitor may contain speakers and a +microphone.
Each function requires +its own driver at the Host end which communicates with the function within +the peripheral using a USB class driver or vendor defined protocol. The function +informs the Host what protocol it understands via its Interface.

The USB Client Driver supports:

multiple USB interfaces, +i.e. it supports licensee products that implement multiple USB interfaces +simultaneously
alternate USB interfaces
a single USB Configuration +only; the API does not provide a mechanism for specifying more than one USB +configuration.
extended standard endpoint +descriptors.
reading and modifying +standard descriptors.
setting class specific +interface and endpoint descriptors.
remote wakeup signalling.
reading device directed +Ep0 (Endpoint Zero) traffic.

Endpoint types

There +are four endpoint types corresponding to the four transfer types:

Control endpoints
Bulk endpoints
Interrupt endpoints
Isochronous endpoints.

Control +endpoints

These are serially bi-directional. This means that they +can send and receive data, but not simultaneously.

Every peripheral +has at least one control endpoint. Although other control endpoints are possible, +Symbian platform only allows Endpoint zero (Ep0) as the control endpoint. +Ep0 is a shared resource, which must always be available.

Ep0 is vital +for the operation of the device. Its primary function is the control endpoint +for the Host. When the device is first connected to the Host, a process known +as enumeration must occur, and this takes place through Ep0. During enumeration, +the client tells the Host what kind of device it is and what classes it supports. +Enumeration is complete, for the purpose of writing client drivers, when the +Host moves the client into its configured state. The Host moves the client +into its configured state when a Host driver is available to communicate with +the client.

Ep0 needs handling with some sensitivity. Every request +arriving on Ep0 must be handled either by the Controller or by a client class +driver. Each request must be moved through the data phase, even if there is +no associated request data, so that the status phase may begin. It is imperative +that this happens otherwise endpoint zero will be unable to accept any further +requests. This could result in the Host stopping communication with the device.

Bulk endpoints

These are unidirectional. They can have the +IN or the OUT direction.

The IN direction means sending packets to +the Host. The OUT direction means receiving packets from the Host.

Bulk +endpoints can supply a maximum of 64 bytes of data per packet, but such transfers +have no guaranteed bus bandwidth.

Interrupt +endpoints

Interrupt endpoints are similar to Bulk endpoints but, +in addition, the endpoint descriptor specifies how often the Host should poll +the endpoint for data. The polling frequency may be anything from 1ms to 255ms.

Isochronous endpoints

Isochronous endpoints can deliver up +to 1023 bytes of data per packet, but there is no retry capability if an error +is detected. Like Interrupt endpoints, they have an associated polling frequency, +which is fixed at 1ms.

Endpoint numbering

Two +numbering schemes are used within the USB implementation. There is also the +external USB address numbering scheme.

Virtual endpoint numbers

Applications +or class drivers use virtual endpoints when communicating with the USB client +driver. These numbers are used when exchanging data over the USB.

Virtual +endpoints range in value from 1 to KMaxEndpointsPerClient, +and applications refer to these endpoints by number when using the user side +handle to the USB client driver.

For applications that implement a +specific USB device class, and which need access to endpoint-0, virtual endpoint-0 +is available. This endpoint is special because it does not belong to any specific +interface. It is always available and, at the interface to the USB client +driver, is the only bi-directional endpoint.

Implementation note

Within the platform independent layer, +virtual endpoint numbers are represented by instances of the internal class TUsbcLogicalEndpoint. +Note that there is no representation for virtual endpoint-0.

Physical endpoints

Physical (or 'real') endpoints are used +at the interface between the platform independent layer and the platform specific +layer within the USB client controller. They represent endpoints physically +present on a given device.

Implementation note

Within the platform independent layer, +physical endpoint numbers are represented by instances of the internal class TUsbcPhysicalEndpoint, +in the array represented by the internal data member DUsbClientController::iRealEndPoints.

To +simplify array indexing, the numbering scheme uses "transformed" USB endpoint +addresses. We represent each channel as a separate endpoint, RX (OUT) channel +as iRealEndpoints[n] and TX (IN) channel as iRealEndpoints[n ++ 1].

Canonical endpoint numbers

The +two layers of the USB client controller, i.e. the Platform Independent layer +and the Platform Specific layer, use a numbering system known as canonical +endpoint numbers when communicating between each other. The physical endpoint +numbers are never used explicitly.

This system is based upon the physical +endpoint number, but takes the direction of the endpoint into account. If r is +the physical endpoint number, then the corresponding canonical endpoint number +is a value defined as:

2r + 1
if +the endpoint direction is IN
2r
if +the endpoint direction is OUT

This means that canonical endpoint numbers fall into a range from +0 to 31.

For example, Endpoint 0 (Ep0) is represented by 2 canonical +endpoint numbers:

0, representing Ep0(OUT)
1, representing Ep0(IN).

Converting between Endpoint +number representations

It is possible to convert between the Endpoint +Address representation and the Canonical Endpoint. The following text explains +how these values are stored in memory and shows the conversion process:

Endpoint Address

where the numbers 0-7 represent bits 0-7 of the byte containing the +endpoint address.

D = Direction: 0 = Receive/IN, 1 = Transmit/OUT

P3 +P2 P1 P0 represents the physical endpoint number (0-15)

+ +

Canonical Endpoint Number

The canonical endpoint number is +just the endpoint address rotated left by 1 bit as shown below:

+ +

Summary +of Endpoint Number Representations

The APIs use the following +conventions for representing endpoint numbers types:

+ + + +

Name

Endpoint number

+ + +

aRealEndpoint

Canonical Endpoint Number

+ + +

aEndpointNum

Virtual Endpoint Number

+ + +

aAddress

Endpoint Address

+ + +

n/a

Physical Endpoint Number

+ + + +