USB.h 18.8 KB
Newer Older
1
2
/*
             LUFA Library
3
     Copyright (C) Dean Camera, 2011.
4

5
  dean [at] fourwalledcubicle [dot] com
6
           www.lufa-lib.org
7
8
9
*/

/*
10
  Copyright 2011  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
17
18
  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
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
  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.
 */

40
/** @defgroup Group_USB USB Core - LUFA/Drivers/USB/USB.h
41
42
43
 *
 *  \section Sec_Dependencies Module Source Dependencies
 *  The following files must be built with any user project that uses this module:
44
45
46
47
 *    - LUFA/Drivers/USB/LowLevel/Device.c <i>(Makefile source module name: LUFA_SRC_USB)</i>
 *    - LUFA/Drivers/USB/LowLevel/Endpoint.c <i>(Makefile source module name: LUFA_SRC_USB)</i>
 *    - LUFA/Drivers/USB/LowLevel/Host.c <i>(Makefile source module name: LUFA_SRC_USB)</i>
 *    - LUFA/Drivers/USB/LowLevel/Pipe.c <i>(Makefile source module name: LUFA_SRC_USB)</i>
48
 *    - LUFA/Drivers/USB/LowLevel/USBController.c <i>(Makefile source module name: LUFA_SRC_USB)</i>
49
50
 *    - LUFA/Drivers/USB/LowLevel/USBInterrupt.c <i>(Makefile source module name: LUFA_SRC_USB)</i>
 *    - LUFA/Drivers/USB/HighLevel/ConfigDescriptor.c <i>(Makefile source module name: LUFA_SRC_USB)</i>
51
 *    - LUFA/Drivers/USB/HighLevel/DeviceStandardReq.c <i>(Makefile source module name: LUFA_SRC_USB)</i>
52
 *    - LUFA/Drivers/USB/HighLevel/Events.c <i>(Makefile source module name: LUFA_SRC_USB)</i>
53
 *    - LUFA/Drivers/USB/HighLevel/EndpointStream.c <i>(Makefile source module name: LUFA_SRC_USB)</i>
54
 *    - LUFA/Drivers/USB/HighLevel/HostStandardReq.c <i>(Makefile source module name: LUFA_SRC_USB)</i>
55
 *    - LUFA/Drivers/USB/HighLevel/PipeStream.c <i>(Makefile source module name: LUFA_SRC_USB)</i>
56
 *    - LUFA/Drivers/USB/HighLevel/USBTask.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>
58
 *
59
 *  \section Sec_ModDescription Module Description
60
61
62
63
64
65
66
67
68
69
70
71
72
73
 *  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.
 */

74
/** @defgroup Group_USBClassDrivers USB Class Drivers
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
 *
 *  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>
90
91
92
 *   <th width="100px">USB Class</th>
 *   <th width="90px">Device Mode</th>
 *   <th width="90px">Host Mode</th>
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
 *  </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.
 *
143
 *  \subsection Sec_ClassDriverDevice Device Mode Class Drivers
144
 *  Implementing a Device Mode Class Driver in a user application requires a number of steps to be followed. Firstly,
145
 *  the module configuration and state structure must be added to the project source. These structures are named in a
146
 *  similar manner between classes, that of <tt>USB_ClassInfo_<i>{Class Name}</i>_Device_t</tt>, and are used to hold the
147
 *  complete state and configuration for each class instance. Multiple class instances is where the power of the class
148
 *  drivers lie; multiple interfaces of the same class simply require more instances of the Class Driver's \c USB_ClassInfo_*
149
150
 *  structure.
 *
151
 *  Inside the ClassInfo structure lies two sections, a \c Config section, and a \c State section. The \c Config
152
153
154
155
 *  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.
 *
156
 *  The \c State section of the \c USB_ClassInfo_* structures are designed to be controlled by the Class Drivers only for
157
158
159
160
161
162
163
164
165
166
 *  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,
167
 *
168
169
170
171
172
173
174
175
176
 *              .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.
 *
177
 *  To initialize the Class driver instance, the driver's <tt><i>{Class Name}</i>_Device_ConfigureEndpoints()</tt> function
178
 *  should be called in response to the \ref EVENT_USB_Device_ConfigurationChanged() event. This function will return a
179
180
 *  boolean value if the driver successfully 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 separate instances of
181
 *  the same class type can be initialized like this:
182
183
184
185
186
 *
 *  \code
 *  void EVENT_USB_Device_ConfigurationChanged(void)
 *  {
 *  	LEDs_SetAllLEDs(LEDMASK_USB_READY);
187
 *
188
189
190
191
 *  	if (!(Audio_Device_ConfigureEndpoints(&My_Audio_Interface)))
 *  	  LEDs_SetAllLEDs(LEDMASK_USB_ERROR);
 *  }
 *  \endcode
192
 *
193
 *  Once initialized, it is important to maintain the class driver's state by repeatedly calling the Class Driver's
194
 *  <tt><i>{Class Name}</i>_Device_USBTask()</tt> function in the main program loop. The exact implementation of this
195
196
 *  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
197
 *  separate instance, just like the main USB maintenance routine \ref USB_USBTask():
198
199
200
201
202
 *
 *  \code
 *  int main(void)
 *  {
 *      SetupHardware();
203
 *
204
 *      LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
205
 *
206
207
208
 *      for (;;)
 *      {
 *          Create_And_Process_Samples();
209
 *
210
211
212
213
214
215
216
 *          Audio_Device_USBTask(&My_Audio_Interface);
 *          USB_USBTask();
 *      }
 *  }
 *  \endcode
 *
 *  The final standardized Device Class Driver function is the Control Request handler function
217
 *  <tt><i>{Class Name}</i>_Device_ProcessControlRequest()</tt>, which should be called when the
218
219
220
221
222
 *  \ref EVENT_USB_Device_ControlRequest() 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:
223
224
 *
 *  \code
225
 *  void EVENT_USB_Device_ControlRequest(void)
226
227
228
229
230
 *  {
 *      Audio_Device_ProcessControlRequest(&My_Audio_Interface);
 *  }
 *  \endcode
 *
231
 *  Each class driver may also define a set of callback functions (which are prefixed by \c CALLBACK_*
232
233
 *  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
234
 *  also define a set of events (identifiable by their prefix of \c EVENT_* in the function's name), which
235
236
237
238
239
240
241
 *  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.
 *
242
 *  \subsection Sec_ClassDriverHost Host Mode Class Drivers
243
 *  Implementing a Host Mode Class Driver in a user application requires a number of steps to be followed. Firstly,
244
 *  the module configuration and state structure must be added to the project source. These structures are named in a
245
 *  similar manner between classes, that of <tt>USB_ClassInfo_<b>{Class Name}</b>_Host_t</tt>, and are used to hold the
246
 *  complete state and configuration for each class instance. Multiple class instances is where the power of the class
247
 *  drivers lie; multiple interfaces of the same class simply require more instances of the Class Driver's \c USB_ClassInfo_*
248
249
 *  structure.
 *
250
 *  Inside the \c USB_ClassInfo_* structure lies two sections, a \c Config section, and a \c State section. The \c Config
251
252
253
254
 *  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.
 *
255
 *  The \c State section of the \c USB_ClassInfo_* structures are designed to be controlled by the Class Drivers only for
256
257
258
259
260
261
262
263
264
265
266
 *  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,
267
 *
268
269
270
271
272
273
 *              .DataOUTPipeNumber      = 2,
 *              .DataOUTPipeDoubleBank  = false,
 *          },
 *  };
 *  \endcode
 *
274
 *  To initialize the Class driver instance, the driver's <tt><b>{Class Name}</b>_Host_ConfigurePipes()</tt> function
275
 *  should be called in response to the host state machine entering the \ref HOST_STATE_Addressed state. This function
276
 *  will return an error code from the class driver's <tt><b>{Class Name}</b>_EnumerationFailure_ErrorCodes_t</tt> enum
277
 *  to indicate if the driver successfully initialized the instance and bound it to an interface in the attached device.
278
 *  Like all the class driver functions, this function takes in the address of the specific instance you wish to initialize -
279
 *  in this manner, multiple separate instances of the same class type can be initialized. A fragment of a Class Driver
280
281
282
283
284
285
286
 *  based Host mode application may look like the following:
 *
 *  \code
 *      switch (USB_HostState)
 *      {
 *          case HOST_STATE_Addressed:
 *              LEDs_SetAllLEDs(LEDMASK_USB_ENUMERATING);
287
 *
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
 *              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
318
 *  <tt><b>{Class Name}</b>_Host_USBTask()</tt> function in the main program loop. The exact implementation of this
319
320
 *  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
321
 *  separate instance, just like the main USB maintenance routine \ref USB_USBTask():
322
323
324
325
326
 *
 *  \code
 *  int main(void)
 *  {
 *      SetupHardware();
327
 *
328
 *      LEDs_SetAllLEDs(LEDMASK_USB_NOTREADY);
329
 *
330
331
332
333
334
 *      for (;;)
 *      {
 *          switch (USB_HostState)
 *          {
 *             // Host state machine handling here
335
336
 *          }
 *
337
338
339
340
341
342
 *          MIDI_Host_USBTask(&My_Audio_Interface);
 *          USB_USBTask();
 *      }
 *  }
 *  \endcode
 *
343
 *  Each class driver may also define a set of callback functions (which are prefixed by \c CALLBACK_*
344
345
 *  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
346
 *  also define a set of events (identifiable by their prefix of \c EVENT_* in the function's name), which
347
348
349
350
351
352
353
 *  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.
 */
354

355
356
357
358
359
360
361
362
363
364
365
#ifndef __USB_H__
#define __USB_H__

	/* Macros: */
		#if !defined(__DOXYGEN__)
			#define __INCLUDE_FROM_USB_DRIVER
		#endif

	/* Includes: */
		#include "HighLevel/USBMode.h"

366
	/* Preprocessor Checks: */
367
368
369
370
		#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
371

372
373
374
375
376
377
	/* Includes: */
		#include "HighLevel/USBTask.h"
		#include "HighLevel/Events.h"
		#include "HighLevel/StdDescriptors.h"
		#include "HighLevel/ConfigDescriptor.h"

378
		#include "LowLevel/USBController.h"
379
		#include "LowLevel/USBInterrupt.h"
380

381
382
383
		#if defined(USB_CAN_BE_HOST) || defined(__DOXYGEN__)
			#include "LowLevel/Host.h"
			#include "LowLevel/Pipe.h"
384
			#include "HighLevel/HostStandardReq.h"
385
			#include "HighLevel/PipeStream.h"
386
		#endif
387

388
389
390
		#if defined(USB_CAN_BE_DEVICE) || defined(__DOXYGEN__)
			#include "LowLevel/Device.h"
			#include "LowLevel/Endpoint.h"
391
			#include "HighLevel/DeviceStandardReq.h"
392
			#include "HighLevel/EndpointStream.h"
393
		#endif
394

395
396
397
		#if defined(USB_CAN_BE_BOTH) || defined(__DOXYGEN__)
			#include "LowLevel/OTG.h"
		#endif
398
399
400
401
402
403
404
405
406
		
		#include "Class/Audio.h"
		#include "Class/CDC.h"
		#include "Class/HID.h"
		#include "Class/MassStorage.h"
		#include "Class/MIDI.h"
		#include "Class/Printer.h"
		#include "Class/RNDIS.h"
		#include "Class/StillImage.h"
407

408
409
#endif