X-Git-Url: http://git.linex4red.de/pub/USBasp.git/blobdiff_plain/dea897ef571bf33bc80c0e1dbf35601009582f3d..77a9df36a77d2523dd2bc24fa17f9f04c6c175c5:/LUFA/Drivers/USB/USB.h
diff --git a/LUFA/Drivers/USB/USB.h b/LUFA/Drivers/USB/USB.h
index 165f6577b..fa4fcf1c3 100644
--- a/LUFA/Drivers/USB/USB.h
+++ b/LUFA/Drivers/USB/USB.h
@@ -1,21 +1,21 @@
/*
LUFA Library
- Copyright (C) Dean Camera, 2010.
-
+ Copyright (C) Dean Camera, 2011.
+
dean [at] fourwalledcubicle [dot] com
- www.fourwalledcubicle.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
+ 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
+ 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
+ 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
@@ -34,33 +34,36 @@
* 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.
+ * the individual USB driver submodule headers.
*/
-/** @defgroup Group_USB USB Core - LUFA/Drivers/USB/USB.h
+/** \defgroup Group_USB USB Core - LUFA/Drivers/USB/USB.h
*
* \section Sec_Dependencies Module Source Dependencies
* The following files must be built with any user project that uses this module:
- * - LUFA/Drivers/USB/LowLevel/DevChapter9.c
- * - LUFA/Drivers/USB/LowLevel/Device.c
- * - LUFA/Drivers/USB/LowLevel/Endpoint.c
- * - LUFA/Drivers/USB/LowLevel/Host.c
- * - LUFA/Drivers/USB/LowLevel/HostChapter9.c
- * - LUFA/Drivers/USB/LowLevel/LowLevel.c
- * - LUFA/Drivers/USB/LowLevel/Pipe.c
- * - LUFA/Drivers/USB/LowLevel/USBInterrupt.c
- * - LUFA/Drivers/USB/HighLevel/ConfigDescriptor.c
- * - LUFA/Drivers/USB/HighLevel/Events.c
- * - LUFA/Drivers/USB/HighLevel/USBTask.c
- *
- * \section Module Description
- * Driver and framework for the USB controller hardware on the USB series of AVR microcontrollers. This module
+ * - LUFA/Drivers/USB/Core/ConfigDescriptor.c (Makefile source module name: LUFA_SRC_USB)
+ * - LUFA/Drivers/USB/Core/DeviceStandardReq.c (Makefile source module name: LUFA_SRC_USB)
+ * - LUFA/Drivers/USB/Core/Events.c (Makefile source module name: LUFA_SRC_USB)
+ * - LUFA/Drivers/USB/Core/HostStandardReq.c (Makefile source module name: LUFA_SRC_USB)
+ * - LUFA/Drivers/USB/Core/USBTask.c (Makefile source module name: LUFA_SRC_USB)
+ * - LUFA/Drivers/USB/Core/ARCH/Device_ARCH.c (Makefile source module name: LUFA_SRC_USB)
+ * - LUFA/Drivers/USB/Core/ARCH/Endpoint_ARCH.c (Makefile source module name: LUFA_SRC_USB)
+ * - LUFA/Drivers/USB/Core/ARCH/EndpointStream_ARCH.c (Makefile source module name: LUFA_SRC_USB)
+ * - LUFA/Drivers/USB/Core/ARCH/Host_ARCH.c (Makefile source module name: LUFA_SRC_USB)
+ * - LUFA/Drivers/USB/Core/ARCH/Pipe_ARCH.c (Makefile source module name: LUFA_SRC_USB)
+ * - LUFA/Drivers/USB/Core/ARCH/PipeStream_ARCH.c (Makefile source module name: LUFA_SRC_USB)
+ * - LUFA/Drivers/USB/Core/ARCH/USBController_ARCH.c (Makefile source module name: LUFA_SRC_USB)
+ * - LUFA/Drivers/USB/Core/ARCH/USBInterrupt_ARCH.c (Makefile source module name: LUFA_SRC_USB)
+ * - LUFA/Drivers/USB/Class/Common/HIDParser.c (Makefile source module name: LUFA_SRC_USB)
+ *
+ * \section Sec_ModDescription Module Description
+ * Driver and framework for the USB controller of the selected architecture and microcontroller model. 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.
+ * require any additional timers or other peripherals 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
@@ -68,7 +71,7 @@
* of USB management functions found \ref Group_USBManagement.
*/
-/** @defgroup Group_USBClassDrivers USB Class Drivers
+/** \defgroup Group_USBClassDrivers USB Class Drivers
*
* 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
@@ -84,14 +87,14 @@
*
*
*
- * | USB Class |
- * Device Mode |
- * Host Mode |
+ * USB Class |
+ * Device Mode |
+ * Host Mode |
*
*
* | Audio |
* Yes |
- * No |
+ * Yes |
*
*
* | CDC |
@@ -137,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
- * 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
+ * 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 \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:
@@ -161,7 +164,7 @@
* .Config =
* {
* .StreamingInterfaceNumber = 1,
- *
+ *
* .DataINEndpointNumber = 1,
* .DataINEndpointSize = 256,
* },
@@ -171,39 +174,39 @@
* \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 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:
+ * boolean true 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 this:
*
* \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
+ * {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():
+ * separate 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();
* }
@@ -211,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,
@@ -236,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
- * 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
+ * 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 \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:
@@ -261,19 +264,19 @@
* {
* .DataINPipeNumber = 1,
* .DataINPipeDoubleBank = false,
- *
+ *
* .DataOUTPipeNumber = 2,
* .DataOUTPipeDoubleBank = false,
* },
* };
* \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
- * to indicate if the driver sucessfully 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 seperate instances of the same class type can be initialized. A fragment of a Class Driver
+ * 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
* based Host mode application may look like the following:
*
* \code
@@ -281,7 +284,7 @@
* {
* case HOST_STATE_Addressed:
* LEDs_SetAllLEDs(LEDMASK_USB_ENUMERATING);
- *
+ *
* uint16_t ConfigDescriptorSize;
* uint8_t ConfigDescriptorData[512];
*
@@ -312,35 +315,35 @@
* 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
- * seperate instance, just like the main USB maintenance routine \ref USB_USBTask():
+ * separate 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_"
+ * 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,
@@ -348,48 +351,51 @@
* 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
+ #define __INCLUDE_FROM_USB_DRIVER
/* Includes: */
- #include "HighLevel/USBMode.h"
+ #include "../../Common/Common.h"
+ #include "Core/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"
+ #include "Core/USBTask.h"
+ #include "Core/Events.h"
+ #include "Core/StdDescriptors.h"
+ #include "Core/ConfigDescriptor.h"
+ #include "Core/USBController.h"
+ #include "Core/USBInterrupt.h"
- #include "LowLevel/LowLevel.h"
- #include "LowLevel/USBInterrupt.h"
-
#if defined(USB_CAN_BE_HOST) || defined(__DOXYGEN__)
- #include "LowLevel/Host.h"
- #include "LowLevel/HostChapter9.h"
- #include "LowLevel/Pipe.h"
+ #include "Core/Host.h"
+ #include "Core/Pipe.h"
+ #include "Core/HostStandardReq.h"
+ #include "Core/PipeStream.h"
#endif
-
+
#if defined(USB_CAN_BE_DEVICE) || defined(__DOXYGEN__)
- #include "LowLevel/Device.h"
- #include "LowLevel/DevChapter9.h"
- #include "LowLevel/Endpoint.h"
+ #include "Core/Device.h"
+ #include "Core/Endpoint.h"
+ #include "Core/DeviceStandardReq.h"
+ #include "Core/EndpointStream.h"
#endif
-
+
#if defined(USB_CAN_BE_BOTH) || defined(__DOXYGEN__)
- #include "LowLevel/OTG.h"
+ #include "Core/OTG.h"
#endif
-
+
+ #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"
+
#endif