b633336266847748ad91ea1e6e0224f654ee06a9
   3      Copyright (C) Dean Camera, 2011. 
   5   dean [at] fourwalledcubicle [dot] com 
  10   Copyright 2011  Dean Camera (dean [at] fourwalledcubicle [dot] com) 
  12   Permission to use, copy, modify, distribute, and sell this 
  13   software and its documentation for any purpose is hereby granted 
  14   without fee, provided that the above copyright notice appear in 
  15   all copies and that both that the copyright notice and this 
  16   permission notice and warranty disclaimer appear in supporting 
  17   documentation, and that the name of the author not be used in 
  18   advertising or publicity pertaining to distribution of the 
  19   software without specific, written prior permission. 
  21   The author disclaim all warranties with regard to this 
  22   software, including all implied warranties of merchantability 
  23   and fitness.  In no event shall the author be liable for any 
  24   special, indirect or consequential damages or any damages 
  25   whatsoever resulting from loss of use, data or profits, whether 
  26   in an action of contract, negligence or other tortious action, 
  27   arising out of or in connection with the use or performance of 
  32  *  \brief Master include file for the library USB functionality. 
  34  *  Master include file for the library USB functionality. 
  36  *  This file should be included in all user projects making use of the USB portions of the library, instead of 
  37  *  the individual USB driver submodule headers. 
  40 /** \defgroup Group_USB USB Core - LUFA/Drivers/USB/USB.h 
  42  *  \section Sec_Dependencies Module Source Dependencies 
  43  *  The following files must be built with any user project that uses this module: 
  44  *    - LUFA/Drivers/USB/Core/ConfigDescriptor.c <i>(Makefile source module name: LUFA_SRC_USB)</i> 
  45  *    - LUFA/Drivers/USB/Core/DeviceStandardReq.c <i>(Makefile source module name: LUFA_SRC_USB)</i> 
  46  *    - LUFA/Drivers/USB/Core/Events.c <i>(Makefile source module name: LUFA_SRC_USB)</i> 
  47  *    - LUFA/Drivers/USB/Core/HostStandardReq.c <i>(Makefile source module name: LUFA_SRC_USB)</i> 
  48  *    - LUFA/Drivers/USB/Core/USBTask.c <i>(Makefile source module name: LUFA_SRC_USB)</i> 
  49  *    - LUFA/Drivers/USB/Core/<i>ARCH</i>/Device_<i>ARCH</i>.c <i>(Makefile source module name: LUFA_SRC_USB)</i> 
  50  *    - LUFA/Drivers/USB/Core/<i>ARCH</i>/Endpoint_<i>ARCH</i>.c <i>(Makefile source module name: LUFA_SRC_USB)</i> 
  51  *    - LUFA/Drivers/USB/Core/<i>ARCH</i>/EndpointStream_<i>ARCH</i>.c <i>(Makefile source module name: LUFA_SRC_USB)</i> 
  52  *    - LUFA/Drivers/USB/Core/<i>ARCH</i>/Host_<i>ARCH</i>.c <i>(Makefile source module name: LUFA_SRC_USB)</i> 
  53  *    - LUFA/Drivers/USB/Core/<i>ARCH</i>/Pipe_<i>ARCH</i>.c <i>(Makefile source module name: LUFA_SRC_USB)</i> 
  54  *    - LUFA/Drivers/USB/Core/<i>ARCH</i>/PipeStream_<i>ARCH</i>.c <i>(Makefile source module name: LUFA_SRC_USB)</i> 
  55  *    - LUFA/Drivers/USB/Core/<i>ARCH</i>/USBController_<i>ARCH</i>.c <i>(Makefile source module name: LUFA_SRC_USB)</i> 
  56  *    - LUFA/Drivers/USB/Core/<i>ARCH</i>/USBInterrupt_<i>ARCH</i>.c <i>(Makefile source module name: LUFA_SRC_USB)</i> 
  57  *    - LUFA/Drivers/USB/Class/Common/HIDParser.c <i>(Makefile source module name: LUFA_SRC_USB)</i> 
  59  *  \section Sec_ModDescription Module Description 
  60  *  Driver and framework for the USB controller of the selected architecture and microcontroller model. This module 
  61  *  consists of many submodules, and is designed to provide an easy way to configure and control USB host, device 
  62  *  or OTG mode USB applications. 
  64  *  The USB stack requires the sole control over the USB controller in the microcontroller only; i.e. it does not 
  65  *  require any additional timers or other peripherals to operate. This ensures that the USB stack requires as few 
  66  *  resources as possible. 
  68  *  The USB stack can be used in Device Mode for connections to USB Hosts (see \ref Group_Device), in Host mode for 
  69  *  hosting of other USB devices (see \ref Group_Host), or as a dual role device which can either act as a USB host 
  70  *  or device depending on what peripheral is connected (see \ref Group_OTG). Both modes also require a common set 
  71  *  of USB management functions found \ref Group_USBManagement. 
  74 /** \defgroup Group_USBClassDrivers USB Class Drivers 
  76  *  Drivers for both host and device mode of the standard USB classes, for rapid application development. 
  77  *  Class drivers give a framework which sits on top of the low level library API, allowing for standard 
  78  *  USB classes to be implemented in a project with minimal user code. These drivers can be used in 
  79  *  conjunction with the library low level APIs to implement interfaces both via the class drivers and via 
  80  *  the standard library APIs. 
  82  *  Multiple device mode class drivers can be used within a project, including multiple instances of the 
  83  *  same class driver. In this way, USB Hosts and Devices can be made quickly using the internal class drivers 
  84  *  so that more time and effort can be put into the end application instead of the USB protocol. 
  86  *  The available class drivers and their modes are listed below. 
  90  *   <th width="200px">USB Class</th> 
  91  *   <th width="90px">Device Mode</th> 
  92  *   <th width="90px">Host Mode</th> 
  95  *   <td>Android Open Accessory</td> 
  96  *   <td bgcolor="#EE0000">No</td> 
  97  *   <td bgcolor="#00EE00">Yes</td> 
 101  *   <td bgcolor="#00EE00">Yes</td> 
 102  *   <td bgcolor="#00EE00">Yes</td> 
 106  *   <td bgcolor="#00EE00">Yes</td> 
 107  *   <td bgcolor="#00EE00">Yes</td> 
 111  *   <td bgcolor="#00EE00">Yes</td> 
 112  *   <td bgcolor="#00EE00">Yes</td> 
 116  *   <td bgcolor="#00EE00">Yes</td> 
 117  *   <td bgcolor="#00EE00">Yes</td> 
 120  *   <td>Mass Storage</td> 
 121  *   <td bgcolor="#00EE00">Yes</td> 
 122  *   <td bgcolor="#00EE00">Yes</td> 
 126  *   <td bgcolor="#EE0000">No</td> 
 127 *    <td bgcolor="#00EE00">Yes</td> 
 131  *   <td bgcolor="#00EE00">Yes</td> 
 132  *   <td bgcolor="#00EE00">Yes</td> 
 135  *   <td>Still Image</td> 
 136  *   <td bgcolor="#EE0000">No</td> 
 137  *   <td bgcolor="#00EE00">Yes</td> 
 142  *  \section Sec_UsingClassDrivers Using the Class Drivers 
 143  *  To make the Class drivers easy to integrate into a user application, they all implement a standardized 
 144  *  design with similarly named/used function, enums, defines and types. The two different modes are implemented 
 145  *  slightly differently, and thus will be explained separately. For information on a specific class driver, read 
 146  *  the class driver's module documentation. 
 148  *  \subsection Sec_ClassDriverDevice Device Mode Class Drivers 
 149  *  Implementing a Device Mode Class Driver in a user application requires a number of steps to be followed. Firstly, 
 150  *  the module configuration and state structure must be added to the project source. These structures are named in a 
 151  *  similar manner between classes, that of <tt>USB_ClassInfo_<i>{Class Name}</i>_Device_t</tt>, and are used to hold the 
 152  *  complete state and configuration for each class instance. Multiple class instances is where the power of the class 
 153  *  drivers lie; multiple interfaces of the same class simply require more instances of the Class Driver's \c USB_ClassInfo_* 
 156  *  Inside the ClassInfo structure lies two sections, a \c Config section, and a \c State section. The \c Config 
 157  *  section contains the instance's configuration parameters, and <b>must have all fields set by the user application</b> 
 158  *  before the class driver is used. Each Device mode Class driver typically contains a set of configuration parameters 
 159  *  for the endpoint size/number of the associated logical USB interface, plus any class-specific configuration parameters. 
 161  *  The \c State section of the \c USB_ClassInfo_* structures are designed to be controlled by the Class Drivers only for 
 162  *  maintaining the Class Driver instance's state, and should not normally be set by the user application. 
 164  *  The following is an example of a properly initialized instance of the Audio Class Driver structure: 
 167  *  USB_ClassInfo_Audio_Device_t My_Audio_Interface = 
 171  *              .StreamingInterfaceNumber = 1, 
 173  *              .DataINEndpointNumber     = 1, 
 174  *              .DataINEndpointSize       = 256, 
 179  *  \note The class driver's configuration parameters should match those used in the device's descriptors that are 
 182  *  To initialize the Class driver instance, the driver's <tt><i>{Class Name}</i>_Device_ConfigureEndpoints()</tt> function 
 183  *  should be called in response to the \ref EVENT_USB_Device_ConfigurationChanged() event. This function will return a 
 184  *  boolean true value if the driver successfully initialized the instance. Like all the class driver functions, this function 
 185  *  takes in the address of the specific instance you wish to initialize - in this manner, multiple separate instances of 
 186  *  the same class type can be initialized like this: 
 189  *  void EVENT_USB_Device_ConfigurationChanged(void) 
 191  *      LEDs_SetAllLEDs(LEDMASK_USB_READY); 
 193  *      if (!(Audio_Device_ConfigureEndpoints(&My_Audio_Interface))) 
 194  *        LEDs_SetAllLEDs(LEDMASK_USB_ERROR); 
 198  *  Once initialized, it is important to maintain the class driver's state by repeatedly calling the Class Driver's 
 199  *  <tt><i>{Class Name}</i>_Device_USBTask()</tt> function in the main program loop. The exact implementation of this 
 200  *  function varies between class drivers, and can be used for any internal class driver purpose to maintain each 
 201  *  instance. Again, this function uses the address of the instance to operate on, and thus needs to be called for each 
 202  *  separate instance, just like the main USB maintenance routine \ref USB_USBTask(): 
 209  *      LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY); 
 213  *          Create_And_Process_Samples(); 
 215  *          Audio_Device_USBTask(&My_Audio_Interface); 
 221  *  The final standardized Device Class Driver function is the Control Request handler function 
 222  *  <tt><i>{Class Name}</i>_Device_ProcessControlRequest()</tt>, which should be called when the 
 223  *  \ref EVENT_USB_Device_ControlRequest() event fires. This function should also be called for 
 224  *  each class driver instance, using the address of the instance to operate on as the function's 
 225  *  parameter. The request handler will abort if it is determined that the current request is not 
 226  *  targeted at the given class driver instance, thus these methods can safely be called 
 227  *  one-after-another in the event handler with no form of error checking: 
 230  *  void EVENT_USB_Device_ControlRequest(void) 
 232  *      Audio_Device_ProcessControlRequest(&My_Audio_Interface); 
 236  *  Each class driver may also define a set of callback functions (which are prefixed by \c CALLBACK_* 
 237  *  in the function's name) which <b>must</b> also be added to the user application - refer to each 
 238  *  individual class driver's documentation for mandatory callbacks. In addition, each class driver may 
 239  *  also define a set of events (identifiable by their prefix of \c EVENT_* in the function's name), which 
 240  *  the user application <b>may</b> choose to implement, or ignore if not needed. 
 242  *  The individual Device Mode Class Driver documentation contains more information on the non-standardized, 
 243  *  class-specific functions which the user application can then use on the driver instances, such as data 
 244  *  read and write routines. See each driver's individual documentation for more information on the 
 245  *  class-specific functions. 
 247  *  \subsection Sec_ClassDriverHost Host Mode Class Drivers 
 248  *  Implementing a Host Mode Class Driver in a user application requires a number of steps to be followed. Firstly, 
 249  *  the module configuration and state structure must be added to the project source. These structures are named in a 
 250  *  similar manner between classes, that of <tt>USB_ClassInfo_<b>{Class Name}</b>_Host_t</tt>, and are used to hold the 
 251  *  complete state and configuration for each class instance. Multiple class instances is where the power of the class 
 252  *  drivers lie; multiple interfaces of the same class simply require more instances of the Class Driver's \c USB_ClassInfo_* 
 255  *  Inside the \c USB_ClassInfo_* structure lies two sections, a \c Config section, and a \c State section. The \c Config 
 256  *  section contains the instance's configuration parameters, and <b>must have all fields set by the user application</b> 
 257  *  before the class driver is used. Each Device mode Class driver typically contains a set of configuration parameters 
 258  *  for the endpoint size/number of the associated logical USB interface, plus any class-specific configuration parameters. 
 260  *  The \c State section of the \c USB_ClassInfo_* structures are designed to be controlled by the Class Drivers only for 
 261  *  maintaining the Class Driver instance's state, and should not normally be set by the user application. 
 263  *  The following is an example of a properly initialized instance of the MIDI Class Driver structure: 
 266  *  USB_ClassInfo_MIDI_Host_t My_MIDI_Interface = 
 270  *              .DataINPipeNumber       = 1, 
 271  *              .DataINPipeDoubleBank   = false, 
 273  *              .DataOUTPipeNumber      = 2, 
 274  *              .DataOUTPipeDoubleBank  = false, 
 279  *  To initialize the Class driver instance, the driver's <tt><b>{Class Name}</b>_Host_ConfigurePipes()</tt> function 
 280  *  should be called in response to the host state machine entering the \ref HOST_STATE_Addressed state. This function 
 281  *  will return an error code from the class driver's <tt><b>{Class Name}</b>_EnumerationFailure_ErrorCodes_t</tt> enum 
 282  *  to indicate if the driver successfully initialized the instance and bound it to an interface in the attached device. 
 283  *  Like all the class driver functions, this function takes in the address of the specific instance you wish to initialize - 
 284  *  in this manner, multiple separate instances of the same class type can be initialized. A fragment of a Class Driver 
 285  *  based Host mode application may look like the following: 
 288  *      switch (USB_HostState) 
 290  *          case HOST_STATE_Addressed: 
 291  *              LEDs_SetAllLEDs(LEDMASK_USB_ENUMERATING); 
 293  *              uint16_t ConfigDescriptorSize; 
 294  *              uint8_t  ConfigDescriptorData[512]; 
 296  *              if (USB_Host_GetDeviceConfigDescriptor(1, &ConfigDescriptorSize, ConfigDescriptorData, 
 297  *                                                     sizeof(ConfigDescriptorData)) != HOST_GETCONFIG_Successful) 
 299  *                  LEDs_SetAllLEDs(LEDMASK_USB_ERROR); 
 300  *                  USB_HostState = HOST_STATE_WaitForDeviceRemoval; 
 304  *              if (MIDI_Host_ConfigurePipes(&My_MIDI_Interface, 
 305  *                                           ConfigDescriptorSize, ConfigDescriptorData) != MIDI_ENUMERROR_NoError) 
 307  *                  LEDs_SetAllLEDs(LEDMASK_USB_ERROR); 
 308  *                  USB_HostState = HOST_STATE_WaitForDeviceRemoval; 
 312  *              // Other state handler code here 
 315  *  Note that the function also required the device's configuration descriptor so that it can determine which interface 
 316  *  in the device to bind to - this can be retrieved as shown in the above fragment using the 
 317  *  \ref USB_Host_GetDeviceConfigDescriptor() function. If the device does not implement the interface the class driver 
 318  *  is looking for, if all the matching interfaces are already bound to class driver instances or if an error occurs while 
 319  *  binding to a device interface (for example, a device endpoint bank larger that the maximum supported bank size is used) 
 320  *  the configuration will fail. 
 322  *  Once initialized, it is important to maintain the class driver's state by repeatedly calling the Class Driver's 
 323  *  <tt><b>{Class Name}</b>_Host_USBTask()</tt> function in the main program loop. The exact implementation of this 
 324  *  function varies between class drivers, and can be used for any internal class driver purpose to maintain each 
 325  *  instance. Again, this function uses the address of the instance to operate on, and thus needs to be called for each 
 326  *  separate instance, just like the main USB maintenance routine \ref USB_USBTask(): 
 333  *      LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY); 
 337  *          switch (USB_HostState) 
 339  *             // Host state machine handling here 
 342  *          MIDI_Host_USBTask(&My_Audio_Interface); 
 348  *  Each class driver may also define a set of callback functions (which are prefixed by \c CALLBACK_* 
 349  *  in the function's name) which <b>must</b> also be added to the user application - refer to each 
 350  *  individual class driver's documentation for mandatory callbacks. In addition, each class driver may 
 351  *  also define a set of events (identifiable by their prefix of \c EVENT_* in the function's name), which 
 352  *  the user application <b>may</b> choose to implement, or ignore if not needed. 
 354  *  The individual Host Mode Class Driver documentation contains more information on the non-standardized, 
 355  *  class-specific functions which the user application can then use on the driver instances, such as data 
 356  *  read and write routines. See each driver's individual documentation for more information on the 
 357  *  class-specific functions. 
 364                 #define __INCLUDE_FROM_USB_DRIVER 
 367                 #include "../../Common/Common.h" 
 368                 #include "Core/USBMode.h" 
 371                 #include "Core/USBTask.h" 
 372                 #include "Core/Events.h" 
 373                 #include "Core/StdDescriptors.h" 
 374                 #include "Core/ConfigDescriptor.h" 
 375                 #include "Core/USBController.h" 
 376                 #include "Core/USBInterrupt.h" 
 378                 #if defined(USB_CAN_BE_HOST) || defined(__DOXYGEN__) 
 379                         #include "Core/Host.h" 
 380                         #include "Core/Pipe.h" 
 381                         #include "Core/HostStandardReq.h" 
 382                         #include "Core/PipeStream.h" 
 385                 #if defined(USB_CAN_BE_DEVICE) || defined(__DOXYGEN__) 
 386                         #include "Core/Device.h" 
 387                         #include "Core/Endpoint.h" 
 388                         #include "Core/DeviceStandardReq.h" 
 389                         #include "Core/EndpointStream.h" 
 392                 #if defined(USB_CAN_BE_BOTH) || defined(__DOXYGEN__) 
 393                         #include "Core/OTG.h" 
 396                 #include "Class/AndroidAccessoryClass.h" 
 397                 #include "Class/AudioClass.h" 
 398                 #include "Class/CDCClass.h" 
 399                 #include "Class/HIDClass.h" 
 400                 #include "Class/MassStorageClass.h" 
 401                 #include "Class/MIDIClass.h" 
 402                 #include "Class/PrinterClass.h" 
 403                 #include "Class/RNDISClass.h" 
 404                 #include "Class/StillImageClass.h"