Architecture

Symbian platform provides access to USB client hardware through its USB +client driver.

The following diagram shows the USB client architecture. Devices can provide +more than one USB function. To better show the typical use, the diagram shows +the components in use with a phone that is configured as a combined +WHCM and OBEX peripheral.

+ + + +

There are three main elements:

The user side interface +to the USB client driver.
The USB client driver +LDD that provides the driver's logical channel. This is hardware independent.
The PDD, or client controller, +that manages access to the USB client hardware.

User API

The user side interface to the USB client +driver is provided by RDevUsbcClient. The user side interface +is implemented as a set of inline functions and means that there is no separate +user side library component. This is typically the case for device drivers.

USB client +driver (LDD)

The USB client driver provides an interface to the +USB client device. The USB client driver is also referred to as a channel to +the USB client device; it may also be referred to as the USB logical device +driver.

Each user component that requires a connection to the USB +client device opens a channel using the user side RDevUsbcClient class.

A +channel supports only one USB interface. A channel (i.e. the USB LDD) can +be loaded as many times as needed; the decision is based on the number of +interfaces required. This can be done either in the same process or in a different +process depending on the relationship between the interfaces.

If there +is more than one channel open on the USB client device, then they can all +share Control Endpoint 0 (Ep0). Each channel can make a request on this endpoint. +The other endpoints cannot be shared between channels; instead each endpoint +is used exclusively by one, and only one, channel.

Each channel can +claim up to a maximum of five endpoints in addition to Ep0. Each endpoint +claimed on a channel is locally numbered from one and five. This number need +not correspond to the actual endpoint number of the hardware interface; this +number is called the logical endpoint number, and all transfer requests use +the logical number for the endpoint. A driver can, however, discover the physical +endpoint address of a logical endpoint by requesting the endpoint descriptor.

A +channel can have asynchronous requests outstanding on one or more of its endpoints +simultaneously; this includes Ep0. As Ep0 can be shared between channels, +then the underlying USB Controller must manage multiple requests on this endpoint

USB client +controller (PDD)

The USB client controller manages access to the +USB client hardware on behalf of all USB client drivers. It has a two layer +implementation:

a licensee product independent +layer that provides an API for the USB client driver. This is often referred +to as the Platform Independent Layer, and forms the 'upper' part of the USB +physical device driver (PDD).
a layer that interfaces +with the hardware. This is often referred to as the Platform Specific Layer, +and forms the 'lower' part of the USB physical device driver (PDD). It +is this part that needs porting effort.

The Platform Independent Layer contains, as far as possible, the +functionality that is defined in the USB specification. This includes the +‘Chapter 9’ device state handling and request processing. The Platform Specific +Layer contains only that functionality which cannot be abstracted and made +generic, because different USB Device Controller designs are programmed differently +and operate differently.

The complete USB client controller (PDD) +is an instance of a DUsbClientController derived class +and is implemented as a kernel extension named usbcc.dll.

The +functionality of the Platform Independent Layer is provided by the base class DUsbClientController. +This class also defines a large number of pure virtual functions that are +intended to provide the functionality that is not part of the USB specification, +but is specific to the USB Device Controller. Such functions typically implement +direct USB Device Controller hardware manipulation, register access, endpoint +FIFO loading/unloading etc. The platform specific layer provides the implementation +for these pure virtual functions by defining and implementing a device specific +class derived from DUsbClientController.