Note:

Additional information on USB demonstration application projects is available in the USB Demonstrations section.

The following figure highlights the steps that the application must follow to use the USB Device Library.

Application Interaction with Device Layer 

The application must first initialize the Device Layer. As a part of the Device Layer initialization process, the Device Layer initialization structure must be defined which in turn requires the following data structures to be designed

• The master descriptor table
• The function driver registration table

The following figure shows a pictorial representation of the data that forms the Device Layer initialization structure. Additional information on Device Layer initialization is available in the Device Layer Help File.

Device Layer Initialization 

After successful initialization of the Device_layer, the application can open the Device_layer and register a Device_layer event handler. The Device_layer event handler receives device level events such as device configured, device deconfigured, device reset and device suspended. The device configured event and deconfigured event are important. The application can use the device deconfigured event to reinitialize its internal state machine. When the application receives a device configured event, it must register event handlers for each function driver that is relevant to the configuration that was set. The function driver event handler registration must be done in the device configured event context because the Device_layer acknowledges the set configuration request from the host when it exits the device configured event handler context. The application at this point should be ready to respond to function driver events.

Note:

Not registering the function driver event handler in the Device_layer configured event could cause the device to not respond to the host requests and therefore, be non-compliant.

Once configured, the device is now ready to serve its intended function on the USB. The application interacts with the Device_layer and function drivers through API function and event handlers. The application must be aware of function driver events which require application response. For example, the USB_DEVICE_CDC_EVENT_SET_LINE_CODING event from the USB CDC Function Driver requires the application to respond with a USB_DEVICE_ControlRead function. This function provides the buffer to receive the line coding parameters that the Host sends in the data stage of the Set Line Coding control transfer. 

The following figure shows the application interaction with Device_layer and function driver after the device has been configured.

Application - Device Layer Interaction after device configuration 

In the previous figure, the application should have registered the Device_layer event handler before attaching the device on the bus. It should have registered the function driver event handler before exiting the device configured - Device_layer event. The application will then receive function driver instance specific events via the function driver event handlers.

Class-specific control transfer related function driver events require the application to complete the data stage and/or the status of the control transfer. The application does this by using the Device Layer Control Transfer API to complete the Control Read/Write transfers. The application may typically be able the complete required data processing, and to continue (or end) the control transfer within the function driver event handler context. However, there could be cases where the required control transfer data processing may require hardware access or extended computation. Performing extended processing or waiting for external hardware within the function driver event handler context is not recommended as the USB 2.0 Specification places restrictions on the control transfer response time. 

In cases where the application is not ready to respond to control transfer requests within the function driver event handler context, the USB Device Library provides the option of deferring the response to the control transfer event. The application can respond to the control transfer request after exiting the handler function. The application must still observe the USB 2.0 Specification control transfer timing requirements while responding to the control transfer. Deferring the response in such a manner provides the application with flexibility to analyze the control transfer without degrading the performance of the device on the USB.