mirror of
https://github.com/dougg3/mac-rom-simm-programmer.git
synced 2024-12-01 04:49:22 +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.
44 lines
2.6 KiB
Plaintext
44 lines
2.6 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_WhyUseLUFA Why Use LUFA?
|
|
*
|
|
* The LUFA Library has many advantages over implementing the code required to drive the USB AVRs directly.
|
|
* It is much more preferable to incorporate LUFA into your existing projects - or even make a new project
|
|
* using LUFA - than it is to start from scratch and use the USB AVR registers directly. Some of these reasons
|
|
* are:
|
|
*
|
|
* - <b>Portability:</b>
|
|
* The LUFA stack is designed to run (at some capacity) on the entire Atmel range of USB AVRs, regardless of the
|
|
* exact USB controller revision used. If you decide to implement your own USB stack, you will either need to
|
|
* code around the differences between each USB AVR controller's implementation between different chip models, or
|
|
* require your code to run on only one specific USB AVR model series.
|
|
*
|
|
* - <b>Speed of Development:</b>
|
|
* LUFA ships with a wide range of pre-made demos, bootloaders and projects for you to try, learn and extend. Each
|
|
* of these demos are tested (where possible) across as many USB AVRs and Operating Systems as possible, to ensure
|
|
* that they work under as many conditions as possible. In addition, there are inbuilt class drivers for several of
|
|
* the USB classes which you can make use of in your projects with minimal effort.
|
|
*
|
|
* - <b>Maintainability:</b>
|
|
* As LUFA takes care of much of the USB implementation, you can be left to focusing on your actual project's
|
|
* functionality, rather than being held back developing and debugging the USB stack code. Since LUFA uses clear APIs
|
|
* for USB development, your code will be more readable than if it had the low level USB stack code integrated into
|
|
* it directly. Updating the LUFA library is a simple folder-replacement and gives new features and bug fixes in
|
|
* seconds each time a new release is made.
|
|
*
|
|
* - <b>Size:</b>
|
|
* Not just requiring less code to make complex USB devices, LUFA is written to compile down as much as possible into
|
|
* optimal code, to occupy only a small space for its feature set.
|
|
*
|
|
* - <b>Support:</b>
|
|
* Since many people are now using LUFA in their own projects, you can take advantage of other's knowledge when you run
|
|
* into difficulties or need some advice. In addition, you can also email the library author to receive personalized
|
|
* support when you need it (subject to author's schedule).
|
|
*/
|
|
|