mirror of
https://github.com/dougg3/mac-rom-simm-programmer.git
synced 2024-12-01 19:50:18 +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.
53 lines
3.7 KiB
Plaintext
53 lines
3.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_LUFAvsAtmelStack LUFA vs the Atmel 8-bit USB AVR Stack
|
|
*
|
|
* Atmel offers an official 8-bit USB AVR stack, which may be incorporated into user projects and products. As LUFA and the Atmel
|
|
* stack aims to give roughly the same functionality to a design, it is often asked what advantages LUFA carries over the official
|
|
* Atmel USB stack for the 8-bit USB AVRs. Below are just some of the advantages to choosing LUFA over the official Atmel stack.
|
|
*
|
|
* - <b>Licensing:</b>
|
|
* LUFA is released under a very permissive MIT license (see \ref Page_LicenseInfo), while the Atmel stack carries several
|
|
* restrictions as to how and where it can be used. LUFA's licensing should be suitable for both Commercial and Non-Commercial
|
|
* entities alike.
|
|
*
|
|
* - <b>Demos and Projects:</b>
|
|
* Unlike the Atmel stack, LUFA comes with many different Device and Host mode Demos and Projects ready to run out of the box.
|
|
* Atmel favors separate downloads for each of their (small set) of USB AVR demos, which requires more time and offers less
|
|
* to the end-user. LUFA also contains several open source Bootloaders, which can be modified as the user wishes to suit his or
|
|
* her application, instead of being forced to use Atmel's single prebuilt (closed-source) DFU bootloader.
|
|
*
|
|
* - <b>Central Library Code:</b>
|
|
* LUFA is designed to allow the central library core code to be shared amongst several projects, so long as the compiled object
|
|
* files are cleaned between different projects. This is in direct contrast to the Atmel library, which is strongly coupled to the
|
|
* project it is integrated with. Using LUFA allows for only one copy of the library core to be needed for all applications, and
|
|
* makes updating the library used in all projects a trivial copy-and-paste process.
|
|
*
|
|
* - <b>Clean API:</b>
|
|
* One of the main design goals of LUFA is to make the API easy to use. While LUFA is a fluid project which has undergone many
|
|
* API improvements, the API is arguably much nicer to use and easier to understand than the equivalent Atmel stack code. LUFA's
|
|
* API is also more complete than the Atmel stack, and contains many features to speed up application development.
|
|
*
|
|
* - <b>Full Hardware Support:</b>
|
|
* LUFA supports the full range of Atmel's USB AVR microcontrollers (see \ref Page_DeviceSupport), with porting between chips being
|
|
* as simple as a single compile switch in many cases. Atmel's stack requires different libraries to be used based on the USB AVR
|
|
* microcontroller series, complicating the process of moving between USB AVR models. In addition, LUFA contains drivers for all the
|
|
* hardware contained on Atmel's USB AVR based boards, so you can get started quickly and easily.
|
|
*
|
|
* - <b>Better Library Support:</b>
|
|
* As many people are now using LUFA, there is a community being built around it. You can get answers to your LUFA related questions
|
|
* quickly by either emailing the library author (subject to author's schedule) or by posting to the official LUFA support mailing list.
|
|
*
|
|
* - <b>More Compact Code:</b>
|
|
* LUFA is written from the ground up to compile optimally, using clean code and good design. Two demos giving the same functionality -
|
|
* the LUFA Low Level API Mouse Demo vs. the Atmel AVR270 HID Mouse application note shows LUFA to be the clear size winner *.
|
|
*
|
|
* * <i>LUFA Low Level Mouse Demo: 3510 bytes, Atmel AVR270 Mouse Application Note: 4222 bytes, using an identical build environment.</i>
|
|
*/
|
|
|