| LUFA Library 140302 |

All Data Structures Files Functions Variables Typedefs Enumerations Enumerator Macros Groups Pages
Modules
USB Class Drivers

Drivers for the various standardized USB device classes. More...

## Modules
| Android Open Accessory Class Driver
| USB class driver for the Google Android Open Accessory class standard.
| Audio 1.0 Class Driver
| USB class driver for the USB-IF Audio 1.0 class standard.
| CDC-ACM (Virtual Serial) Class Driver
| USB class driver for the USB-IF CDC-ACM (Virtual Serial) class standard.
| HID Class Driver
| USB class driver for the USB-IF Human Interface Device (HID) class standard.
| MIDI Class Driver
| USB class driver for the USB-IF MIDI class standard.
| Mass Storage Class Driver
| USB class driver for the USB-IF Bulk-Only Transport Mass Storage class standard.
| Printer Class Driver
| USB class driver for the USB-IF Printer class standard.
| RNDIS (Networking) Class Driver
| USB class driver for the Microsoft Remote Network Driver Interface Specification (RNDIS) class standard.
| Still Image Class Driver
| USB class driver for the USB-IF Still Image (PIMA-compliant) class standard.

## Detailed Description

Drivers for both host and device mode of the standard USB classes, for rapid application development. Class drivers give a framework which sits on top of the low level library API, allowing for standard USB classes to be implemented in a project with minimal user code. These drivers can be used in conjunction with the library low level APIs to implement interfaces both via the class drivers and via the standard library APIs.

Multiple device mode class drivers can be used within a project, including multiple instances of the same class driver. In this way, USB Hosts and Devices can be made quickly using the internal class drivers so that more time and effort can be put into the end application instead of the USB protocol.

The available class drivers and their modes are listed below.

USB Class | Device Mode | Host Mode
--- | --- | ---
Android Open Accessory | No | Yes
Audio 1.0 | Yes | Yes
CDC-ACM | Yes | Yes
HID | Yes | Yes
MIDI | Yes | Yes
Mass Storage | Yes | Yes
Printer | Yes | Yes
RNDIS | Yes | Yes
Still Image | No | Yes

# Using the Class Drivers

To make the Class drivers easy to integrate into a user application, they all implement a standardized design with similarly named/used function, enums, defines and types. The two different modes are implemented slightly differently, and thus will be explained separately. For information on a specific class driver, read the class driver's module documentation.

## Device Mode Class Drivers

Implementing a Device Mode Class Driver in a user application requires a number of steps to be followed. Firstly, the module configuration and state structure must be added to the project source. These structures are named in a similar manner between classes, that of `USB_ClassInfo_{Class Name}_Device_t`, and are used to hold the complete state and configuration for each class instance. Multiple class instances is where the power of the class drivers lie; multiple interfaces of the same class simply require more instances of the Class Driver's `USB_ClassInfo_*` structure.

Inside the ClassInfo structure lies two sections, a `Config` section, and a `State` section. The `Config` section contains the instance's configuration parameters, and must have all fields set by the user application before the class driver is used. Each Device mode Class driver typically contains a set of configuration parameters for the endpoint size/number of the associated logical USB interface, plus any class-specific configuration parameters.

The following is an example of a properly initialized instance of the Audio Class Driver structure:

USB_ClassInfo_Audio_Device_t My_Audio_Interface =
{
.Config =
{
.StreamingInterfaceNumber = 1,
.DataINEndpoint =
{
.Address = (ENDPOINT_DIR_IN | 1),
.Size = 64,
.Banks = 1,
},
},
};

Note
  The class driver's configuration parameters should match those used in the device's descriptors that are sent to the host.

To initialize the Class driver instance, the driver's `{Class Name}_Device_ConfigureEndpoints()` function should be called in response to the EVENT_USB_Device_ConfigurationChanged() event. This function will return a boolean true value if the driver successfully initialized the instance. Like all the class driver functions, this function takes in the address of the specific instance you wish to initialize - in this manner, multiple separate instances of the same class type can be initialized like this:

void EVENT_USB_Device_ConfigurationChanged(void)
{
LEDs_SetAllLEDs(LEDMASK_USB_READY);
if (!(Audio_Device_ConfigureEndpoints(&My_Audio_Interface)))
LEDs_SetAllLEDs(LEDMASK_USB_ERROR);
}

Once initialized, it is important to maintain the class driver's state by repeatedly calling the Class Driver's `{Class Name}_Device_USBTask()` function in the main program loop. The exact implementation of this function varies between class drivers, and can be used for any internal class driver purpose to maintain each instance. Again, this function uses the address of the instance to operate on, and thus needs to be called for each separate instance, just like the main USB maintenance routine USB_USBTask():

int main(void)
{
SetupHardware();
LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
for (;;)
{
if (USB_DeviceState != DEVICE_STATE_Configured)
Create_And_Process_Samples();
Audio_Device_USBTask(&My_Audio_Interface);
USB_USBTask();
}
}

The final standardized Device Class Driver function is the Control Request handler function `{Class Name}_Device_ProcessControlRequest()`, which should be called when the EVENT_USB_Device_ControlRequest() event fires. This function should also be called for each class driver instance, using the address of the instance to operate on as the function's parameter. The request handler will abort if it is determined that the current request is not targeted at the given class driver instance, thus these methods can safely be called one-after-another in the event handler with no form of error checking:

void EVENT_USB_Device_ControlRequest(void)
{
Audio_Device_ProcessControlRequest(&My_Audio_Interface);
}

Each class driver may also define a set of callback functions (which are prefixed by `CALLBACK_*` in the function's name) which must also be added to the user application - refer to each individual class driver's documentation for mandatory callbacks. In addition, each class driver may also define a set of events (identifiable by their prefix of `EVENT_*` in the function's name), which the user application may choose to implement, or ignore if not needed.

The individual Device Mode Class Driver documentation contains more information on the non-standardized, class-specific functions which the user application can then use on the driver instances, such as data read and write routines. See each driver's individual documentation for more information on the class-specific functions.

## Host Mode Class Drivers

Implementing a Host Mode Class Driver in a user application requires a number of steps to be followed. Firstly, the module configuration and state structure must be added to the project source. These structures are named in a similar manner between classes, that of `USB_ClassInfo_{Class Name}_Host_t`, and are used to hold the complete state and configuration for each class instance. Multiple class instances is where the power of the class drivers lie; multiple interfaces of the same class simply require more instances of the Class Driver's `USB_ClassInfo_*` structure.

Inside the `USB_ClassInfo_*` structure lies two sections, a `Config` section, and a `State` section. The `Config` section contains the instance's configuration parameters, and must have all fields set by the user application before the class driver is used. Each Device mode Class driver typically contains a set of configuration parameters for the endpoint size/number of the associated logical USB interface, plus any class-specific configuration parameters.

The following is an example of a properly initialized instance of the MIDI Host Class Driver structure:

USB_ClassInfo_MIDI_Host_t My_MIDI_Interface =
{
.Config =
{
.DataINPipe =
{
.Address = (PIPE_DIR_IN | 1),
.Size = 64,
.Banks = 1,
},
.DataOUTPipe =
{
.Address = (PIPE_DIR_OUT | 2),
.Size = 64,
.Banks = 1,
},
},
};

To initialize the Class driver instance, the driver's `{Class Name}_Host_ConfigurePipes()` function should be called in response to the `EVENT_USB_Host_DeviceEnumerationComplete()` event firing. This function will will return an error code from the class driver's `{Class Name}_EnumerationFailure_ErrorCodes_t` enum to indicate if the driver successfully initialized the instance and bound it to an interface in the attached device. Like all the class driver functions, this function takes in the address of the specific instance you wish to initialize - in this manner, multiple separate instances of the same class type can be initialized. A fragment of a Class Driver based Host mode application may look like the following:

void EVENT_USB_Host_DeviceEnumerationComplete(void)
{
LEDs_SetAllLEDs(LEDMASK_USB_ENUMERATING);
uint16_t ConfigDescriptorSize;
uint8_t ConfigDescriptorData[512];
if (USB_Host_GetDeviceConfigDescriptor(1, &ConfigDescriptorSize, ConfigDescriptorData,
sizeof(ConfigDescriptorData)) != HOST_GETCONFIG_Successful)
{
LEDs_SetAllLEDs(LEDMASK_USB_ERROR);
return;
}
if (MIDI_Host_ConfigurePipes(&Keyboard_MIDI_Interface,
ConfigDescriptorSize, ConfigDescriptorData) != MIDI_ENUMERROR_NoError)
{
LEDs_SetAllLEDs(LEDMASK_USB_ERROR);
return;
}
if (USB_Host_SetDeviceConfiguration(1) != HOST_SENDCONTROL_Successful)
{
LEDs_SetAllLEDs(LEDMASK_USB_ERROR);
return;
}
LEDs_SetAllLEDs(LEDMASK_USB_READY);
}

Note that the function also requires the device's configuration descriptor so that it can determine which interface in the device to bind to - this can be retrieved as shown in the above fragment using the USB_Host_GetDeviceConfigDescriptor() function. If the device does not implement the interface the class driver is looking for, if all the matching interfaces are already bound to class driver instances or if an error occurs while binding to a device interface (for example, a device endpoint bank larger that the maximum supported bank size is used) the configuration will fail.

To complete the device enumeration after binding the host mode Class Drivers to the attached device, a call to `USB_Host_SetDeviceConfiguration()` must be made. If the device configuration is not set within the `EVENT_USB_Host_DeviceEnumerationComplete()` event, the host still will assume the device enumeration has failed.

Once initialized, it is important to maintain the class driver's state by repeatedly calling the Class Driver's `{Class Name}_Host_USBTask()` function in the main program loop. The exact implementation of this function varies between class drivers, and can be used for any internal class driver purpose to maintain each instance. Again, this function uses the address of the instance to operate on, and thus needs to be called for each separate instance, just like the main USB maintenance routine USB_USBTask():

int main(void)
{
SetupHardware();
LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
for (;;)
{
if (USB_HostState != HOST_STATE_Configured)
Create_And_Process_Samples();
MIDI_Host_USBTask(&My_Audio_Interface);
USB_USBTask();
}
}

Each class driver may also define a set of callback functions (which are prefixed by `CALLBACK_*` in the function's name) which must also be added to the user application - refer to each individual class driver's documentation for mandatory callbacks. In addition, each class driver may also define a set of events (identifiable by their prefix of `EVENT_*` in the function's name), which the user application may choose to implement, or ignore if not needed.

The individual Host Mode Class Driver documentation contains more information on the non-standardized, class-specific functions which the user application can then use on the driver instances, such as data read and write routines. See each driver's individual documentation for more information on the class-specific functions.