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