Commit Graph

13 Commits

Author SHA1 Message Date
Doug Brown 7e5639c792 Exclude M258KE code from Eclipse AVR builds 2023-09-10 05:02:44 -07:00
Doug Brown baf0937589 Switch to config header for LUFA
This eliminates the need for a bunch of extra defines added to the
compile command.
2023-06-25 11:38:41 -07:00
Doug Brown b627ef9020 Move descriptors to RAM
This ensures they will work properly on the AT90USB128x, especially in
the bootloader where they will be in the upper 64 KB.
2023-05-28 19:34:02 -07:00
Doug Brown 3a8e006925 Manually control USB PLL
The 646 and 1286 have different required USB PLL values when you have a
16 MHz crystal. Detect the chip at runtime to set up the PLL correctly.
This requires taking over control of the PLL from LUFA.
2023-05-28 19:34:02 -07:00
Doug Brown 8aec8807c9 Fix line endings
A whole bunch of files in this project had DOS line endings. This is due
to how I started working on it on a Windows machine with little Git
experience. Now it's inconsistent so I'm fixing it.
2023-05-28 19:34:02 -07:00
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
Doug Brown 927c178671 Ignore local settings files. Get project compiling on my computer. 2020-11-27 00:16:35 -08:00
Doug Brown 522ded0973 Added .bin file generation for firmware upload 2012-03-04 17:28:15 -08:00
Doug Brown f45cc2c4d6 Started writing more command handling 2011-12-11 08:35:53 -08:00
Doug Brown 8865d0c00f I got the device identification working, and I'm in the middle of breaking it into its own set of functions for write cycles, read cycles, unlock sequence, etc. 2011-12-10 18:40:30 -08:00
Doug Brown 1db6834da4 Added LUFA into the project, right now just for some demo stuff. 2011-12-09 22:11:31 -08:00
Doug Brown 1595c69890 OK -- so I separated the actual port code from the external memory controller code. I think this makes more sense.
It does add some complexity to the code. I may be going through a chain of calls just to turn the CS pin on, for instance. Hopefully I'm not going too crazy with this.

Anyway, this means that I can control the ports from a SIMM electrical test routine using the same types of functions that the actual programming  controlling code would use, without having to duplicate a bunch of port definitions and bit manipulation. I made sure to add all the functions I can think of needing to the ports module. We'll see if I got them all!
2011-11-27 00:01:29 -08:00
Doug Brown 407f6831a9 Initial import of my test code for the SIMM programmer board. Right now
it contains an (untested) MCP23S17 driver complete with AVR SPI support,
and an (untested) external memory interface driver that uses it.
2011-11-25 23:10:30 -08:00