mirror of
https://github.com/dougg3/mac-rom-simm-programmer.git
synced 2024-12-01 04:49:22 +00:00
8aec8807c9
A whole bunch of files in this project had DOS line endings. This is due to how I started working on it on a Windows machine with little Git experience. Now it's inconsistent so I'm fixing it.
53 lines
3.6 KiB
Plaintext
53 lines
3.6 KiB
Plaintext
/** \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_LUFAvsAtmelStack LUFA vs the Atmel 8-bit USB AVR Stack
|
|
*
|
|
* Atmel offers an official 8-bit USB AVR stack, which may be incorporated into user projects and products. As LUFA and the Atmel
|
|
* stack aims to give roughly the same functionality to a design, it is often asked what advantages LUFA carries over the official
|
|
* Atmel USB stack for the 8-bit USB AVRs. Below are just some of the advantages to choosing LUFA over the official Atmel stack.
|
|
*
|
|
* - <b>Licensing:</b>
|
|
* LUFA is released under a very permissive MIT license (see \ref Page_LicenseInfo), while the Atmel stack carries several
|
|
* restrictions as to how and where it can be used. LUFA's licensing should be suitable for both Commercial and Non-Commercial
|
|
* entities alike.
|
|
*
|
|
* - <b>Demos and Projects:</b>
|
|
* Unlike the Atmel stack, LUFA comes with many different Device and Host mode Demos and Projects ready to run out of the box.
|
|
* Atmel favors separate downloads for each of their (small set) of USB AVR demos, which requires more time and offers less
|
|
* to the end-user. LUFA also contains several open source Bootloaders, which can be modified as the user wishes to suit his or
|
|
* her application, instead of being forced to use Atmel's single prebuilt (closed-source) DFU bootloader.
|
|
*
|
|
* - <b>Central Library Code:</b>
|
|
* LUFA is designed to allow the central library core code to be shared amongst several projects, so long as the compiled object
|
|
* files are cleaned between different projects. This is in direct contrast to the Atmel library, which is strongly coupled to the
|
|
* project it is integrated with. Using LUFA allows for only one copy of the library core to be needed for all applications, and
|
|
* makes updating the library used in all projects a trivial copy-and-paste process.
|
|
*
|
|
* - <b>Clean API:</b>
|
|
* One of the main design goals of LUFA is to make the API easy to use. While LUFA is a fluid project which has undergone many
|
|
* API improvements, the API is arguably much nicer to use and easier to understand than the equivalent Atmel stack code. LUFA's
|
|
* API is also more complete than the Atmel stack, and contains many features to speed up application development.
|
|
*
|
|
* - <b>Full Hardware Support:</b>
|
|
* LUFA supports the full range of Atmel's USB AVR microcontrollers (see \ref Page_DeviceSupport), with porting between chips being
|
|
* as simple as a single compile switch in many cases. Atmel's stack requires different libraries to be used based on the USB AVR
|
|
* microcontroller series, complicating the process of moving between USB AVR models. In addition, LUFA contains drivers for all the
|
|
* hardware contained on Atmel's USB AVR based boards, so you can get started quickly and easily.
|
|
*
|
|
* - <b>Better Library Support:</b>
|
|
* As many people are now using LUFA, there is a community being built around it. You can get answers to your LUFA related questions
|
|
* quickly by either emailing the library author (subject to author's schedule) or by posting to the official LUFA support mailing list.
|
|
*
|
|
* - <b>More Compact Code:</b>
|
|
* LUFA is written from the ground up to compile optimally, using clean code and good design. Two demos giving the same functionality -
|
|
* the LUFA Low Level API Mouse Demo vs. the Atmel AVR270 HID Mouse application note shows LUFA to be the clear size winner *.
|
|
*
|
|
* * <i>LUFA Low Level Mouse Demo: 3510 bytes, Atmel AVR270 Mouse Application Note: 4222 bytes, using an identical build environment.</i>
|
|
*/
|
|
|