X-Git-Url: http://git.linex4red.de/pub/USBasp.git/blobdiff_plain/cb779e3d7d32d7c43e0a45bb526de0a04135b0c7..0019fbd1294ccc9ecb0ac4ddb5d8c71efcf9597f:/LUFA/Drivers/USB/USB.h diff --git a/LUFA/Drivers/USB/USB.h b/LUFA/Drivers/USB/USB.h index 1e1c26e88..ff72a08f3 100644 --- a/LUFA/Drivers/USB/USB.h +++ b/LUFA/Drivers/USB/USB.h @@ -1,13 +1,13 @@ /* LUFA Library - Copyright (C) Dean Camera, 2010. + Copyright (C) Dean Camera, 2011. dean [at] fourwalledcubicle [dot] com www.lufa-lib.org */ /* - Copyright 2010 Dean Camera (dean [at] fourwalledcubicle [dot] com) + Copyright 2011 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 @@ -54,8 +54,9 @@ * - LUFA/Drivers/USB/HighLevel/HostStandardReq.c (Makefile source module name: LUFA_SRC_USB) * - LUFA/Drivers/USB/HighLevel/PipeStream.c (Makefile source module name: LUFA_SRC_USB) * - LUFA/Drivers/USB/HighLevel/USBTask.c (Makefile source module name: LUFA_SRC_USB) + * - LUFA/Drivers/USB/Class/Common/HIDParser.c (Makefile source module name: LUFA_SRC_USB) * - * \section Module Description + * \section Sec_ModDescription 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. @@ -139,20 +140,20 @@ * 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 + * \subsection Sec_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 + * 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 + * drivers lie; multiple interfaces of the same class simply require more instances of the Class Driver's \c USB_ClassInfo_* * structure. * - * Inside the ClassInfo structure lies two sections, a Config section, and a State section. The Config + * Inside the ClassInfo structure lies two sections, a \c Config section, and a \c State section. The \c 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 + * The \c State section of the \c USB_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: @@ -173,11 +174,11 @@ * \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 + * 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 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 - * the same class type can be initialized like thus: + * the same class type can be initialized like this: * * \code * void EVENT_USB_Device_ConfigurationChanged(void) @@ -190,7 +191,7 @@ * \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 + * {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 * separate instance, just like the main USB maintenance routine \ref USB_USBTask(): @@ -213,24 +214,24 @@ * \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: + * {Class Name}_Device_ProcessControlRequest(), which should be called when the + * \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: * * \code - * void EVENT_USB_Device_UnhandledControlRequest(void) + * void EVENT_USB_Device_ControlRequest(void) * { * Audio_Device_ProcessControlRequest(&My_Audio_Interface); * } * \endcode * - * Each class driver may also define a set of callback functions (which are prefixed by "CALLBACK_" + * Each class driver may also define a set of callback functions (which are prefixed by \c 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 + * also define a set of events (identifiable by their prefix of \c 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, @@ -238,20 +239,20 @@ * 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 + * \subsection Sec_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 + * 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 + * drivers lie; multiple interfaces of the same class simply require more instances of the Class Driver's \c USB_ClassInfo_* * structure. * - * Inside the ClassInfo structure lies two sections, a Config section, and a State section. The Config + * Inside the \c USB_ClassInfo_* structure lies two sections, a \c Config section, and a \c State section. The \c 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 + * The \c State section of the \c USB_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: @@ -270,9 +271,9 @@ * }; * \endcode * - * To initialize the Class driver instance, the driver's {Class Name}_Host_ConfigurePipes() function + * 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 + * will return an error code from the class driver's {Class Name}_EnumerationFailure_ErrorCodes_t enum * to indicate if the driver successfully initialized the instance and bound it to an interface in the attached device. * 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 the same class type can be initialized. A fragment of a Class Driver @@ -314,7 +315,7 @@ * 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 + * {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 * separate instance, just like the main USB maintenance routine \ref USB_USBTask(): @@ -339,10 +340,10 @@ * } * \endcode * - * Each class driver may also define a set of callback functions (which are prefixed by "CALLBACK_" + * Each class driver may also define a set of callback functions (which are prefixed by \c 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 + * also define a set of events (identifiable by their prefix of \c 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,