qmk_firmware/LUFA/ManPages/WhyUseLUFA.txt

/** \file
 *
 *  This file contains special DoxyGen information for the generation of the main page and other special
 *  documentation pages. It is not a project source file.
 */

/**
 *  \page Page_WhyUseLUFA Why Use LUFA?
 *
 *  The LUFA Library has many advantages over implementing the code required to drive the USB AVRs directly.
 *  It is much more preferable to incorporate LUFA into your existing projects - or even make a new project
 *  using LUFA - than it is to start from scratch and use the USB AVR registers directly. Some of these reasons
 *  are:
 *
 *  - <b>Portability:</b>
 *    The LUFA stack is designed to run (at some capacity) on the entire Atmel range of USB AVRs, regardless of the
 *    exact USB controller revision used. If you decide to implement your own USB stack, you will either need to
 *    code around the differences between each USB AVR controller's implementation between different chip models, or
 *    require your code to run on only one specific USB AVR model series.
 *
 *  - <b>Speed of Development:</b>
 *    LUFA ships with a wide range of pre-made demos, bootloaders and projects for you to try, learn and extend. Each
 *    of these demos are tested (where possible) across as many USB AVRs and Operating Systems as possible, to ensure
 *    that they work under as many conditions as possible. In addition, there are inbuilt class drivers for several of
 *    the USB classes which you can make use of in your projects with minimal effort.
 *
 *  - <b>Maintainability:</b>
 *    As LUFA takes care of much of the USB implementation, you can be left to focusing on your actual project's
 *    functionality, rather than being held back developing and debugging the USB stack code. Since LUFA uses clear APIs
 *    for USB development, your code will be more readable than if it had the low level USB stack code integrated into
 *    it directly. Updating the LUFA library is a simple folder-replacement and gives new features and bug fixes in
 *    seconds each time a new release is made.
 *
 *  - <b>Size:</b>
 *    Not just requiring less code to make complex USB devices, LUFA (under most cases with the correct compile options)
 *    requires less FLASH space than Atmel's stack, meaning more space for the user application*.
 *
 *  - <b>Support:</b>
 *    Since many people are now using LUFA in their own projects, you can take advantage of other's knowledge when you run
 *    into difficulties or need some advice. In addition, you can also email the library author to receive personalized
 *    support when you need it (subject to author's schedule).
 *
 *   <small>* Atmel Stack Mouse Device Demo 4218 bytes, LUFA Mouse Low Level Device Demo 3472 bytes, under identical build
 *   environments</small>
 */
Add svn:eol-style property to source files, so that the line endings are correctly converted to the target system's native end of line style. 15 years ago			`/** \file`
			`*`
			`* This file contains special DoxyGen information for the generation of the main page and other special`
			`* documentation pages. It is not a project source file.`
			`*/`

			`/**`
			`* \page Page_WhyUseLUFA Why Use LUFA?`
			`*`
			`* The LUFA Library has many advantages over implementing the code required to drive the USB AVRs directly.`
			`* It is much more preferable to incorporate LUFA into your existing projects - or even make a new project`
			`* using LUFA - than it is to start from scratch and use the USB AVR registers directly. Some of these reasons`
			`* are:`
			`*`
			`* - <b>Portability:</b>`
			`* The LUFA stack is designed to run (at some capacity) on the entire Atmel range of USB AVRs, regardless of the`
			`* exact USB controller revision used. If you decide to implement your own USB stack, you will either need to`
			`* code around the differences between each USB AVR controller's implementation between different chip models, or`
			`* require your code to run on only one specific USB AVR model series.`
			`*`
			`* - <b>Speed of Development:</b>`
			`* LUFA ships with a wide range of pre-made demos, bootloaders and projects for you to try, learn and extend. Each`
			`* of these demos are tested (where possible) across as many USB AVRs and Operating Systems as possible, to ensure`
			`* that they work under as many conditions as possible. In addition, there are inbuilt class drivers for several of`
			`* the USB classes which you can make use of in your projects with minimal effort.`
			`*`
			`* - <b>Maintainability:</b>`
			`* As LUFA takes care of much of the USB implementation, you can be left to focusing on your actual project's`
			`* functionality, rather than being held back developing and debugging the USB stack code. Since LUFA uses clear APIs`
			`* for USB development, your code will be more readable than if it had the low level USB stack code integrated into`
			`* it directly. Updating the LUFA library is a simple folder-replacement and gives new features and bug fixes in`
			`* seconds each time a new release is made.`
			`*`
			`* - <b>Size:</b>`
			`* Not just requiring less code to make complex USB devices, LUFA (under most cases with the correct compile options)`
			`* requires less FLASH space than Atmel's stack, meaning more space for the user application*.`
			`*`
			`* - <b>Support:</b>`
Spell check code and manual pages. Remove custom Doxygen CSS stylesheet, as the new 1.7 Doxygen's default stylesheet is much better. 15 years ago			`* Since many people are now using LUFA in their own projects, you can take advantage of other's knowledge when you run`
			`* into difficulties or need some advice. In addition, you can also email the library author to receive personalized`
Add svn:eol-style property to source files, so that the line endings are correctly converted to the target system's native end of line style. 15 years ago			`* support when you need it (subject to author's schedule).`
			`*`
Altered all endpoint/pipe stream transfers so that the new BytesProcessed parameter now points to a location where the number of bytes in the transfer that have been completed can be stored (or NULL if entire transaction should be performed in one chunk). Added new Endpoint_Null_Stream() and Pipe_Null_stream() functions. Removed the NO_STREAM_CALLBACKS compile time option due to the new partial stream transfer feature replacing it. Fixed errors in the incomplete Test and Measurement device demo preventing proper operation (thanks to Pavel Plotnikov). 14 years ago			`* <small>* Atmel Stack Mouse Device Demo 4218 bytes, LUFA Mouse Low Level Device Demo 3472 bytes, under identical build`
Add svn:eol-style property to source files, so that the line endings are correctly converted to the target system's native end of line style. 15 years ago			`* environments</small>`
			`*/`
Clean up excessive whitespace at the end of each line using the wspurify tool made by Laszlo Monda 14 years ago