Architecture
Describes the USB client 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.