michi/qmk_firmware
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Spell check code and manual pages. Remove custom Doxygen CSS stylesheet, as the new 1.7 Doxygen's default stylesheet is much better.

Browse Source
This commit is contained in:
Dean Camera
2010-06-16 11:01:01 +00:00
parent 13ea700b35
commit 711542ee89
40 changed files with 140 additions and 687 deletions
Download Patch File Download Diff File Expand all files Collapse all files
LUFA/ManPages/CompileTimeTokens.txt
+8 -8
View File
@@ -7,7 +7,7 @@
/** \page Page_TokenSummary Summary of Compile Tokens
*
* The following lists all the possible tokens which can be defined in a project makefile, and passed to the
* compiler via the -D switch, to alter the LUFA library code. These tokens may alter the library behaviour,
* compiler via the -D switch, to alter the LUFA library code. These tokens may alter the library behavior,
* or remove features unused by a given application in order to save flash space.
*
*
@@ -28,7 +28,7 @@
* By default, the USB HID Host class driver is designed to work with HID devices using either the Boot or Report HID
* communication protocols. On devices where the Report protocol is not used (i.e. in applications where only basic
* Mouse or Keyboard operation is desired, using boot compatible devices), the code responsible for the Report protocol
* mode can be removed to save space in the compiled application by defining this token. When defined, it is still neccesary
* mode can be removed to save space in the compiled application by defining this token. When defined, it is still necessary
* to explicitly put the attached device into Boot protocol mode via a call to \ref HID_Host_SetBootProtocol().
*
* <b>HID_STATETABLE_STACK_DEPTH</b>=<i>x</i> - ( \ref Group_HIDParser ) \n
@@ -61,7 +61,7 @@
*
* <b>HID_MAX_REPORT_IDS</b>=<i>x</i> - ( \ref Group_HIDParser ) \n
* HID reports may contain several report IDs, to logically distinguish grouped device data from one another - for example, a combination
* keyboard and mouse might use report IDs to seperate the keyboard reports from the mouse reports. In order to determine the size of each
* keyboard and mouse might use report IDs to separate the keyboard reports from the mouse reports. In order to determine the size of each
* report, and thus know how many bytes must be read or written, the size of each report (IN, OUT and FEATURE) must be calculated and
* stored. This token may be defined to a non-zero 8-bit value to set the maximum number of report IDs in a device which can be processed
* and their sizes calculated/stored into the resultant processed report structure. If not defined, this defaults to the value indicated in
@@ -83,11 +83,11 @@
* By default, streams are transferred internally via a loop, sending or receiving one byte per iteration before checking for a bank full
* or empty condition. This allows for multiple stream functions to be chained together easily, as there are no alignment issues. However,
* this can lead to heavy performance penalties in applications where large streams are used frequently. When this compile time option is
* used, bytes are sent or recevied in groups of 8 bytes at a time increasing performance at the expense of a larger flash memory consumption
* used, bytes are sent or received in groups of 8 bytes at a time increasing performance at the expense of a larger flash memory consumption
* due to the extra code required to deal with byte alignment.
*
* <b>USE_STATIC_OPTIONS</b>=<i>x</i> - ( \ref Group_USBManagement ) \n
* By default, the USB_Init() function accepts dynamic options at runtime to alter the library behaviour, including whether the USB pad
* By default, the USB_Init() function accepts dynamic options at runtime to alter the library behavior, including whether the USB pad
* voltage regulator is enabled, and the device speed when in device mode. By defining this token to a mask comprised of the USB options
* mask defines usually passed as the Options parameter to USB_Init(), the resulting compiled binary can be decreased in size by removing
* the dynamic options code, and replacing it with the statically set options. When defined, the USB_Init() function no longer accepts an
@@ -143,7 +143,7 @@
* binary.
*
* <b>DEVICE_STATE_AS_GPIOR</b> - ( \ref Group_Device ) \n
* One of the most frequenty used global variables in the stack is the USB_DeviceState global, which indicates the current state of
* One of the most frequently used global variables in the stack is the USB_DeviceState global, which indicates the current state of
* the Device State Machine. To reduce the amount of code and time required to access and modify this global in an application, this token
* may be defined to a value between 0 and 2 to fix the state variable into one of the three general purpose IO registers inside the AVR
* reserved for application use. When defined, the corresponding GPIOR register should not be used within the user application except
@@ -161,7 +161,7 @@
* endpoints internally, saving space. Generally, this is usually only useful in (some) bootloaders and is best avoided.
*
* <b>INTERRUPT_CONTROL_ENDPOINT</b> - ( \ref Group_USBManagement ) \n
* Some applications prefer to not call the USB_USBTask() management task reguarly while in device mode, as it can complicate code significantly.
* Some applications prefer to not call the USB_USBTask() management task regularly while in device mode, as it can complicate code significantly.
* Instead, when device mode is used this token can be passed to the library via the -D switch to allow the library to manage the USB control
* endpoint entirely via USB controller interrupts asynchronously to the user application. When defined, USB_USBTask() does not need to be called
* when in USB device mode.
@@ -181,7 +181,7 @@
* This section describes compile tokens which affect USB driver stack of the LUFA library when used in Host mode.
*
* <b>HOST_STATE_AS_GPIOR</b> - ( \ref Group_Host ) \n
* One of the most frequenty used global variables in the stack is the USB_HostState global, which indicates the current state of
* One of the most frequently used global variables in the stack is the USB_HostState global, which indicates the current state of
* the Host State Machine. To reduce the amount of code and time required to access and modify this global in an application, this token
* may be defined to a value between 0 and 2 to fix the state variable into one of the three general purpose IO registers inside the AVR
* reserved for application use. When defined, the corresponding GPIOR register should not be used within the user application except