mirror of
https://github.com/dougg3/mac-rom-simm-programmer.git
synced 2024-12-11 07:50:36 +00:00
7425af761a
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.
31 lines
2.1 KiB
Plaintext
31 lines
2.1 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_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
|
|
* (<a>http://winavr.sourceforge.net</a>) 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.
|
|
*
|
|
* 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.
|
|
*/
|