Delete host mode demos from the root Host demos folder.
[pub/lufa.git] / LUFA / GettingStarted.txt
index 0fe3f50..08fbd1d 100644 (file)
@@ -9,24 +9,27 @@
  *  Out of the box, LUFA contains a large number of pre-made class demos for you to test, experiment with and\r
  *  ultimately build upon for your own projects. All the demos come pre-configured to build and run correctly\r
  *  on the AT90USB1287 AVR microcontroller, mounted on the Atmel USBKEY board and running at an 8MHz master clock.\r
  *  Out of the box, LUFA contains a large number of pre-made class demos for you to test, experiment with and\r
  *  ultimately build upon for your own projects. All the demos come pre-configured to build and run correctly\r
  *  on the AT90USB1287 AVR microcontroller, mounted on the Atmel USBKEY board and running at an 8MHz master clock.\r
- *  This is due to two reasons; one, it is the hardware the author posesses, and two, it is the most popular Atmel\r
+ *  This is due to two reasons; one, it is the hardware the author possesses, and two, it is the most popular Atmel\r
  *  USB demonstration board to date.\r
  *\r
  *  USB demonstration board to date.\r
  *\r
+ *\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
  *  \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
  *  \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.\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
  *\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
+ *  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
  *  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
@@ -34,7 +37,8 @@
  *\r
  *    - <b>MCU</b>, the target AVR processor.\r
  *    - <b>BOARD</b>, the target board hardware\r
  *\r
  *    - <b>MCU</b>, the target AVR processor.\r
  *    - <b>BOARD</b>, the target board hardware\r
- *    - <b>F_CPU</b>, the target AVR master clock frequency\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
  *    - <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
  *  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
  *  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_CPU The F_CPU Parameter\r
- *  This parameter indicates the target AVR's master clock frequency, in Hz. Consult your AVR model's datasheet for allowable clock frequencies\r
- *  if the USB interface is to be operational.\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
  *\r
- *  <b>Note that this value does not actually *alter* the AVR's clock frequency</b>, it is just a way to indicate to the library the clock frequency\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
  *  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 ocurr.\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
  *\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 seperate lines.\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
  *\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
@@ -75,6 +87,7 @@
  *  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
  *  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
  *  \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
@@ -85,7 +98,7 @@
  *\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
  *\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 intermediatary files and all diagnostic output\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
  *  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
  *  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
  *  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
  *  \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