Table of Contents
Everyone and their granny has a ‘zero-parts’ EPROM, EEPROM or Flash programmer design. Well, I got mine. A Flash RAM programmer is going to be a necessity as the CFT project acquires speed, and I'd rather make my own tools than buy them at exorbitant prices. I need to program certain types of parts only (namely 4-MBit Flash RAMs), and wanted to use what I had handy, so the implementation reflects this. The programmer uses an AVR Atmega-8 microcontroller, three 74164 ICs and a handful of passive components. The hardware design was inspired by Jay Kominek's Parallel port EEPROM programmer. Since parallel ports are becoming rare, I embellished the design by using an AVR Atmega-8 microcontroller to do the hard work, and an FTDI USB-to-serial cable to take care of communications and supplying power. I made sure that all of the expensive components (the FTDI cable and ZIF socket) are removable so I can reuse them for other projects. For now, this is a fairly specialised little device, but I may add more functionality to the schematics, and will certainly add to the hardware itself as I need more functions.
The device is very generic, and can program any parallel-programmed EPROM-like device. However, the current schematic drawing makes some assumptions.
Since I designed this primarily for me, the compatibility is fairly limited at the moment since only a handful of parts make financial sense in 20111. The socket is designed for '010, '020 and '040 EPROM, EEPROM and Flash RAM pinouts.
The schematic does not allow for a separate VPP input to the socket because I'm programming 5V-only devices. Feel free to add one yourself to the appropriate pin. If the VPP is anything other than 5V, you'll obviously have to source the voltage in some way. The standard way with self-built EPROM and EEPROM programmers is putting a power jack (or terminals) on the board and using a bench power supply to provide the exotic voltages needed.
Theory of Operation
The programmer works by using three 74x164 serial-in-parallel-out shift registers to buffer the address pins of the EPROM/EEPROM/Flash chip, and using eight pins on the Atmega for the data. Each 74164 outputs 8 bits of address data, for a total of 24 bits, which is more than I need. The 74164 uses a dual A-B input (which is ANDed to provide input to the shift register), a clock input, and a clear input. Clear is permanently wired to VCC to disable the signal. The clock signal from each 74164 is fed to a separate pin on the Atmega. The B ports of all registers are driven together by a single pin on the microcontroller. All the A ports are also tied to VCC permanently. This way, the Atmega can set the B port and then strobe one of the clock output to control a single shift register. Using appropriate code, all three registers can be updated rapidly.The firmware maintains the current value of each register, and avoids resending it if it hasn't changed. So, when programming sequentially, only the least significant register is updated all the time. The second register is updated once every 256 bytes, and the third and most significant one is updated once every 64k.
The memory chip's data bus is split into two nybbles and connected directly to the microcontroller. The signals are split because the Atmega8 doesn't have an entire 8-bit port easily accessible. The microcontroller can configure these pins as inputs or outputs, and so both read from and write to the memory part. To avoid shorts and other nasties and (probably — I don't care to test it) to allow hot-swapping of the memory chips, the data bus spends all its idle time floating (configured as input), and is only driven when a write is in place.
Chip control signals CE, OE and WE are also directly wired to the microcontroller for easier access. For safety, WE is also pulled up with a 1kΩ resistor. Since AVR microcontrollers boot with their pins configured as inputs, we need the pull up resistor to make sure WE is high, and writing is disabled. The only downside of this design is that there are no failsafes: you could modify the firmware to assert all of these signals simultaneously, which would confuse the memory chip.
For communications accuracy, the Atmega is clocked externally using a 7.3728 MHz crystal. This is a good rate for serial communications, and allows us to reach speeds of up to 460,800 bps. The FTDI serial-to-USB chip is very happy to deal with such transfer rates and the whole chain works flawlessly. You could run the Atmega with different crystals, or use its internal R-C oscillator (don't forget to set the appropriate fuses), but this would severely limit your data rates, and introduce serial communication errors.
For status indication, a power LED and an activity LED are provided. The activity LED is wired to signal A14 of the ZIF socket. I did this so it would blink while reading or writing. Unfortunately, the device reads and writes too quickly for the blinking to be evident at 460,800 bps. At lower speeds, A14 might be enough. Alternatively, you could connect it to A15 or A16. The firmware blinks the LED (by modifying the address on the shift registers) at appropriate points to indicate activity.
The control software allows for a modest amount of human interactivity, although you'll need a microcontroller with more than 8K of Flash RAM for a better feature set. The interaction is a little bit like a Hayes-style modem (you know, the type with the AT commands). Of course, this isn't quite enough for practical use.
A Python program,
flashprog, takes care of the computer-side of
things. It allows you to read, write, verify and erase memory chips. The Python
program (and some of the microcontroller firmware) were written to cover my own
needs, so there are absolutely no guarantees the software will work for parts
other than the ones I have handy. I will update the software and
firmware as I get my hands on more parts I need to program.
Both the software and hardware are provided under the terms of the GNU Public License (GPL).
You can find everything here, including Eagle schematics, firmware, source for
the firmware, and the
- 1 I need three 8K (2764/2964) chips for the CFT microcode ROM. Can you believe it's now cheaper (by a factor of two, sometimes) to buy 512K chips than 8K chips?)