Add documentation to the USB Class Drivers module on how to use the Host mode class...

diff --git a/LUFA/Drivers/USB/USB.h b/LUFA/Drivers/USB/USB.h
index d1bf17a..a632f52 100644 (file)
--- a/LUFA/Drivers/USB/USB.h
+++ b/LUFA/Drivers/USB/USB.h
@@ -235,7 +235,116 @@
  *  class-specific functions.\r
  *\r
  *  \subsection SSec_ClassDriverHost Host Mode Class Drivers\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
  *\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
  */\r
  \r
 #ifndef __USB_H__\r