LUFA/Drivers/USB/USB.h

   1 /*
   2              LUFA Library
   3      Copyright (C) Dean Camera, 2010.
   4
   5   dean [at] fourwalledcubicle [dot] com
   6       www.fourwalledcubicle.com
   7 */
   8
   9 /*
  10   Copyright 2010  Dean Camera (dean [at] fourwalledcubicle [dot] com)
  11
  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.
  20
  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
  28   this software.
  29 */
  30
  31 /** \file
  32  *
  33  *  Master include file for the library USB functionality. This file should be included in all user projects making
  34  *  use of the USB portions of the library, instead of including any headers in the USB/LowLevel or USB/HighLevel
  35  *  directories.
  36  */
  37
  38 /** @defgroup Group_USB USB - LUFA/Drivers/USB/USB.h
  39  *
  40  *  \section Sec_Dependencies Module Source Dependencies
  41  *  The following files must be built with any user project that uses this module:
  42  *    - LUFA/Drivers/USB/LowLevel/DevChapter9.c
  43  *    - LUFA/Drivers/USB/LowLevel/Endpoint.c
  44  *    - LUFA/Drivers/USB/LowLevel/Host.c
  45  *    - LUFA/Drivers/USB/LowLevel/HostChapter9.c
  46  *    - LUFA/Drivers/USB/LowLevel/LowLevel.c
  47  *    - LUFA/Drivers/USB/LowLevel/Pipe.c
  48  *    - LUFA/Drivers/USB/HighLevel/Events.c
  49  *    - LUFA/Drivers/USB/HighLevel/USBInterrupt.c
  50  *    - LUFA/Drivers/USB/HighLevel/USBTask.c
  51  *    - LUFA/Drivers/USB/HighLevel/ConfigDescriptor.c
  52  *
  53  *  \section Module Description
  54  *  Driver and framework for the USB controller hardware on the USB series of AVR microcontrollers. This module
  55  *  consists of many submodules, and is designed to provide an easy way to configure and control USB host, device
  56  *  or OTG mode USB applications.
  57  *
  58  *  The USB stack requires the sole control over the USB controller in the microcontroller only; i.e. it does not
  59  *  require any additional AVR timers, etc. to operate. This ensures that the USB stack requires as few resources
  60  *  as possible.
  61  *
  62  *  The USB stack can be used in Device Mode for connections to USB Hosts (see \ref Group_Device), in Host mode for
  63  *  hosting of other USB devices (see \ref Group_Host), or as a dual role device which can either act as a USB host
  64  *  or device depending on what peripheral is connected (see \ref Group_OTG). Both modes also require a common set
  65  *  of USB management functions found \ref Group_USBManagement.
  66  */
  67
  68 /** \ingroup Group_USB
  69  *  @defgroup Group_USBClassDrivers USB Class Drivers
  70  *
  71  *  Drivers for both host and device mode of the standard USB classes, for rapid application development.
  72  *  Class drivers give a framework which sits on top of the low level library API, allowing for standard
  73  *  USB classes to be implemented in a project with minimal user code. These drivers can be used in
  74  *  conjunction with the library low level APIs to implement interfaces both via the class drivers and via
  75  *  the standard library APIs.
  76  *
  77  *  Multiple device mode class drivers can be used within a project, including multiple instances of the
  78  *  same class driver. In this way, USB Hosts and Devices can be made quickly using the internal class drivers
  79  *  so that more time and effort can be put into the end application instead of the USB protocol.
  80  *
  81  *  The available class drivers and their modes are listed below.
  82  *
  83  *  <table>
  84  *  <tr>
  85  *   <th width="100px">USB Class</th>
  86  *   <th width="90px">Device Mode</th>
  87  *   <th width="90px">Host Mode</th>
  88  *  </tr>
  89  *  <tr>
  90  *   <td>Audio</td>
  91  *   <td bgcolor="#00EE00">Yes</td>
  92  *   <td bgcolor="#EE0000">No</td>
  93  *  </tr>
  94  *  <tr>
  95  *   <td>CDC</td>
  96  *   <td bgcolor="#00EE00">Yes</td>
  97  *   <td bgcolor="#00EE00">Yes</td>
  98  *  </tr>
  99  *  <tr>
 100  *   <td>HID</td>
 101  *   <td bgcolor="#00EE00">Yes</td>
 102  *   <td bgcolor="#00EE00">Yes</td>
 103  *  </tr>
 104  *  <tr>
 105  *   <td>MIDI</td>
 106  *   <td bgcolor="#00EE00">Yes</td>
 107  *   <td bgcolor="#00EE00">Yes</td>
 108  *  </tr>
 109  *  <tr>
 110  *   <td>Mass Storage</td>
 111  *   <td bgcolor="#00EE00">Yes</td>
 112  *   <td bgcolor="#00EE00">Yes</td>
 113  *  </tr>
 114  *  <tr>
 115  *   <td>Printer</td>
 116  *   <td bgcolor="#EE0000">No</td>
 117 *    <td bgcolor="#00EE00">Yes</td>
 118  *  </tr>
 119  *  <tr>
 120  *   <td>RNDIS</td>
 121  *   <td bgcolor="#00EE00">Yes</td>
 122  *   <td bgcolor="#00EE00">Yes</td>
 123  *  </tr>
 124  *  <tr>
 125  *   <td>Still Image</td>
 126  *   <td bgcolor="#EE0000">No</td>
 127  *   <td bgcolor="#00EE00">Yes</td>
 128  *  </tr>
 129  *  </table>
 130  *
 131  *
 132  *  \section Sec_UsingClassDrivers Using the Class Drivers
 133  *  To make the Class drivers easy to integrate into a user application, they all implement a standardized
 134  *  design with similarly named/used function, enums, defines and types. The two different modes are implemented
 135  *  slightly differently, and thus will be explained separately. For information on a specific class driver, read
 136  *  the class driver's module documentation.
 137  *
 138  *  \subsection SSec_ClassDriverDevice Device Mode Class Drivers
 139  *  Implementing a Device Mode Class Driver in a user application requires a number of steps to be followed. Firstly,
 140  *  the module configuration and state structure must be added to the project source. These structures are named in a
 141  *  similar manner between classes, that of <i>USB_ClassInfo_<b>{Class Name}</b>_Device_t</i>, and are used to hold the
 142  *  complete state and configuration for each class instance. Multiple class instances is where the power of the class
 143  *  drivers lie; multiple interfaces of the same class simply require more instances of the Class Driver's ClassInfo
 144  *  structure.
 145  *
 146  *  Inside the ClassInfo structure lies two sections, a <i>Config</i> section, and a <i>State</i> section. The Config
 147  *  section contains the instance's configuration parameters, and <b>must have all fields set by the user application</b>
 148  *  before the class driver is used. Each Device mode Class driver typically contains a set of configuration parameters
 149  *  for the endpoint size/number of the associated logical USB interface, plus any class-specific configuration parameters.
 150  *
 151  *  The <i>State</i> section of the ClassInfo structures are designed to be controlled by the Class Drivers only for
 152  *  maintaining the Class Driver instance's state, and should not normally be set by the user application.
 153  *
 154  *  The following is an example of a properly initialized instance of the Audio Class Driver structure:
 155  *
 156  *  \code
 157  *  USB_ClassInfo_Audio_Device_t My_Audio_Interface =
 158  *  {
 159  *      .Config =
 160  *          {
 161  *              .StreamingInterfaceNumber = 1,
 162  *
 163  *              .DataINEndpointNumber     = 1,
 164  *              .DataINEndpointSize       = 256,
 165  *          },
 166  *  };
 167  *  \endcode
 168  *
 169  *  \note The class driver's configuration parameters should match those used in the device's descriptors that are
 170  *  sent to the host.
 171  *
 172  *  To initialize the Class driver instance, the driver's <i><b>{Class Name}</b>_Device_ConfigureEndpoints()</i> function
 173  *  should be called in response to the \ref EVENT_USB_Device_ConfigurationChanged() event. This function will return a
 174  *  boolean value if the driver sucessfully initialized the instance. Like all the class driver functions, this function
 175  *  takes in the address of the specific instance you wish to initialize - in this manner, multiple seperate instances of
 176  *  the same class type can be initialized like thus:
 177  *
 178  *  \code
 179  *  void EVENT_USB_Device_ConfigurationChanged(void)
 180  *  {
 181  *      LEDs_SetAllLEDs(LEDMASK_USB_READY);
 182  *
 183  *      if (!(Audio_Device_ConfigureEndpoints(&My_Audio_Interface)))
 184  *        LEDs_SetAllLEDs(LEDMASK_USB_ERROR);
 185  *  }
 186  *  \endcode
 187  *
 188  *  Once initialized, it is important to maintain the class driver's state by repeatedly calling the Class Driver's
 189  *  <i><b>{Class Name}</b>_Device_USBTask()</i> function in the main program loop. The exact implementation of this
 190  *  function varies between class drivers, and can be used for any internal class driver purpose to maintain each
 191  *  instance. Again, this function uses the address of the instance to operate on, and thus needs to be called for each
 192  *  seperate instance, just like the main USB maintenance routine \ref USB_USBTask():
 193  *
 194  *  \code
 195  *  int main(void)
 196  *  {
 197  *      SetupHardware();
 198  *
 199  *      LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
 200  *
 201  *      for (;;)
 202  *      {
 203  *          Create_And_Process_Samples();
 204  *
 205  *          Audio_Device_USBTask(&My_Audio_Interface);
 206  *          USB_USBTask();
 207  *      }
 208  *  }
 209  *  \endcode
 210  *
 211  *  The final standardized Device Class Driver function is the Control Request handler function
 212  *  <i><b>{Class Name}</b>_Device_ProcessControlRequest()</i>, which should be called when the
 213  *  \ref EVENT_USB_Device_UnhandledControlRequest() event fires. This function should also be
 214  *  called for each class driver instance, using the address of the instance to operate on as
 215  *  the function's parameter. The request handler will abort if it is determined that the current
 216  *  request is not targeted at the given class driver instance, thus these methods can safely be
 217  *  called one-after-another in the event handler with no form of error checking:
 218  *
 219  *  \code
 220  *  void EVENT_USB_Device_UnhandledControlRequest(void)
 221  *  {
 222  *      Audio_Device_ProcessControlRequest(&My_Audio_Interface);
 223  *  }
 224  *  \endcode
 225  *
 226  *  Each class driver may also define a set of callback functions (which are prefixed by "CALLBACK_"
 227  *  in the function's name) which <b>must</b> also be added to the user application - refer to each
 228  *  individual class driver's documentation for mandatory callbacks. In addition, each class driver may
 229  *  also define a set of events (identifiable by their prefix of "EVENT_" in the function's name), which
 230  *  the user application <b>may</b> choose to implement, or ignore if not needed.
 231  *
 232  *  The individual Device Mode Class Driver documentation contains more information on the non-standardized,
 233  *  class-specific functions which the user application can then use on the driver instances, such as data
 234  *  read and write routines. See each driver's individual documentation for more information on the
 235  *  class-specific functions.
 236  *
 237  *  \subsection SSec_ClassDriverHost Host Mode Class Drivers
 238  *  Implementing a Host Mode Class Driver in a user application requires a number of steps to be followed. Firstly,
 239  *  the module configuration and state structure must be added to the project source. These structures are named in a
 240  *  similar manner between classes, that of <i>USB_ClassInfo_<b>{Class Name}</b>_Host_t</i>, and are used to hold the
 241  *  complete state and configuration for each class instance. Multiple class instances is where the power of the class
 242  *  drivers lie; multiple interfaces of the same class simply require more instances of the Class Driver's ClassInfo
 243  *  structure.
 244  *
 245  *  Inside the ClassInfo structure lies two sections, a <i>Config</i> section, and a <i>State</i> section. The Config
 246  *  section contains the instance's configuration parameters, and <b>must have all fields set by the user application</b>
 247  *  before the class driver is used. Each Device mode Class driver typically contains a set of configuration parameters
 248  *  for the endpoint size/number of the associated logical USB interface, plus any class-specific configuration parameters.
 249  *
 250  *  The <i>State</i> section of the ClassInfo structures are designed to be controlled by the Class Drivers only for
 251  *  maintaining the Class Driver instance's state, and should not normally be set by the user application.
 252  *
 253  *  The following is an example of a properly initialized instance of the MIDI Class Driver structure:
 254  *
 255  *  \code
 256  *  USB_ClassInfo_MIDI_Host_t My_MIDI_Interface =
 257  *  {
 258  *      .Config =
 259  *          {
 260  *              .DataINPipeNumber       = 1,
 261  *              .DataINPipeDoubleBank   = false,
 262  *
 263  *              .DataOUTPipeNumber      = 2,
 264  *              .DataOUTPipeDoubleBank  = false,
 265  *          },
 266  *  };
 267  *  \endcode
 268  *
 269  *  To initialize the Class driver instance, the driver's <i><b>{Class Name}</b>_Host_ConfigurePipes()</i> function
 270  *  should be called in response to the host state machine entering the \ref HOST_STATE_Addressed state. This function
 271  *  will return an error code from the class driver's <i><b>{Class Name}</b>_EnumerationFailure_ErrorCodes_t</i> enum
 272  *  to indicate if the driver sucessfully initialized the instance and bound it to an interface in the attached device.
 273  *  Like all the class driver functions, this function takes in the address of the specific instance you wish to initialize
 274  *  - in this manner, multiple seperate instances of the same class type can be initialized. A fragment of a Class Driver
 275  *  based Host mode application may look like the following:
 276  *
 277  *  \code
 278  *      switch (USB_HostState)
 279  *      {
 280  *          case HOST_STATE_Addressed:
 281  *              LEDs_SetAllLEDs(LEDMASK_USB_ENUMERATING);
 282  *
 283  *              uint16_t ConfigDescriptorSize;
 284  *              uint8_t  ConfigDescriptorData[512];
 285  *
 286  *              if (USB_Host_GetDeviceConfigDescriptor(1, &ConfigDescriptorSize, ConfigDescriptorData,
 287  *                                                     sizeof(ConfigDescriptorData)) != HOST_GETCONFIG_Successful)
 288  *              {
 289  *                  LEDs_SetAllLEDs(LEDMASK_USB_ERROR);
 290  *                  USB_HostState = HOST_STATE_WaitForDeviceRemoval;
 291  *                  break;
 292  *              }
 293  *
 294  *              if (MIDI_Host_ConfigurePipes(&My_MIDI_Interface,
 295  *                                           ConfigDescriptorSize, ConfigDescriptorData) != MIDI_ENUMERROR_NoError)
 296  *              {
 297  *                  LEDs_SetAllLEDs(LEDMASK_USB_ERROR);
 298  *                  USB_HostState = HOST_STATE_WaitForDeviceRemoval;
 299  *                  break;
 300  *              }
 301  *
 302  *              // Other state handler code here
 303  *  \endcode
 304  *
 305  *  Note that the function also required the device's configuration descriptor so that it can determine which interface
 306  *  in the device to bind to - this can be retrieved as shown in the above fragment using the
 307  *  \ref USB_Host_GetDeviceConfigDescriptor() function. If the device does not implement the interface the class driver
 308  *  is looking for, if all the matching interfaces are already bound to class driver instances or if an error occurs while
 309  *  binding to a device interface (for example, a device endpoint bank larger that the maximum supported bank size is used)
 310  *  the configuration will fail.
 311  *
 312  *  Once initialized, it is important to maintain the class driver's state by repeatedly calling the Class Driver's
 313  *  <i><b>{Class Name}</b>_Host_USBTask()</i> function in the main program loop. The exact implementation of this
 314  *  function varies between class drivers, and can be used for any internal class driver purpose to maintain each
 315  *  instance. Again, this function uses the address of the instance to operate on, and thus needs to be called for each
 316  *  seperate instance, just like the main USB maintenance routine \ref USB_USBTask():
 317  *
 318  *  \code
 319  *  int main(void)
 320  *  {
 321  *      SetupHardware();
 322  *
 323  *      LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
 324  *
 325  *      for (;;)
 326  *      {
 327  *          switch (USB_HostState)
 328  *          {
 329  *             // Host state machine handling here
 330  *          }
 331  *
 332  *          MIDI_Host_USBTask(&My_Audio_Interface);
 333  *          USB_USBTask();
 334  *      }
 335  *  }
 336  *  \endcode
 337  *
 338  *  Each class driver may also define a set of callback functions (which are prefixed by "CALLBACK_"
 339  *  in the function's name) which <b>must</b> also be added to the user application - refer to each
 340  *  individual class driver's documentation for mandatory callbacks. In addition, each class driver may
 341  *  also define a set of events (identifiable by their prefix of "EVENT_" in the function's name), which
 342  *  the user application <b>may</b> choose to implement, or ignore if not needed.
 343  *
 344  *  The individual Host Mode Class Driver documentation contains more information on the non-standardized,
 345  *  class-specific functions which the user application can then use on the driver instances, such as data
 346  *  read and write routines. See each driver's individual documentation for more information on the
 347  *  class-specific functions.
 348  */
 349
 350 #ifndef __USB_H__
 351 #define __USB_H__
 352
 353         /* Includes: */
 354                 #include "HighLevel/USBMode.h"
 355
 356         /* Preprocessor Checks: */
 357                 #if (!defined(USB_SERIES_2_AVR) && !defined(USB_SERIES_4_AVR) && \
 358                      !defined(USB_SERIES_6_AVR) && !defined(USB_SERIES_7_AVR))
 359                         #error The currently selected AVR model is not supported under the USB component of the LUFA library.
 360                 #endif
 361
 362         /* Includes: */
 363                 #include "HighLevel/USBTask.h"
 364                 #include "HighLevel/USBInterrupt.h"
 365                 #include "HighLevel/Events.h"
 366                 #include "HighLevel/StdDescriptors.h"
 367
 368                 #include "LowLevel/LowLevel.h"
 369
 370                 #if defined(USB_CAN_BE_HOST) || defined(__DOXYGEN__)
 371                         #include "LowLevel/Host.h"
 372                         #include "LowLevel/HostChapter9.h"
 373                         #include "LowLevel/Pipe.h"
 374                 #endif
 375
 376                 #if defined(USB_CAN_BE_DEVICE) || defined(__DOXYGEN__)
 377                         #include "LowLevel/Device.h"
 378                         #include "LowLevel/DevChapter9.h"
 379                         #include "LowLevel/Endpoint.h"
 380                 #endif
 381
 382                 #if defined(USB_CAN_BE_BOTH) || defined(__DOXYGEN__)
 383                         #include "LowLevel/OTG.h"
 384                 #endif
 385
 386                 #include "HighLevel/ConfigDescriptor.h"
 387
 388 #endif
 389