- *\r
- * \section Sec_Prerequisites Prerequisites\r
- * Before you can compile any of the LUFA library code or demos, you will need a recent distribution of avr-libc (1.6.2+)\r
- * and the AVR-GCC (4.2+) compiler. For Windows users, the best way to obtain these is the WinAVR project\r
- * (http://winavr.sourceforge.net) as this provides a single-file setup for everything required to compile your\r
- * own AVR projects.\r
- *\r
- *\r
- * \section Sec_Configuring Configuring the Demos, Bootloaders and Projects\r
- * If the target AVR model, clock speed, board or other settings are different to the current settings, they must be changed\r
- * and the project recompiled from the source code before being programmed into the AVR microcontroller. Most project\r
- * configuration options are located in the "makefile" build script inside each LUFA application's folder, however some\r
- * demo or application-specific configuration settings (such as the output format in the AudioOut demo) are located in the\r
- * main .c source file of the project. See each project's individual documentation for application-specific configuration\r
- * values.\r
- *\r
- * Each project "makefile" contains all the script and configuration data required to compile each project. When opened with\r
- * any regular basic text editor such as Notepad or WordPad (ensure that the save format is a pure ASCII text format) the\r
- * build configuration settings may be altered.\r
- *\r
- * Inside each makefile, a number of configuration variables are located, with the format "<VARIABLE NAME> = <VALUE>". For\r
- * each application, the important variables which should be altered are:\r
- *\r
- * - <b>MCU</b>, the target AVR processor.\r
- * - <b>BOARD</b>, the target board hardware\r
- * - <b>F_CLOCK</b>, the target raw master clock frequency, before any prescaling is performed\r
- * - <b>F_CPU</b>, the target AVR CPU master clock frequency, after any prescaling\r
- * - <b>CDEFS</b>, the C preprocessor defines which configure the source code\r
- *\r
- * These values should be changed to reflect the build hardware.\r
- *\r
- * \subsection SSec_MCU The MCU Parameter\r
- * This parameter indicates the target AVR model for the compiled application. This should be set to the model of the target AVR\r
- * (such as the AT90USB1287, or the ATMEGA32U4), in all lower-case (e.g. "at90usb1287"). Note that not all demos support all the\r
- * USB AVR models, as they may make use of peripherals or modes only present in some devices.\r
- *\r
- * For supported library AVR models, see main documentation page.\r
- *\r
- * \subsection SSec_BOARD The BOARD Parameter\r
- * This parameter indicates the target AVR board hardware for the compiled application. Some LUFA library drivers are board-specific,\r
- * such as the LED driver, and the library needs to know the layout of the target board. If you are using one of the board models listed\r
- * on the main library page, change this parameter to the board name in all UPPER-case.\r
- *\r
- * If you are not using any board-specific drivers in the LUFA library, or you are using a custom board layout, change this to read\r
- * "USER" (no quotes) instead of a standard board name. If the USER board type is selected and the application makes use of one or more\r
- * board-specific hardware drivers inside the LUFA library, then the appropriate stub drives files should be copied from the /BoardStubs/\r
- * directory into a /Board/ folder inside the application directory, and the stub driver completed with the appropriate code to drive the\r
- * custom board's hardware.\r
- *\r
- * \subsection SSec_F_CLOCK The F_CLOCK Parameter\r
- * This parameter indicates the target AVR's input clock frequency, in Hz. This is the actual clock input, before any prescaling is performed. In the\r
- * USB AVR architecture, the input clock before any prescaling is fed directly to the PLL subsystem, and thus the PLL is derived directly from the\r
- * clock input. The PLL then feeds the USB and other sections of the AVR with the correct upscaled frequencies required for those sections to function.\r
- *\r
- * <b>Note that this value does not actually *alter* the AVR's input clock frequency</b>, it is just a way to indicate to the library the clock frequency\r
- * of the AVR as set by the AVR's fuses. If this value does not reflect the actual running frequency of the AVR, incorrect operation of one of more\r
- * library components will occur.\r
- *\r
- * \subsection SSec_F_CPU The F_CPU Parameter\r
- * This parameter indicates the target AVR's master CPU clock frequency, in Hz.\r
- *\r
- * <b>Note that this value does not actually *alter* the AVR's CPU clock frequency</b>, it is just a way to indicate to the library the clock frequency\r
- * of the AVR core as set by the AVR's fuses. If this value does not reflect the actual running frequency of the AVR, incorrect operation of one of more\r
- * library components will occur.\r
- *\r
- * \subsection SSec_CDEFS The CDEFS Parameter\r
- * Most applications will actually have multiple CDEF lines, which are concatenated together with the "+=" operator. This ensures that large\r
- * numbers of configuration options remain readable by splitting up groups of options into separate lines.\r
- *\r
- * Normally, these options do not need to be altered to allow an application to compile and run correctly on a different board or AVR to the\r
- * current configuration - if the options are incorrect, then the demo is most likely incompatible with the chosen USB AVR model and cannot be\r
- * made to function through the altering of the makefile settings alone (or at all). Settings such as the USB mode (device, host or both), the USB\r
- * interface speed (Low or Full speed) and other LUFA configuration options can be set here - refer to the library documentation for details on the\r
- * configuration parameters.\r
- *\r
- *\r
- * \section Sec_Compiling Compiling a LUFA Application\r
- * Compiling the LUFA demos, applications and/or bootloaders is very simple. LUFA comes with makefile scripts for\r
- * each individual demo, bootloader and project folder, as well as scripts in the /Demos/, /Bootloaders/, /Projects/\r
- * and the LUFA root directory. This means that compilation can be started from any of the above directories, with\r
- * a build started from an upper directory in the directory structure executing build of all child directories under it.\r
- * This means that while a build inside a particular demo directory will build only that particular demo, a build stated\r
- * from the /Demos/ directory will build all LUFA demo projects sequentially.\r
- *\r
- * \subsection SSec_CommandLine Via the Command Line\r
- * To build a project from the source via the command line, the command <b>"make all"</b> should be executed from the command line in the directory\r
- * of interest. To remove compiled files (including the binary output, all intermediately files and all diagnostic output\r
- * files), execute <b>"make clean"</b>. Once a "make all" has been run and no errors were encountered, the resulting binary will\r
- * be located in the generated ".HEX" file. If your project makes use of pre-initialized EEPROM variables, the generated ".EEP"\r
- * file will contain the project's EEPROM data.\r
- *\r
- * \subsection SSec_AVRStudio Via AVRStudio\r
- * Each demo, project and bootloader contains an AVRStudio project (.aps) which can be used to build each project. Once opened\r
- * in AVRStudio, the project can be built and cleaned using the GUI buttons or menus. Note that the AVRStudio project files make\r
- * use of the external project makefile, thus the procedure for configuring a demo remains the same regardless of the build environment.\r
- *\r
- *\r
- * \section Sec_Programming Programming a USB AVR\r
- * Once you have built an application, you will need a way to program in the resulting ".HEX" file (and, if your\r
- * application uses EEPROM variables with initial values, also a ".EEP" file) into your USB AVR. Normally, the\r
- * reprogramming an AVR device must be performed using a special piece of programming hardware, through one of the\r
- * supported AVR programming protocols - ISP, HVSP, HVPP, JTAG or dW. This can be done through a custom programmer,\r
- * a third party programmer, or an official Atmel AVR tool - for more information, see the Atmel.com website.\r
- *\r
- * Alternatively, you can use the bootloader. From the Atmel factory, each USB AVR comes preloaded with the Atmel\r
- * DFU (Device Firmware Update) class bootloader, a small piece of AVR firmware which allows the remainder of the\r
- * AVR to be programmed through a non-standard interface such as the serial USART port, SPI, or (in this case) USB.\r
- * Bootloaders have the advantage of not requiring any special hardware for programming, and cannot usually be erased\r
- * or broken without an external programming device. They have disadvantages however; they cannot change the fuses of\r
- * the AVR (special configuration settings that control the operation of the chip itself) and a small portion of the\r
- * AVR's FLASH program memory must be reserved to contain the bootloader firmware, and thus cannot be used by the\r
- * loaded application. Atmel's DFU bootloader is either 4KB (for the smaller USB AVRs) or 8KB (for the larger USB AVRs).\r
- *\r
- * If you wish to use the DFU bootloader to program in your application, refer to your DFU programmer's documentation.\r
- * Atmel provides a free utility called FLIP which is USB AVR compatible, and an open source (Linux compatible)\r
- * alternative exists called "dfu-programmer".\r
projects / pub / USBasp.git / commitdiff