mac-rom-simm-programmer/hal/at90usb646/LUFA/DoxygenPages/ConfiguringApps.txt
Doug Brown 7425af761a Break out code into a HAL, optimize flash operations
This makes the code pretty easily portable to other architectures if someone
wants to make a more modern SIMM programmer. I also was pretty careful to split
responsibilities of the different components and give the existing components
better names. I'm pretty happy with the organization of the code now.

As part of this change I have also heavily optimized the code. In particular,
the read and write cycle routines are very important to the overall performance
of the programmer. In these routines I had to make some tradeoffs of code
performance versus prettiness, but the overall result is much faster
programming.

Some of these performance changes are the result of what I discovered when
I upgraded my AVR compiler. I discovered that it is smarter at looking at 32-bit
variables when I use a union instead of bitwise operations.

I also shaved off more CPU cycles by carefully making a few small tweaks. I
added a bypass for the "program only some chips" mask, because it was adding
unnecessary CPU cycles for a feature that is rarely used. I removed the
verification feature from the write routine, because we can always verify the
data after the write chunk is complete, which is more efficient. I also added
assumptions about the initial/final state of the CS/OE/WE pins, which allowed me
to remove more valuable CPU cycles from the read/write cycle routines.

There are also a few enormous performance optimizations I should have done a
long time ago:

1) The code was only handling one received byte per main loop iteration. Reading
   every byte available cut nearly a minute off of the 8 MB programming time.
2) The code wasn't taking advantage of the faster programming command available
   in the chips used on the 8 MB SIMM.

The end result of all of these optimizations is I have programming time of the
8 MB SIMM down to 3:31 (it used to be 8:43).

Another minor issue I fixed: the Micron SIMM chip identification wasn't working
properly. It was outputting the manufacturer ID again instead of the device ID.
2020-11-27 00:16:35 -08:00

90 lines
6.7 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_ConfiguringApps Configuring the Demos, Bootloaders and Projects
*
* If the target microcontroller model, architecture, clock speed, board or other settings are different from the current
* settings, they must be changed and the project recompiled from the source code before being programmed into the 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 one or
* more of the source files 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 processor model
* - <b>ARCH</b>, the target microcontroller architecture
* - <b>BOARD</b>, the target board hardware
* - <b>F_CPU</b>, the target CPU master clock frequency, after any prescaling
* - <b>F_USB</b>, the target raw input clock to the USB module of the processor
* - <b>CDEFS</b>, the C preprocessor defines which configure options the source code
* - <b>LUFA_PATH</b>, the path to the LUFA library source code
* - <b>LUFA_OPTS</b>, the compile time LUFA options which configure the library features
*
* These values should be changed to reflect the build hardware.
*
* \section Sec_MCU The MCU Parameter
* This parameter indicates the target microcontroller model for the compiled application. This should be set to the model of the target
* microcontroller (such as the AT90USB1287, or the ATMEGA32U4), in all lower-case (e.g. "at90usb1287"). Note that not all demos support all the
* microcontroller models and architectures, as they may make use of peripherals or modes only present in some devices.
*
* For supported processor models, see \ref Page_DeviceSupport.
*
* \section Sec_ARCH The ARCH Parameter
* This parameter indicates the target microcontroller architecture the library is to be compiled for. Different microcontroller
* architectures require different source files to be compiled into the final binary, and so this option must be set to the correct
* architecture for the selected platform.
*
* For supported processor architectures, see \ref Page_DeviceSupport.
*
* \section Sec_BOARD The BOARD Parameter
* This parameter indicates the target 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 \c /CodeTemplates/DriverStubs/
* 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.
*
* For boards with built in hardware driver support within the LUFA library, see \ref Page_DeviceSupport.
*
* \section Sec_F_CPU The F_CPU Parameter
* This parameter indicates the target microcontroller's main CPU clock frequency, in Hz. This is used by many libraries (and applications) for
* timing related purposes, and should reflect the actual CPU speed after any prescaling or adjustments are performed.
*
* \section Sec_F_USB The F_USB Parameter
* This parameter indicates the raw input clock frequency to the USB module within the microcontroller in Hz. This may be very different on some platforms
* to the main CPU clock or other peripheral/bus clocks.
*
* \section Sec_CDEFS The CDEFS Parameter
* Many applications have features which can be controlled by the defining of specially named preprocessor tokens at the point of compilation - for example,
* an application might use a compile time token to turn on or off optional or mutually exclusive portions of code. Preprocessor tokens can be
* defined here by listing each one with the -D command line switch, and each token can optionally be defined to a specific value. When defined in the
* project makefile, these behave as if they were defined in every source file via a normal preprocessor define statement.
*
* 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.
*
* \section Sec_LUFA_PATH The LUFA_PATH Parameter
* As each LUFA program requires the LUFA library source code to compile correctly, the application must know where the LUFA library is located. This
* value specifies the path to the LUFA library base relative to the path of the project makefile.
*
* \section Sec_LUFA_OPTS The LUFA_OPTS Parameter
* This value is similar to the CDEFS parameter listed elsewhere -- indeed, it is simply a convenient place to group LUFA related tokens away from the
* application's compile time tokens. Normally, these options do not need to be altered to allow an application to compile and run correctly on a
* different board or microcontroller to the current configuration - if the options are incorrect, then the demo is most likely incompatible with the chosen
* microcontroller 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 and other LUFA configuration options can be set here - see \ref Page_TokenSummary documentation for details
* on the available LUFA compile time configuration options.
*/