/*\r
LUFA Library\r
- Copyright (C) Dean Camera, 2009.\r
+ Copyright (C) Dean Camera, 2010.\r
\r
dean [at] fourwalledcubicle [dot] com\r
www.fourwalledcubicle.com\r
*/\r
\r
/*\r
- Copyright 2009 Dean Camera (dean [at] fourwalledcubicle [dot] com)\r
+ Copyright 2010 Dean Camera (dean [at] fourwalledcubicle [dot] com)\r
\r
Permission to use, copy, modify, distribute, and sell this \r
software and its documentation for any purpose is hereby granted\r
* <td bgcolor="#00EE00">Yes</td>\r
* </tr>\r
* </table>\r
+ *\r
+ *\r
+ * \section Sec_UsingClassDrivers Using the Class Drivers\r
+ * To make the Class drivers easy to integrate into a user application, they all implement a standardized\r
+ * design with similarly named/used function, enums, defines and types. The two different modes are implemented\r
+ * slightly differently, and thus will be explained separately. For information on a specific class driver, read\r
+ * the class driver's module documentation.\r
+ *\r
+ * \subsection SSec_ClassDriverDevice Device Mode Class Drivers\r
+ * Implementing a Device Mode Class Driver in a user application requires a number of steps to be followed. Firstly,\r
+ * the module configuration and state structure must be added to the project source. These structures are named in a \r
+ * similar manner between classes, that of <i>USB_ClassInfo_<b>{Class Name}</b>_Device_t</i>, and are used to hold the\r
+ * complete state and configuration for each class instance. Multiple class instances is where the power of the class \r
+ * drivers lie; multiple interfaces of the same class simply require more instances of the Class Driver's ClassInfo \r
+ * structure.\r
+ *\r
+ * Inside the ClassInfo structure lies two sections, a <i>Config</i> section, and a <i>State</i> section. The Config\r
+ * section contains the instance's configuration parameters, and <b>must have all fields set by the user application</b>\r
+ * before the class driver is used. Each Device mode Class driver typically contains a set of configuration parameters\r
+ * for the endpoint size/number of the associated logical USB interface, plus any class-specific configuration parameters.\r
+ *\r
+ * The <i>State</i> section of the ClassInfo structures are designed to be controlled by the Class Drivers only for\r
+ * maintaining the Class Driver instance's state, and should not normally be set by the user application.\r
+ *\r
+ * The following is an example of a properly initialized instance of the Audio Class Driver structure:\r
+ *\r
+ * \code\r
+ * USB_ClassInfo_Audio_Device_t My_Audio_Interface =\r
+ * {\r
+ * .Config =\r
+ * {\r
+ * .StreamingInterfaceNumber = 1,\r
+ * \r
+ * .DataINEndpointNumber = 1,\r
+ * .DataINEndpointSize = 256,\r
+ * },\r
+ * };\r
+ * \endcode\r
+ *\r
+ * \note The class driver's configuration parameters should match those used in the device's descriptors that are\r
+ * sent to the host.\r
+ *\r
+ * To initialize the Class driver instance, the driver's <i><b>{Class Name}</b>_Device_ConfigureEndpoints()</i> function\r
+ * should be called in response to the \ref EVENT_USB_Device_ConfigurationChanged() event. This function will return a\r
+ * boolean value if the driver sucessfully initialized the instance. Like all the class driver functions, this function\r
+ * takes in the address of the specific instance you wish to initialize - in this manner, multiple seperate instances of\r
+ * the same class type can be initialized like thus:\r
+ *\r
+ * \code\r
+ * void EVENT_USB_Device_ConfigurationChanged(void)\r
+ * {\r
+ * LEDs_SetAllLEDs(LEDMASK_USB_READY);\r
+ * \r
+ * if (!(Audio_Device_ConfigureEndpoints(&My_Audio_Interface)))\r
+ * LEDs_SetAllLEDs(LEDMASK_USB_ERROR);\r
+ * }\r
+ * \endcode\r
+ * \r
+ * Once initialized, it is important to maintain the class driver's state by repeatedly calling the Class Driver's\r
+ * <i><b>{Class Name}</b>_Device_USBTask()</i> function in the main program loop. The exact implementation of this\r
+ * function varies between class drivers, and can be used for any internal class driver purpose to maintain each\r
+ * instance. Again, this function uses the address of the instance to operate on, and thus needs to be called for each\r
+ * seperate instance, just like the main USB maintenance routine \ref USB_USBTask():\r
+ *\r
+ * \code\r
+ * int main(void)\r
+ * {\r
+ * SetupHardware();\r
+ * \r
+ * LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);\r
+ * \r
+ * for (;;)\r
+ * {\r
+ * Create_And_Process_Samples();\r
+ * \r
+ * Audio_Device_USBTask(&My_Audio_Interface);\r
+ * USB_USBTask();\r
+ * }\r
+ * }\r
+ * \endcode\r
+ *\r
+ * The final standardized Device Class Driver function is the Control Request handler function\r
+ * <i><b>{Class Name}</b>_Device_ProcessControlRequest()</i>, which should be called when the\r
+ * \ref EVENT_USB_Device_UnhandledControlRequest() event fires. This function should also be\r
+ * called for each class driver instance, using the address of the instance to operate on as\r
+ * the function's parameter. The request handler will abort if it is determined that the current\r
+ * request is not targeted at the given class driver instance, thus these methods can safely be\r
+ * called one-after-another in the event handler with no form of error checking:\r
+ *\r
+ * \code\r
+ * void EVENT_USB_Device_UnhandledControlRequest(void)\r
+ * {\r
+ * Audio_Device_ProcessControlRequest(&My_Audio_Interface);\r
+ * }\r
+ * \endcode\r
+ *\r
+ * Each class driver may also define a set of callback functions (which are prefixed by "CALLBACK_"\r
+ * in the function's name) which <b>must</b> also be added to the user application - refer to each\r
+ * individual class driver's documentation for mandatory callbacks. In addition, each class driver may\r
+ * also define a set of events (identifiable by their prefix of "EVENT_" in the function's name), which\r
+ * the user application <b>may</b> choose to implement, or ignore if not needed.\r
+ *\r
+ * The individual Device Mode Class Driver documentation contains more information on the non-standardized,\r
+ * class-specific functions which the user application can then use on the driver instances, such as data\r
+ * read and write routines. See each driver's individual documentation for more information on the\r
+ * class-specific functions.\r
+ *\r
+ * \subsection SSec_ClassDriverHost Host Mode Class Drivers\r
+ * Implementing a Host Mode Class Driver in a user application requires a number of steps to be followed. Firstly,\r
+ * the module configuration and state structure must be added to the project source. These structures are named in a \r
+ * similar manner between classes, that of <i>USB_ClassInfo_<b>{Class Name}</b>_Host_t</i>, and are used to hold the\r
+ * complete state and configuration for each class instance. Multiple class instances is where the power of the class \r
+ * drivers lie; multiple interfaces of the same class simply require more instances of the Class Driver's ClassInfo \r
+ * structure.\r
+ *\r
+ * Inside the ClassInfo structure lies two sections, a <i>Config</i> section, and a <i>State</i> section. The Config\r
+ * section contains the instance's configuration parameters, and <b>must have all fields set by the user application</b>\r
+ * before the class driver is used. Each Device mode Class driver typically contains a set of configuration parameters\r
+ * for the endpoint size/number of the associated logical USB interface, plus any class-specific configuration parameters.\r
+ *\r
+ * The <i>State</i> section of the ClassInfo structures are designed to be controlled by the Class Drivers only for\r
+ * maintaining the Class Driver instance's state, and should not normally be set by the user application.\r
+ *\r
+ * The following is an example of a properly initialized instance of the MIDI Class Driver structure:\r
+ *\r
+ * \code\r
+ * USB_ClassInfo_MIDI_Host_t My_MIDI_Interface =\r
+ * {\r
+ * .Config =\r
+ * {\r
+ * .DataINPipeNumber = 1,\r
+ * .DataINPipeDoubleBank = false,\r
+ * \r
+ * .DataOUTPipeNumber = 2,\r
+ * .DataOUTPipeDoubleBank = false,\r
+ * },\r
+ * };\r
+ * \endcode\r
+ *\r
+ * To initialize the Class driver instance, the driver's <i><b>{Class Name}</b>_Host_ConfigurePipes()</i> function\r
+ * should be called in response to the host state machine entering the \ref HOST_STATE_Addressed state. This function\r
+ * will return an error code from the class driver's <i><b>{Class Name}</b>_EnumerationFailure_ErrorCodes_t</i> enum\r
+ * to indicate if the driver sucessfully initialized the instance and bound it to an interface in the attached device.\r
+ * Like all the class driver functions, this function takes in the address of the specific instance you wish to initialize\r
+ * - in this manner, multiple seperate instances of the same class type can be initialized. A fragment of a Class Driver\r
+ * based Host mode application may look like the following:\r
+ *\r
+ * \code\r
+ * switch (USB_HostState)\r
+ * {\r
+ * case HOST_STATE_Addressed:\r
+ * LEDs_SetAllLEDs(LEDMASK_USB_ENUMERATING);\r
+ * \r
+ * uint16_t ConfigDescriptorSize;\r
+ * uint8_t ConfigDescriptorData[512];\r
+ *\r
+ * if (USB_Host_GetDeviceConfigDescriptor(1, &ConfigDescriptorSize, ConfigDescriptorData,\r
+ * sizeof(ConfigDescriptorData)) != HOST_GETCONFIG_Successful)\r
+ * {\r
+ * LEDs_SetAllLEDs(LEDMASK_USB_ERROR);\r
+ * USB_HostState = HOST_STATE_WaitForDeviceRemoval;\r
+ * break;\r
+ * }\r
+ *\r
+ * if (MIDI_Host_ConfigurePipes(&My_MIDI_Interface,\r
+ * ConfigDescriptorSize, ConfigDescriptorData) != MIDI_ENUMERROR_NoError)\r
+ * {\r
+ * LEDs_SetAllLEDs(LEDMASK_USB_ERROR);\r
+ * USB_HostState = HOST_STATE_WaitForDeviceRemoval;\r
+ * break;\r
+ * }\r
+ *\r
+ * // Other state handler code here\r
+ * \endcode\r
+ *\r
+ * Note that the function also required the device's configuration descriptor so that it can determine which interface\r
+ * in the device to bind to - this can be retrieved as shown in the above fragment using the\r
+ * \ref USB_Host_GetDeviceConfigDescriptor() function. If the device does not implement the interface the class driver\r
+ * is looking for, if all the matching interfaces are already bound to class driver instances or if an error occurs while\r
+ * binding to a device interface (for example, a device endpoint bank larger that the maximum supported bank size is used)\r
+ * the configuration will fail.\r
+ *\r
+ * Once initialized, it is important to maintain the class driver's state by repeatedly calling the Class Driver's\r
+ * <i><b>{Class Name}</b>_Host_USBTask()</i> function in the main program loop. The exact implementation of this\r
+ * function varies between class drivers, and can be used for any internal class driver purpose to maintain each\r
+ * instance. Again, this function uses the address of the instance to operate on, and thus needs to be called for each\r
+ * seperate instance, just like the main USB maintenance routine \ref USB_USBTask():\r
+ *\r
+ * \code\r
+ * int main(void)\r
+ * {\r
+ * SetupHardware();\r
+ * \r
+ * LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);\r
+ * \r
+ * for (;;)\r
+ * {\r
+ * switch (USB_HostState)\r
+ * {\r
+ * // Host state machine handling here\r
+ * } \r
+ * \r
+ * MIDI_Host_USBTask(&My_Audio_Interface);\r
+ * USB_USBTask();\r
+ * }\r
+ * }\r
+ * \endcode\r
+ *\r
+ * Each class driver may also define a set of callback functions (which are prefixed by "CALLBACK_"\r
+ * in the function's name) which <b>must</b> also be added to the user application - refer to each\r
+ * individual class driver's documentation for mandatory callbacks. In addition, each class driver may\r
+ * also define a set of events (identifiable by their prefix of "EVENT_" in the function's name), which\r
+ * the user application <b>may</b> choose to implement, or ignore if not needed.\r
+ *\r
+ * The individual Host Mode Class Driver documentation contains more information on the non-standardized,\r
+ * class-specific functions which the user application can then use on the driver instances, such as data\r
+ * read and write routines. See each driver's individual documentation for more information on the\r
+ * class-specific functions.\r
*/\r
\r
#ifndef __USB_H__\r
#define __USB_H__\r
\r
+ /* Macros: */\r
+ #if !defined(__DOXYGEN__)\r
+ #define __INCLUDE_FROM_USB_DRIVER\r
+ #endif\r
+\r
/* Includes: */\r
#include "HighLevel/USBMode.h"\r
\r
projects / pub / USBasp.git / blobdiff