diff --git a/LUFA.pnproj b/LUFA.pnproj index 9cb0de0579..7db78da2c0 100644 --- a/LUFA.pnproj +++ b/LUFA.pnproj @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/LUFA/ManPages/CompilingApps.txt b/LUFA/ManPages/CompilingApps.txt new file mode 100644 index 0000000000..b1d5ed6ed2 --- /dev/null +++ b/LUFA/ManPages/CompilingApps.txt @@ -0,0 +1,36 @@ +/** \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_CompilingApps Compiling the Demos, Bootloaders and Projects + * + * The following details how to compile the included LUFA demos, applications and bootloaders using AVR-GCC. + * + * \section Sec_Prerequisites Prerequisites + * Before you can compile any of the LUFA library code or demos, you will need a recent distribution of avr-libc (1.6.2+) + * and the AVR-GCC (4.2+) compiler. For Windows users, the best way to obtain these is the WinAVR project + * (http://winavr.sourceforge.net) as this provides a single-file setup for everything required to compile your + * own AVR projects. + * + * \section Sec_Compiling Compiling a LUFA Application + * Compiling the LUFA demos, applications and/or bootloaders is very simple. LUFA comes with makefile scripts for + * each individual demo, bootloader and project folder, as well as scripts in the /Demos/, /Bootloaders/, /Projects/ + * and the LUFA root directory. This means that compilation can be started from any of the above directories, with + * a build started from an upper directory in the directory structure executing build of all child directories under it. + * This means that while a build inside a particular demo directory will build only that particular demo, a build stated + * from the /Demos/ directory will build all LUFA demo projects sequentially. + * + * \subsection SSec_CommandLine Via the Command Line + * To build a project from the source via the command line, the command "make all" should be executed from the command line in the directory + * of interest. To remove compiled files (including the binary output, all intermediately files and all diagnostic output + * files), execute "make clean". Once a "make all" has been run and no errors were encountered, the resulting binary will + * be located in the generated ".HEX" file. If your project makes use of pre-initialized EEPROM variables, the generated ".EEP" + * file will contain the project's EEPROM data. + * + * \subsection SSec_AVRStudio Via AVRStudio + * Each demo, project and bootloader contains an AVRStudio project (.aps) which can be used to build each project. Once opened + * in AVRStudio, the project can be built and cleaned using the GUI buttons or menus. Note that the AVRStudio project files make + * use of the external project makefile, thus the procedure for configuring a demo remains the same regardless of the build environment. + */ \ No newline at end of file diff --git a/LUFA/ManPages/ConfiguringApps.txt b/LUFA/ManPages/ConfiguringApps.txt new file mode 100644 index 0000000000..bb6d185e42 --- /dev/null +++ b/LUFA/ManPages/ConfiguringApps.txt @@ -0,0 +1,74 @@ +/** \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_ConfiguringApps Configuring the Demos, Bootloaders and Projects + * + * If the target AVR model, clock speed, board or other settings are different to the current settings, they must be changed + * and the project recompiled from the source code before being programmed into the AVR microcontroller. Most project + * configuration options are located in the "makefile" build script inside each LUFA application's folder, however some + * demo or application-specific configuration settings (such as the output format in the AudioOut demo) are located in the + * main .c source file of the project. See each project's individual documentation for application-specific configuration + * values. + * + * Each project "makefile" contains all the script and configuration data required to compile each project. When opened with + * any regular basic text editor such as Notepad or WordPad (ensure that the save format is a pure ASCII text format) the + * build configuration settings may be altered. + * + * Inside each makefile, a number of configuration variables are located, with the format " = ". For + * each application, the important variables which should be altered are: + * + * - MCU, the target AVR processor. + * - BOARD, the target board hardware + * - F_CLOCK, the target raw master clock frequency, before any prescaling is performed + * - F_CPU, the target AVR CPU master clock frequency, after any prescaling + * - CDEFS, the C preprocessor defines which configure the source code + * + * These values should be changed to reflect the build hardware. + * + * \section Sec_MCU The MCU Parameter + * This parameter indicates the target AVR model for the compiled application. This should be set to the model of the target AVR + * (such as the AT90USB1287, or the ATMEGA32U4), in all lower-case (e.g. "at90usb1287"). Note that not all demos support all the + * USB AVR models, as they may make use of peripherals or modes only present in some devices. + * + * For supported library AVR models, see main documentation page. + * + * \section Sec_BOARD The BOARD Parameter + * This parameter indicates the target AVR board hardware for the compiled application. Some LUFA library drivers are board-specific, + * 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 + * on the main library page, change this parameter to the board name in all UPPER-case. + * + * 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 + * "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 + * board-specific hardware drivers inside the LUFA library, then the appropriate stub drives files should be copied from the /BoardStubs/ + * directory into a /Board/ folder inside the application directory, and the stub driver completed with the appropriate code to drive the + * custom board's hardware. + * + * \section Sec_F_CLOCK The F_CLOCK Parameter + * 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 + * 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 + * 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. + * + * Note that this value does not actually *alter* the AVR's input clock frequency, it is just a way to indicate to the library the clock frequency + * 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 + * library components will occur. + * + * \section Sec_F_CPU The F_CPU Parameter + * This parameter indicates the target AVR's master CPU clock frequency, in Hz. + * + * Note that this value does not actually *alter* the AVR's CPU clock frequency, it is just a way to indicate to the library the clock frequency + * 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 + * library components will occur. + * + * \section Sec_CDEFS The CDEFS Parameter + * Most applications will actually have multiple CDEF lines, which are concatenated together with the "+=" operator. This ensures that large + * numbers of configuration options remain readable by splitting up groups of options into separate lines. + * + * 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 + * current configuration - if the options are incorrect, then the demo is most likely incompatible with the chosen USB AVR model and cannot be + * 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 + * interface speed (Low or Full speed) and other LUFA configuration options can be set here - refer to the library documentation for details on the + * configuration parameters. + */ \ No newline at end of file diff --git a/LUFA/ManPages/DemosBootloadersProjects.txt b/LUFA/ManPages/DemosBootloadersProjects.txt index c886513617..3a6fecc1d1 100644 --- a/LUFA/ManPages/DemosBootloadersProjects.txt +++ b/LUFA/ManPages/DemosBootloadersProjects.txt @@ -4,7 +4,7 @@ * documentation pages. It is not a project source file. */ -/** \page Page_Apps Library Demos, Projects and Bootloaders +/** \page Page_LibraryApps Included Library Applications * * The LUFA library ships with several different host and device demos, located in the /Demos/ subdirectory. * If this directory is missing, please re-download the project from the project homepage. Within this directory the demos @@ -27,7 +27,7 @@ * - Demos * - Device * - ClassDriver - * - AudioInput - Audio In (microphone) demo, using the library USB Audio Class driver framework. + * - AudioInput - Audio In (microphone) demo, using the library USB Audio Class driver framework * - AudioOutput - Audio Out (speaker) demo, using the library USB Audio Class driver framework * - CDC - Virtual Serial Port demo, using the library USB CDC Class driver framework * - DualCDC - Dual Virtual Serial Port demo, using the library USB CDC Class driver framework diff --git a/LUFA/ManPages/DevelopingWithLUFA.txt b/LUFA/ManPages/DevelopingWithLUFA.txt index 5e44996642..b6abe3a7f3 100644 --- a/LUFA/ManPages/DevelopingWithLUFA.txt +++ b/LUFA/ManPages/DevelopingWithLUFA.txt @@ -11,7 +11,6 @@ * information on compile-time tuning of the library and other developer-related sections. * * Subsections: - * - \subpage Page_GettingStarted Getting Started * - \subpage Page_TokenSummary Summary of Compile Time Tokens * - \subpage Page_Migration Migrating from an Older LUFA Version * - \subpage Page_VIDPID Allocated USB VID and PID Values diff --git a/LUFA/ManPages/GettingStarted.txt b/LUFA/ManPages/GettingStarted.txt index 08fbd1dfdf..dfd38ed5f6 100644 --- a/LUFA/ManPages/GettingStarted.txt +++ b/LUFA/ManPages/GettingStarted.txt @@ -10,122 +10,11 @@ * ultimately build upon for your own projects. All the demos come pre-configured to build and run correctly * on the AT90USB1287 AVR microcontroller, mounted on the Atmel USBKEY board and running at an 8MHz master clock. * This is due to two reasons; one, it is the hardware the author possesses, and two, it is the most popular Atmel - * USB demonstration board to date. + * USB demonstration board to date. To learn how to reconfigure, recompile and program the included LUFA applications + * using different settings, see the following subsections. * - * - * \section Sec_Prerequisites Prerequisites - * Before you can compile any of the LUFA library code or demos, you will need a recent distribution of avr-libc (1.6.2+) - * and the AVR-GCC (4.2+) compiler. For Windows users, the best way to obtain these is the WinAVR project - * (http://winavr.sourceforge.net) as this provides a single-file setup for everything required to compile your - * own AVR projects. - * - * - * \section Sec_Configuring Configuring the Demos, Bootloaders and Projects - * If the target AVR model, clock speed, board or other settings are different to the current settings, they must be changed - * and the project recompiled from the source code before being programmed into the AVR microcontroller. Most project - * configuration options are located in the "makefile" build script inside each LUFA application's folder, however some - * demo or application-specific configuration settings (such as the output format in the AudioOut demo) are located in the - * main .c source file of the project. See each project's individual documentation for application-specific configuration - * values. - * - * Each project "makefile" contains all the script and configuration data required to compile each project. When opened with - * any regular basic text editor such as Notepad or WordPad (ensure that the save format is a pure ASCII text format) the - * build configuration settings may be altered. - * - * Inside each makefile, a number of configuration variables are located, with the format " = ". For - * each application, the important variables which should be altered are: - * - * - MCU, the target AVR processor. - * - BOARD, the target board hardware - * - F_CLOCK, the target raw master clock frequency, before any prescaling is performed - * - F_CPU, the target AVR CPU master clock frequency, after any prescaling - * - CDEFS, the C preprocessor defines which configure the source code - * - * These values should be changed to reflect the build hardware. - * - * \subsection SSec_MCU The MCU Parameter - * This parameter indicates the target AVR model for the compiled application. This should be set to the model of the target AVR - * (such as the AT90USB1287, or the ATMEGA32U4), in all lower-case (e.g. "at90usb1287"). Note that not all demos support all the - * USB AVR models, as they may make use of peripherals or modes only present in some devices. - * - * For supported library AVR models, see main documentation page. - * - * \subsection SSec_BOARD The BOARD Parameter - * This parameter indicates the target AVR board hardware for the compiled application. Some LUFA library drivers are board-specific, - * 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 - * on the main library page, change this parameter to the board name in all UPPER-case. - * - * 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 - * "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 - * board-specific hardware drivers inside the LUFA library, then the appropriate stub drives files should be copied from the /BoardStubs/ - * directory into a /Board/ folder inside the application directory, and the stub driver completed with the appropriate code to drive the - * custom board's hardware. - * - * \subsection SSec_F_CLOCK The F_CLOCK Parameter - * 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 - * 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 - * 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. - * - * Note that this value does not actually *alter* the AVR's input clock frequency, it is just a way to indicate to the library the clock frequency - * 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 - * library components will occur. - * - * \subsection SSec_F_CPU The F_CPU Parameter - * This parameter indicates the target AVR's master CPU clock frequency, in Hz. - * - * Note that this value does not actually *alter* the AVR's CPU clock frequency, it is just a way to indicate to the library the clock frequency - * 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 - * library components will occur. - * - * \subsection SSec_CDEFS The CDEFS Parameter - * Most applications will actually have multiple CDEF lines, which are concatenated together with the "+=" operator. This ensures that large - * numbers of configuration options remain readable by splitting up groups of options into separate lines. - * - * 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 - * current configuration - if the options are incorrect, then the demo is most likely incompatible with the chosen USB AVR model and cannot be - * 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 - * interface speed (Low or Full speed) and other LUFA configuration options can be set here - refer to the library documentation for details on the - * configuration parameters. - * - * - * \section Sec_Compiling Compiling a LUFA Application - * Compiling the LUFA demos, applications and/or bootloaders is very simple. LUFA comes with makefile scripts for - * each individual demo, bootloader and project folder, as well as scripts in the /Demos/, /Bootloaders/, /Projects/ - * and the LUFA root directory. This means that compilation can be started from any of the above directories, with - * a build started from an upper directory in the directory structure executing build of all child directories under it. - * This means that while a build inside a particular demo directory will build only that particular demo, a build stated - * from the /Demos/ directory will build all LUFA demo projects sequentially. - * - * \subsection SSec_CommandLine Via the Command Line - * To build a project from the source via the command line, the command "make all" should be executed from the command line in the directory - * of interest. To remove compiled files (including the binary output, all intermediately files and all diagnostic output - * files), execute "make clean". Once a "make all" has been run and no errors were encountered, the resulting binary will - * be located in the generated ".HEX" file. If your project makes use of pre-initialized EEPROM variables, the generated ".EEP" - * file will contain the project's EEPROM data. - * - * \subsection SSec_AVRStudio Via AVRStudio - * Each demo, project and bootloader contains an AVRStudio project (.aps) which can be used to build each project. Once opened - * in AVRStudio, the project can be built and cleaned using the GUI buttons or menus. Note that the AVRStudio project files make - * use of the external project makefile, thus the procedure for configuring a demo remains the same regardless of the build environment. - * - * - * \section Sec_Programming Programming a USB AVR - * Once you have built an application, you will need a way to program in the resulting ".HEX" file (and, if your - * application uses EEPROM variables with initial values, also a ".EEP" file) into your USB AVR. Normally, the - * reprogramming an AVR device must be performed using a special piece of programming hardware, through one of the - * supported AVR programming protocols - ISP, HVSP, HVPP, JTAG or dW. This can be done through a custom programmer, - * a third party programmer, or an official Atmel AVR tool - for more information, see the Atmel.com website. - * - * Alternatively, you can use the bootloader. From the Atmel factory, each USB AVR comes preloaded with the Atmel - * DFU (Device Firmware Update) class bootloader, a small piece of AVR firmware which allows the remainder of the - * AVR to be programmed through a non-standard interface such as the serial USART port, SPI, or (in this case) USB. - * Bootloaders have the advantage of not requiring any special hardware for programming, and cannot usually be erased - * or broken without an external programming device. They have disadvantages however; they cannot change the fuses of - * the AVR (special configuration settings that control the operation of the chip itself) and a small portion of the - * AVR's FLASH program memory must be reserved to contain the bootloader firmware, and thus cannot be used by the - * loaded application. Atmel's DFU bootloader is either 4KB (for the smaller USB AVRs) or 8KB (for the larger USB AVRs). - * - * If you wish to use the DFU bootloader to program in your application, refer to your DFU programmer's documentation. - * Atmel provides a free utility called FLIP which is USB AVR compatible, and an open source (Linux compatible) - * alternative exists called "dfu-programmer". + * Subsections: + * - \subpage Page_ConfiguringApps How to Configure the Included Demos, Projects and Bootloaders + * - \subpage Page_CompilingApps How to Compile the Included Demos, Projects and Bootloaders + * - \subpage Page_ProgrammingApps How to Program an AVR with the Included Demos, Projects and Bootloaders */ diff --git a/LUFA/ManPages/License.txt b/LUFA/ManPages/License.txt index 293c18bdbe..120e937ae6 100644 --- a/LUFA/ManPages/License.txt +++ b/LUFA/ManPages/License.txt @@ -5,7 +5,7 @@ */ /** - * \page Page_Licence License + * \page Page_Licence licence * * The LUFA library is currently released under the MIT licence, included below. * diff --git a/LUFA/ManPages/MainPage.txt b/LUFA/ManPages/MainPage.txt index 75f677b979..6a5057c746 100644 --- a/LUFA/ManPages/MainPage.txt +++ b/LUFA/ManPages/MainPage.txt @@ -27,9 +27,9 @@ * class) and open source LUFA powered projects. * * Subsections: - * - \subpage Page_Licence Project License + * - \subpage Page_Licence Project licence * - \subpage Page_Donating Donating to Support this Project - * - \subpage Page_Apps Project Demos, Bootloaders and Projects + * - \subpage Page_LibraryApps Overview of included Demos, Bootloaders and Projects * * * Logo design by Pavla Dlab diff --git a/LUFA/ManPages/ProgrammingApps.txt b/LUFA/ManPages/ProgrammingApps.txt new file mode 100644 index 0000000000..1e3be715a4 --- /dev/null +++ b/LUFA/ManPages/ProgrammingApps.txt @@ -0,0 +1,27 @@ +/** \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_ProgrammingApps Programming an Application into a USB AVR + * + * Once you have built an application, you will need a way to program in the resulting ".HEX" file (and, if your + * application uses EEPROM variables with initial values, also a ".EEP" file) into your USB AVR. Normally, the + * reprogramming an AVR device must be performed using a special piece of programming hardware, through one of the + * supported AVR programming protocols - ISP, HVSP, HVPP, JTAG or dW. This can be done through a custom programmer, + * a third party programmer, or an official Atmel AVR tool - for more information, see the Atmel.com website. + * + * Alternatively, you can use the bootloader. From the Atmel factory, each USB AVR comes preloaded with the Atmel + * DFU (Device Firmware Update) class bootloader, a small piece of AVR firmware which allows the remainder of the + * AVR to be programmed through a non-standard interface such as the serial USART port, SPI, or (in this case) USB. + * Bootloaders have the advantage of not requiring any special hardware for programming, and cannot usually be erased + * or broken without an external programming device. They have disadvantages however; they cannot change the fuses of + * the AVR (special configuration settings that control the operation of the chip itself) and a small portion of the + * AVR's FLASH program memory must be reserved to contain the bootloader firmware, and thus cannot be used by the + * loaded application. Atmel's DFU bootloader is either 4KB (for the smaller USB AVRs) or 8KB (for the larger USB AVRs). + * + * If you wish to use the DFU bootloader to program in your application, refer to your DFU programmer's documentation. + * Atmel provides a free utility called FLIP which is USB AVR compatible, and an open source (Linux compatible) + * alternative exists called "dfu-programmer". + */ \ No newline at end of file