-/*\r
- LUFA Library\r
- Copyright (C) Dean Camera, 2010.\r
- \r
- dean [at] fourwalledcubicle [dot] com\r
- www.fourwalledcubicle.com\r
-*/\r
-\r
-/*\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
- without fee, provided that the above copyright notice appear in \r
- all copies and that both that the copyright notice and this\r
- permission notice and warranty disclaimer appear in supporting \r
- documentation, and that the name of the author not be used in \r
- advertising or publicity pertaining to distribution of the \r
- software without specific, written prior permission.\r
-\r
- The author disclaim all warranties with regard to this\r
- software, including all implied warranties of merchantability\r
- and fitness. In no event shall the author be liable for any\r
- special, indirect or consequential damages or any damages\r
- whatsoever resulting from loss of use, data or profits, whether\r
- in an action of contract, negligence or other tortious action,\r
- arising out of or in connection with the use or performance of\r
- this software.\r
-*/\r
-\r
-/** \file\r
- * \brief Master include file for the library USB functionality.\r
- *\r
- * Master include file for the library USB functionality.\r
- *\r
- * This file should be included in all user projects making use of the USB portions of the library, instead of\r
- * including any headers in the USB/LowLevel/ or USB/HighLevel/ subdirectories.\r
- */\r
-\r
-/** @defgroup Group_USB USB - LUFA/Drivers/USB/USB.h\r
- *\r
- * \section Sec_Dependencies Module Source Dependencies\r
- * The following files must be built with any user project that uses this module:\r
- * - LUFA/Drivers/USB/LowLevel/DevChapter9.c\r
- * - LUFA/Drivers/USB/LowLevel/Endpoint.c\r
- * - LUFA/Drivers/USB/LowLevel/Host.c\r
- * - LUFA/Drivers/USB/LowLevel/HostChapter9.c\r
- * - LUFA/Drivers/USB/LowLevel/LowLevel.c\r
- * - LUFA/Drivers/USB/LowLevel/Pipe.c\r
- * - LUFA/Drivers/USB/LowLevel/USBInterrupt.c\r
- * - LUFA/Drivers/USB/HighLevel/ConfigDescriptor.c\r
- * - LUFA/Drivers/USB/HighLevel/Events.c\r
- * - LUFA/Drivers/USB/HighLevel/USBTask.c\r
- *\r
- * \section Module Description\r
- * Driver and framework for the USB controller hardware on the USB series of AVR microcontrollers. This module\r
- * consists of many submodules, and is designed to provide an easy way to configure and control USB host, device\r
- * or OTG mode USB applications.\r
- *\r
- * The USB stack requires the sole control over the USB controller in the microcontroller only; i.e. it does not\r
- * require any additional AVR timers, etc. to operate. This ensures that the USB stack requires as few resources\r
- * as possible.\r
- *\r
- * The USB stack can be used in Device Mode for connections to USB Hosts (see \ref Group_Device), in Host mode for\r
- * hosting of other USB devices (see \ref Group_Host), or as a dual role device which can either act as a USB host\r
- * or device depending on what peripheral is connected (see \ref Group_OTG). Both modes also require a common set\r
- * of USB management functions found \ref Group_USBManagement.\r
- */\r
-\r
-/** \ingroup Group_USB\r
- * @defgroup Group_USBClassDrivers USB Class Drivers\r
- *\r
- * Drivers for both host and device mode of the standard USB classes, for rapid application development.\r
- * Class drivers give a framework which sits on top of the low level library API, allowing for standard\r
- * USB classes to be implemented in a project with minimal user code. These drivers can be used in\r
- * conjunction with the library low level APIs to implement interfaces both via the class drivers and via\r
- * the standard library APIs.\r
- *\r
- * Multiple device mode class drivers can be used within a project, including multiple instances of the\r
- * same class driver. In this way, USB Hosts and Devices can be made quickly using the internal class drivers\r
- * so that more time and effort can be put into the end application instead of the USB protocol.\r
- *\r
- * The available class drivers and their modes are listed below.\r
- *\r
- * <table>\r
- * <tr>\r
- * <th width="100px">USB Class</th> \r
- * <th width="90px">Device Mode</th> \r
- * <th width="90px">Host Mode</th> \r
- * </tr>\r
- * <tr>\r
- * <td>Audio</td>\r
- * <td bgcolor="#00EE00">Yes</td>\r
- * <td bgcolor="#EE0000">No</td>\r
- * </tr>\r
- * <tr>\r
- * <td>CDC</td>\r
- * <td bgcolor="#00EE00">Yes</td>\r
- * <td bgcolor="#00EE00">Yes</td>\r
- * </tr>\r
- * <tr>\r
- * <td>HID</td>\r
- * <td bgcolor="#00EE00">Yes</td>\r
- * <td bgcolor="#00EE00">Yes</td>\r
- * </tr>\r
- * <tr>\r
- * <td>MIDI</td>\r
- * <td bgcolor="#00EE00">Yes</td>\r
- * <td bgcolor="#00EE00">Yes</td>\r
- * </tr>\r
- * <tr>\r
- * <td>Mass Storage</td>\r
- * <td bgcolor="#00EE00">Yes</td>\r
- * <td bgcolor="#00EE00">Yes</td>\r
- * </tr>\r
- * <tr>\r
- * <td>Printer</td>\r
- * <td bgcolor="#EE0000">No</td>\r
-* <td bgcolor="#00EE00">Yes</td>\r
- * </tr>\r
- * <tr>\r
- * <td>RNDIS</td>\r
- * <td bgcolor="#00EE00">Yes</td>\r
- * <td bgcolor="#00EE00">Yes</td>\r
- * </tr>\r
- * <tr>\r
- * <td>Still Image</td>\r
- * <td bgcolor="#EE0000">No</td>\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
- /* Preprocessor Checks: */ \r
- #if (!defined(USB_SERIES_2_AVR) && !defined(USB_SERIES_4_AVR) && \\r
- !defined(USB_SERIES_6_AVR) && !defined(USB_SERIES_7_AVR))\r
- #error The currently selected AVR model is not supported under the USB component of the LUFA library.\r
- #endif\r
- \r
- /* Includes: */\r
- #include "HighLevel/USBTask.h"\r
- #include "HighLevel/Events.h"\r
- #include "HighLevel/StdDescriptors.h"\r
- #include "HighLevel/ConfigDescriptor.h"\r
-\r
- #include "LowLevel/LowLevel.h"\r
- #include "LowLevel/USBInterrupt.h"\r
- \r
- #if defined(USB_CAN_BE_HOST) || defined(__DOXYGEN__)\r
- #include "LowLevel/Host.h"\r
- #include "LowLevel/HostChapter9.h"\r
- #include "LowLevel/Pipe.h"\r
- #endif\r
- \r
- #if defined(USB_CAN_BE_DEVICE) || defined(__DOXYGEN__)\r
- #include "LowLevel/Device.h"\r
- #include "LowLevel/DevChapter9.h"\r
- #include "LowLevel/Endpoint.h"\r
- #endif\r
- \r
- #if defined(USB_CAN_BE_BOTH) || defined(__DOXYGEN__)\r
- #include "LowLevel/OTG.h"\r
- #endif\r
- \r
-#endif\r
-\r
+/*
+ LUFA Library
+ Copyright (C) Dean Camera, 2010.
+
+ dean [at] fourwalledcubicle [dot] com
+ www.fourwalledcubicle.com
+*/
+
+/*
+ Copyright 2010 Dean Camera (dean [at] fourwalledcubicle [dot] com)
+
+ Permission to use, copy, modify, distribute, and sell this
+ software and its documentation for any purpose is hereby granted
+ without fee, provided that the above copyright notice appear in
+ all copies and that both that the copyright notice and this
+ permission notice and warranty disclaimer appear in supporting
+ documentation, and that the name of the author not be used in
+ advertising or publicity pertaining to distribution of the
+ software without specific, written prior permission.
+
+ The author disclaim all warranties with regard to this
+ software, including all implied warranties of merchantability
+ and fitness. In no event shall the author be liable for any
+ special, indirect or consequential damages or any damages
+ whatsoever resulting from loss of use, data or profits, whether
+ in an action of contract, negligence or other tortious action,
+ arising out of or in connection with the use or performance of
+ this software.
+*/
+
+/** \file
+ * \brief Master include file for the library USB functionality.
+ *
+ * Master include file for the library USB functionality.
+ *
+ * This file should be included in all user projects making use of the USB portions of the library, instead of
+ * including any headers in the USB/LowLevel/ or USB/HighLevel/ subdirectories.
+ */
+
+/** @defgroup Group_USB USB - LUFA/Drivers/USB/USB.h
+ *
+ * \section Sec_Dependencies Module Source Dependencies
+ * The following files must be built with any user project that uses this module:
+ * - LUFA/Drivers/USB/LowLevel/DevChapter9.c
+ * - LUFA/Drivers/USB/LowLevel/Endpoint.c
+ * - LUFA/Drivers/USB/LowLevel/Host.c
+ * - LUFA/Drivers/USB/LowLevel/HostChapter9.c
+ * - LUFA/Drivers/USB/LowLevel/LowLevel.c
+ * - LUFA/Drivers/USB/LowLevel/Pipe.c
+ * - LUFA/Drivers/USB/LowLevel/USBInterrupt.c
+ * - LUFA/Drivers/USB/HighLevel/ConfigDescriptor.c
+ * - LUFA/Drivers/USB/HighLevel/Events.c
+ * - LUFA/Drivers/USB/HighLevel/USBTask.c
+ *
+ * \section Module Description
+ * Driver and framework for the USB controller hardware on the USB series of AVR microcontrollers. This module
+ * consists of many submodules, and is designed to provide an easy way to configure and control USB host, device
+ * or OTG mode USB applications.
+ *
+ * The USB stack requires the sole control over the USB controller in the microcontroller only; i.e. it does not
+ * require any additional AVR timers, etc. to operate. This ensures that the USB stack requires as few resources
+ * as possible.
+ *
+ * The USB stack can be used in Device Mode for connections to USB Hosts (see \ref Group_Device), in Host mode for
+ * hosting of other USB devices (see \ref Group_Host), or as a dual role device which can either act as a USB host
+ * or device depending on what peripheral is connected (see \ref Group_OTG). Both modes also require a common set
+ * of USB management functions found \ref Group_USBManagement.
+ */
+
+/** \ingroup Group_USB
+ * @defgroup Group_USBClassDrivers USB Class Drivers
+ *
+ * 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.
+ *
+ * <table>
+ * <tr>
+ * <th width="100px">USB Class</th>
+ * <th width="90px">Device Mode</th>
+ * <th width="90px">Host Mode</th>
+ * </tr>
+ * <tr>
+ * <td>Audio</td>
+ * <td bgcolor="#00EE00">Yes</td>
+ * <td bgcolor="#EE0000">No</td>
+ * </tr>
+ * <tr>
+ * <td>CDC</td>
+ * <td bgcolor="#00EE00">Yes</td>
+ * <td bgcolor="#00EE00">Yes</td>
+ * </tr>
+ * <tr>
+ * <td>HID</td>
+ * <td bgcolor="#00EE00">Yes</td>
+ * <td bgcolor="#00EE00">Yes</td>
+ * </tr>
+ * <tr>
+ * <td>MIDI</td>
+ * <td bgcolor="#00EE00">Yes</td>
+ * <td bgcolor="#00EE00">Yes</td>
+ * </tr>
+ * <tr>
+ * <td>Mass Storage</td>
+ * <td bgcolor="#00EE00">Yes</td>
+ * <td bgcolor="#00EE00">Yes</td>
+ * </tr>
+ * <tr>
+ * <td>Printer</td>
+ * <td bgcolor="#EE0000">No</td>
+* <td bgcolor="#00EE00">Yes</td>
+ * </tr>
+ * <tr>
+ * <td>RNDIS</td>
+ * <td bgcolor="#00EE00">Yes</td>
+ * <td bgcolor="#00EE00">Yes</td>
+ * </tr>
+ * <tr>
+ * <td>Still Image</td>
+ * <td bgcolor="#EE0000">No</td>
+ * <td bgcolor="#00EE00">Yes</td>
+ * </tr>
+ * </table>
+ *
+ *
+ * \section Sec_UsingClassDrivers 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.
+ *
+ * \subsection SSec_ClassDriverDevice 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 <i>USB_ClassInfo_<b>{Class Name}</b>_Device_t</i>, 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 ClassInfo
+ * structure.
+ *
+ * Inside the ClassInfo structure lies two sections, a <i>Config</i> section, and a <i>State</i> section. The Config
+ * section contains the instance's configuration parameters, and <b>must have all fields set by the user application</b>
+ * 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 <i>State</i> section of the ClassInfo structures are designed to be controlled by the Class Drivers only for
+ * maintaining the Class Driver instance's state, and should not normally be set by the user application.
+ *
+ * The following is an example of a properly initialized instance of the Audio Class Driver structure:
+ *
+ * \code
+ * USB_ClassInfo_Audio_Device_t My_Audio_Interface =
+ * {
+ * .Config =
+ * {
+ * .StreamingInterfaceNumber = 1,
+ *
+ * .DataINEndpointNumber = 1,
+ * .DataINEndpointSize = 256,
+ * },
+ * };
+ * \endcode
+ *
+ * \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 <i><b>{Class Name}</b>_Device_ConfigureEndpoints()</i> function
+ * should be called in response to the \ref EVENT_USB_Device_ConfigurationChanged() event. This function will return a
+ * boolean value if the driver sucessfully 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 seperate instances of
+ * the same class type can be initialized like thus:
+ *
+ * \code
+ * void EVENT_USB_Device_ConfigurationChanged(void)
+ * {
+ * LEDs_SetAllLEDs(LEDMASK_USB_READY);
+ *
+ * if (!(Audio_Device_ConfigureEndpoints(&My_Audio_Interface)))
+ * LEDs_SetAllLEDs(LEDMASK_USB_ERROR);
+ * }
+ * \endcode
+ *
+ * Once initialized, it is important to maintain the class driver's state by repeatedly calling the Class Driver's
+ * <i><b>{Class Name}</b>_Device_USBTask()</i> 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
+ * seperate instance, just like the main USB maintenance routine \ref USB_USBTask():
+ *
+ * \code
+ * int main(void)
+ * {
+ * SetupHardware();
+ *
+ * LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
+ *
+ * for (;;)
+ * {
+ * Create_And_Process_Samples();
+ *
+ * Audio_Device_USBTask(&My_Audio_Interface);
+ * USB_USBTask();
+ * }
+ * }
+ * \endcode
+ *
+ * The final standardized Device Class Driver function is the Control Request handler function
+ * <i><b>{Class Name}</b>_Device_ProcessControlRequest()</i>, which should be called when the
+ * \ref EVENT_USB_Device_UnhandledControlRequest() 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:
+ *
+ * \code
+ * void EVENT_USB_Device_UnhandledControlRequest(void)
+ * {
+ * Audio_Device_ProcessControlRequest(&My_Audio_Interface);
+ * }
+ * \endcode
+ *
+ * Each class driver may also define a set of callback functions (which are prefixed by "CALLBACK_"
+ * in the function's name) which <b>must</b> 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 <b>may</b> 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.
+ *
+ * \subsection SSec_ClassDriverHost 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 <i>USB_ClassInfo_<b>{Class Name}</b>_Host_t</i>, 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 ClassInfo
+ * structure.
+ *
+ * Inside the ClassInfo structure lies two sections, a <i>Config</i> section, and a <i>State</i> section. The Config
+ * section contains the instance's configuration parameters, and <b>must have all fields set by the user application</b>
+ * 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 <i>State</i> section of the ClassInfo structures are designed to be controlled by the Class Drivers only for
+ * maintaining the Class Driver instance's state, and should not normally be set by the user application.
+ *
+ * The following is an example of a properly initialized instance of the MIDI Class Driver structure:
+ *
+ * \code
+ * USB_ClassInfo_MIDI_Host_t My_MIDI_Interface =
+ * {
+ * .Config =
+ * {
+ * .DataINPipeNumber = 1,
+ * .DataINPipeDoubleBank = false,
+ *
+ * .DataOUTPipeNumber = 2,
+ * .DataOUTPipeDoubleBank = false,
+ * },
+ * };
+ * \endcode
+ *
+ * To initialize the Class driver instance, the driver's <i><b>{Class Name}</b>_Host_ConfigurePipes()</i> function
+ * should be called in response to the host state machine entering the \ref HOST_STATE_Addressed state. This function
+ * will return an error code from the class driver's <i><b>{Class Name}</b>_EnumerationFailure_ErrorCodes_t</i> enum
+ * to indicate if the driver sucessfully 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 seperate instances of the same class type can be initialized. A fragment of a Class Driver
+ * based Host mode application may look like the following:
+ *
+ * \code
+ * switch (USB_HostState)
+ * {
+ * case HOST_STATE_Addressed:
+ * 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);
+ * USB_HostState = HOST_STATE_WaitForDeviceRemoval;
+ * break;
+ * }
+ *
+ * if (MIDI_Host_ConfigurePipes(&My_MIDI_Interface,
+ * ConfigDescriptorSize, ConfigDescriptorData) != MIDI_ENUMERROR_NoError)
+ * {
+ * LEDs_SetAllLEDs(LEDMASK_USB_ERROR);
+ * USB_HostState = HOST_STATE_WaitForDeviceRemoval;
+ * break;
+ * }
+ *
+ * // Other state handler code here
+ * \endcode
+ *
+ * Note that the function also required 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
+ * \ref 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.
+ *
+ * Once initialized, it is important to maintain the class driver's state by repeatedly calling the Class Driver's
+ * <i><b>{Class Name}</b>_Host_USBTask()</i> 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
+ * seperate instance, just like the main USB maintenance routine \ref USB_USBTask():
+ *
+ * \code
+ * int main(void)
+ * {
+ * SetupHardware();
+ *
+ * LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
+ *
+ * for (;;)
+ * {
+ * switch (USB_HostState)
+ * {
+ * // Host state machine handling here
+ * }
+ *
+ * MIDI_Host_USBTask(&My_Audio_Interface);
+ * USB_USBTask();
+ * }
+ * }
+ * \endcode
+ *
+ * Each class driver may also define a set of callback functions (which are prefixed by "CALLBACK_"
+ * in the function's name) which <b>must</b> 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 <b>may</b> 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.
+ */
+
+#ifndef __USB_H__
+#define __USB_H__
+
+ /* Macros: */
+ #if !defined(__DOXYGEN__)
+ #define __INCLUDE_FROM_USB_DRIVER
+ #endif
+
+ /* Includes: */
+ #include "HighLevel/USBMode.h"
+
+ /* Preprocessor Checks: */
+ #if (!defined(USB_SERIES_2_AVR) && !defined(USB_SERIES_4_AVR) && \
+ !defined(USB_SERIES_6_AVR) && !defined(USB_SERIES_7_AVR))
+ #error The currently selected AVR model is not supported under the USB component of the LUFA library.
+ #endif
+
+ /* Includes: */
+ #include "HighLevel/USBTask.h"
+ #include "HighLevel/Events.h"
+ #include "HighLevel/StdDescriptors.h"
+ #include "HighLevel/ConfigDescriptor.h"
+
+ #include "LowLevel/LowLevel.h"
+ #include "LowLevel/USBInterrupt.h"
+
+ #if defined(USB_CAN_BE_HOST) || defined(__DOXYGEN__)
+ #include "LowLevel/Host.h"
+ #include "LowLevel/HostChapter9.h"
+ #include "LowLevel/Pipe.h"
+ #endif
+
+ #if defined(USB_CAN_BE_DEVICE) || defined(__DOXYGEN__)
+ #include "LowLevel/Device.h"
+ #include "LowLevel/DevChapter9.h"
+ #include "LowLevel/Endpoint.h"
+ #endif
+
+ #if defined(USB_CAN_BE_BOTH) || defined(__DOXYGEN__)
+ #include "LowLevel/OTG.h"
+ #endif
+
+#endif
+
projects / pub / USBasp.git / blobdiff