X-Git-Url: http://git.linex4red.de/pub/USBasp.git/blobdiff_plain/b37d77eab32d171ad7b28157a924a4026e2aebd1..b8fd4dd51c3fb1da7c543c44e2ab67f5f0ea20ac:/LUFA/Drivers/USB/USB.h

diff --git a/LUFA/Drivers/USB/USB.h b/LUFA/Drivers/USB/USB.h
index bae0450eb..731704ea8 100644
--- a/LUFA/Drivers/USB/USB.h
+++ b/LUFA/Drivers/USB/USB.h
@@ -3,7 +3,7 @@
      Copyright (C) Dean Camera, 2010.
 
   dean [at] fourwalledcubicle [dot] com
-      www.fourwalledcubicle.com
+           www.lufa-lib.org
 */
 
 /*
@@ -55,7 +55,7 @@
  *    - LUFA/Drivers/USB/HighLevel/PipeStream.c <i>(Makefile source module name: LUFA_SRC_USB)</i>
  *    - LUFA/Drivers/USB/HighLevel/USBTask.c <i>(Makefile source module name: LUFA_SRC_USB)</i>
  *
- *  \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,7 +139,7 @@
  *  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 <i>USB_ClassInfo_<b>{Class Name}</b>_Device_t</i>, and are used to hold the
@@ -214,14 +214,14 @@
  *
  *  The final standardized Device Class Driver function is the Control Request handler function
  *  <i><b>{Class Name}</b>_Device_ProcessControlRequest()</i>, 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:
+ *  \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);
  *  }
@@ -238,7 +238,7 @@
  *  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 <i>USB_ClassInfo_<b>{Class Name}</b>_Host_t</i>, and are used to hold the