Commit Graph

16 Commits

Author SHA1 Message Date
Doug Brown
82df6ea459 Fix a few minor issues
I noticed that after I implemented the SPI optimization of cycle
counting instead of polling on SPIF, the first "normal" SPI transaction
I tried would fail. This is because nothing was clearing the SPIF flag
anymore, and the normal SPI driver still looks at it. So it was thinking
that the latest transaction was already completed (it wasn't). Worked
around this by making sure we clear the flag in SPI_Assert. I'm not
concerned about performance impact here because the actual clean SPI
driver is not used in performance-bound situations.

Fixed an issue that identified the wrong pins as shorted to ground in
the electrical test functionality. Whoops!
2020-11-27 00:16:35 -08:00
Doug Brown
3df4c40f38 Add/update copyright
This just makes sure everything is up to date with copyrights.
2020-11-27 00:16:35 -08: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
145487d388 Added GPL header to all of my source files. 2012-05-25 20:21:04 -07:00
Doug Brown
c681547026 Fixed bug that screwed up reading after doing an electrical test. 2012-03-04 12:03:02 -08:00
Doug Brown
e38269f879 Optimized the SIMM electrical test, fixed a few small bugs I had introduced in the previous commit. Added comments where necessary. Seems to work great now. 2011-12-18 14:55:08 -08:00
Doug Brown
a1ca591d60 The same short is never repeated twice with the same 2 pins now. However -- if there's a short between 1, 2, and 3 -- it will still show a short between 1 and 2, 1 and 3, and 2 and 3, even though that info is somewhat redundant. But the host software can iron all that out. 2011-12-18 14:18:49 -08:00
Doug Brown
9333b65cde Fixed a tiny mistake -- forgot to say the name of one of my enums after the typedef.
Finished making the electrical test work -- I had failed to realize that I have to ignore the ground shorts once they have been found -- otherwise they reappear against EVERY tested pin (because they are always low and I'm testing for low pins -- duh!). Anyway, it was showing way too many shorts, and that's why. Now I independently can find shorts between separate pins without getting flooded with the ground shorts too. Only thing that's missing is the VCC shorts, but I can't do that without pullups (to my knowledge)
2011-12-18 12:00:22 -08:00
Doug Brown
beae025d1a Oops, I was counting too many errors 2011-12-18 10:19:57 -08:00
Doug Brown
9054aaff0f Started implementing electrical test that tells what pins are shorted to what 2011-12-18 10:18:30 -08:00
Doug Brown
b475c28040 Fixed a bug in the address line tests, updated fusebits for now [with no bootloader yet], started working on getting all the tests working 2011-12-07 21:17:47 -08:00
Doug Brown
bfeadc7e3a I had forgotten to check the control lines for ground shorts. 2011-12-04 17:09:57 -08:00
Doug Brown
65c6654660 Added delay "adapter" class to keep simm_electrical_test.c completely platform-independent.
Updated the electrical class to wait after setting up pins before reading them.
2011-12-04 16:30:26 -08:00
Doug Brown
fc44d70c4f Finished writing the electrical test routine, and fixed a mistake in how I named a few functions in ports.c.
I'm not completely done with the electrical test because it only counts errors right now. So I need to implement a framework to determine which pins are shorted rather than just counting them.
2011-12-04 16:13:30 -08:00
Doug Brown
0a52df645a - Fixed stupid bug of -1 instead of +1 in external_mem.c.
- Began writing an electrical test so I remember WTF I'm doing later
2011-11-27 00:09:29 -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