USB.h 18.3 KB
 Dean Camera committed May 08, 2010 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 /* 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. */  Dean Camera committed Jun 17, 2010 40 /** @defgroup Group_USB USB Core - LUFA/Drivers/USB/USB.h  Dean Camera committed May 08, 2010 41 42 43  * * \section Sec_Dependencies Module Source Dependencies * The following files must be built with any user project that uses this module:  Dean Camera committed Jul 19, 2010 44 45 46 47  * - LUFA/Drivers/USB/LowLevel/Device.c (Makefile source module name: LUFA_SRC_USB) * - LUFA/Drivers/USB/LowLevel/Endpoint.c (Makefile source module name: LUFA_SRC_USB) * - LUFA/Drivers/USB/LowLevel/Host.c (Makefile source module name: LUFA_SRC_USB) * - LUFA/Drivers/USB/LowLevel/Pipe.c (Makefile source module name: LUFA_SRC_USB)  Dean Camera committed Jul 21, 2010 48  * - LUFA/Drivers/USB/LowLevel/USBController.c (Makefile source module name: LUFA_SRC_USB)  Dean Camera committed Jul 19, 2010 49 50  * - LUFA/Drivers/USB/LowLevel/USBInterrupt.c (Makefile source module name: LUFA_SRC_USB) * - LUFA/Drivers/USB/HighLevel/ConfigDescriptor.c (Makefile source module name: LUFA_SRC_USB)  Dean Camera committed Jul 21, 2010 51  * - LUFA/Drivers/USB/HighLevel/DeviceStandardReq.c (Makefile source module name: LUFA_SRC_USB)  Dean Camera committed Jul 19, 2010 52  * - LUFA/Drivers/USB/HighLevel/Events.c (Makefile source module name: LUFA_SRC_USB)  Dean Camera committed Jul 21, 2010 53  * - LUFA/Drivers/USB/HighLevel/HostStandardReq.c (Makefile source module name: LUFA_SRC_USB)  Dean Camera committed Jul 19, 2010 54  * - LUFA/Drivers/USB/HighLevel/USBTask.c (Makefile source module name: LUFA_SRC_USB)  Dean Camera committed May 08, 2010 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70  * * \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. */  Dean Camera committed Jun 17, 2010 71 /** @defgroup Group_USBClassDrivers USB Class Drivers  Dean Camera committed May 08, 2010 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 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 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274  * * 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. * * *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * \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 USB_ClassInfo_{Class Name}_Device_t, 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 Config section, and a State section. The Config * section contains the instance's configuration parameters, and must have all fields set by the user application * 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 State 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 {Class Name}_Device_ConfigureEndpoints() 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 * {Class Name}_Device_USBTask() 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 * {Class Name}_Device_ProcessControlRequest(), 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 must 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 may 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 USB_ClassInfo_{Class Name}_Host_t, 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 Config section, and a State section. The Config * section contains the instance's configuration parameters, and must have all fields set by the user application * 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 State 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 {Class Name}_Host_ConfigurePipes() 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 {Class Name}_EnumerationFailure_ErrorCodes_t enum * to indicate if the driver sucessfully initialized the instance and bound it to an interface in the attached device.  275 276  * 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  Dean Camera committed May 08, 2010 277 278 279 280 281 282 283 284 285 286 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 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374  * 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 * {Class Name}_Host_USBTask() 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 must 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 may 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"  Dean Camera committed Jul 21, 2010 375  #include "LowLevel/USBController.h"  Dean Camera committed May 08, 2010 376 377 378 379 380  #include "LowLevel/USBInterrupt.h" #if defined(USB_CAN_BE_HOST) || defined(__DOXYGEN__) #include "LowLevel/Host.h" #include "LowLevel/Pipe.h"  Dean Camera committed Jul 21, 2010 381  #include "HighLevel/HostStandardReq.h"  Dean Camera committed May 08, 2010 382 383 384 385 386  #endif #if defined(USB_CAN_BE_DEVICE) || defined(__DOXYGEN__) #include "LowLevel/Device.h" #include "LowLevel/Endpoint.h"  Dean Camera committed Jul 21, 2010 387  #include "HighLevel/DeviceStandardReq.h"  Dean Camera committed May 08, 2010 388 389 390 391 392 393 394 395  #endif #if defined(USB_CAN_BE_BOTH) || defined(__DOXYGEN__) #include "LowLevel/OTG.h" #endif #endif