hailey
/
qmk_firmware
mirror of https://github.com/hailey/qmk_firmware.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Split Getting Started page of the documentation into its own section.

Browse Source
Dean Camera 16 years ago
parent 1756087c3e
commit 3bd4011c09
9 changed files with 149 additions and 124 deletions
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Show Stats Download Patch File Download Diff File
  1. 2
      LUFA.pnproj
  2. 36
      LUFA/ManPages/CompilingApps.txt
  3. 74
      LUFA/ManPages/ConfiguringApps.txt
  4. 4
      LUFA/ManPages/DemosBootloadersProjects.txt
  5. 1
      LUFA/ManPages/DevelopingWithLUFA.txt
  6. 123
      LUFA/ManPages/GettingStarted.txt
  7. 2
      LUFA/ManPages/License.txt
  8. 4
      LUFA/ManPages/MainPage.txt
  9. 27
      LUFA/ManPages/ProgrammingApps.txt

2
LUFA.pnproj
View File

File diff suppressed because one or more lines are too long

36
LUFA/ManPages/CompilingApps.txt
Unescape View File

@ -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 <b>"make all"</b> 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 <b>"make clean"</b>. 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.
*/

74
LUFA/ManPages/ConfiguringApps.txt
Unescape View File

@ -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 "<VARIABLE NAME> = <VALUE>". For
* each application, the important variables which should be altered are:
*
* - <b>MCU</b>, the target AVR processor.
* - <b>BOARD</b>, the target board hardware
* - <b>F_CLOCK</b>, the target raw master clock frequency, before any prescaling is performed
* - <b>F_CPU</b>, the target AVR CPU master clock frequency, after any prescaling
* - <b>CDEFS</b>, 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.
*
* <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
* 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.
*
* <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
* 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.
*/

4
LUFA/ManPages/DemosBootloadersProjects.txt
Unescape View File

@ -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 @@
* - <b>Demos</b>
* - <b>Device</b>
* - <b>ClassDriver</b>
* - <b>AudioInput</b> - Audio In (microphone) demo, using the library USB Audio Class driver framework.
* - <b>AudioInput</b> - Audio In (microphone) demo, using the library USB Audio Class driver framework
* - <b>AudioOutput</b> - Audio Out (speaker) demo, using the library USB Audio Class driver framework
* - <b>CDC</b> - Virtual Serial Port demo, using the library USB CDC Class driver framework
* - <b>DualCDC</b> - Dual Virtual Serial Port demo, using the library USB CDC Class driver framework

1
LUFA/ManPages/DevelopingWithLUFA.txt
Unescape View File

@ -11,7 +11,6 @@
* information on compile-time tuning of the library and other developer-related sections.
*
* <b>Subsections:</b>
* - \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

123
LUFA/ManPages/GettingStarted.txt
Unescape View File

@ -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 "<VARIABLE NAME> = <VALUE>". For
* each application, the important variables which should be altered are:
*
* - <b>MCU</b>, the target AVR processor.
* - <b>BOARD</b>, the target board hardware
* - <b>F_CLOCK</b>, the target raw master clock frequency, before any prescaling is performed
* - <b>F_CPU</b>, the target AVR CPU master clock frequency, after any prescaling
* - <b>CDEFS</b>, 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.
*
* <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
* 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.
*
* <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
* 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 <b>"make all"</b> 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 <b>"make clean"</b>. 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".
* <b>Subsections:</b>
* - \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
*/

2
LUFA/ManPages/License.txt
Unescape View File

@ -5,7 +5,7 @@
*/
/**
* \page Page_Licence License
* \page Page_Licence licence
*
* The LUFA library is currently released under the MIT licence, included below.
*

4
LUFA/ManPages/MainPage.txt
Unescape View File

@ -27,9 +27,9 @@
* class) and open source LUFA powered projects.
*
* <b>Subsections:</b>
* - \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
*
*
* <small><i>Logo design by Pavla Dlab</i></small>

27
LUFA/ManPages/ProgrammingApps.txt
Unescape View File

@ -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".
*/
Write Preview
Loading…
Cancel
Save