2.1.3 USB Device Library - Application Interaction

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

The following figure outlines the steps necessary for the application to utilize the USB Device Library:

Figure 2-2. Application Interaction with Device Layer

The application must begin by initializing the Device Layer. This involves defining the Device Layer initialization structure, which requires the initialization of the following data structures:

  • 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.

Figure 2-3. 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. When the application receives a device configured event, it must register event handlers for each function driver relevant to the configuration that was set. The registration of the function driver event handler must be done in the context of the device configured event because the Device Layer acknowledges the set configuration request from the host when it exits the device configured event handler context. At this point, the application should be ready to respond to function driver events. The application can use the device deconfigured event to reinitialize its internal state machine.

Note: Failing to register the function driver event handler in the Device Layer's configured event context could cause the device to not respond to host requests and, therefore, become non-compliant.

Once configured, the device is now ready to serve its intended function via USB. The application interacts with the Device Layer and function drivers through API functions and event handlers. The application must be aware of function driver events that require an application response. For example, the USB_DEVICE_CDC_EVENT_SET_LINE_CODING event from the USB Device CDC Function Driver requires the application to respond with a USB_DEVICE_ControlReceive()function. This function provides the buffer to receive the line coding parameters that the Host sends during 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.

Figure 2-4. 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.

Deferring Control Transfer Responses

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.