EePrOm:
...I guess I wasn't specific enough for you
Apparently not. The title that you gave the thread is "EEPROM Programmer" but those chips are not EEPROMs, they are Flash memory devices. (Nowadays, we usually call them "NOR Flash" to distinguish them from those new-fangled upstart "NAND Flash" devices.)
Now you are telling us:
EePrOm:
I want it to program onto a 32-pin flash chip,
.
.
.
ATMEL AT49F040
.
.
Sorry, I am unsure of the volts it can handle.
Ummm--- You are proposing a project and you haven't even read the data sheet(s)?????
Oh, well...
It's an interesting enough project that I'll take it a little farther.
First things first: The connections.
If you are working with a DIP package you can plug it into a solderless breadboard, or get a socket and use it. (A ZIF socket would be the "only way to go" if you are going to make this project a "product," but before committing to that, you can breadboard it. Use some bypass capacitors on the device. For starters, confirm (by reading the specific data sheet for your specific device) that it will work with a 5 Volt supply. (Some older types of similar devices require higher voltages when programming.)
If you expect to program TSOP devices you will need an adapter board and a (rather pricey) ZIF socket. For PLCC packages, you might be able to find a socket that converts to wire-wrap pins or thru-hole PC board pins.
So: you need something like 19 output pins for address, three output pins for control, and eight data pins that are sometimes outputs and sometimes inputs.
If this is an Arduino with a '328 processor, there aren't enough pins. If it is a Mega board (or anything using a processor with enough I/O pins), I would just connect them directly.
Anyhow, for an Arduino with not so many pins:
I would use a shift register to hold the address bits. (There is lots and lots of information on the Arduino forum and playground about how to do this.)
I would use eight Arduino pins (maybe 2-9) for data and three pins (maybe 10-13) for the control signals.
Now the fun part: The software. Now if you are just going to program the device by writing some bytes, see the data sheet for the sequence.
I'll summarize:
The "default" mode goes like this: Make Chip Select and Output enable go low and make Write Enable go high. Apply an address. The data byte from that address will be presented for your reading pleasure. Give it a new address and it gives you some new data.
To do more interesting things, you have to give it a certain Magical Mystery sequence of Address/Data/Control settings to tell the device that you are going to be writing a byte or erasing a sector. Stuff like that. Each data sheet has flow diagrams that you can use to build your software. I have done this a time or three. The "driver" software that manufacturers sometimes make available may be appropriate for PC-based applications, but for Arduino stuff, just follow the flow charts in the data sheet(s). The devices in the family that you refer to are "pretty much the same," but after you get the first one working, if you want to try a different one (from a different manufacturer) read the new data sheet too. Really. Read the data sheet.
Note that there are various versions of the devices with somewhat different characteristics. The basic structure of a program to write data to these devices may have certain special branches, depending on the exact device.
Some have "boot block" sectors that have different rules for writing. The Boot Block sectors have different protection bits so that "ordinary" programs can't accidentally erase them with a "normal" program sequence. The sector lengths are usually different from "normal" sectors. Stuff like that. Some devices are available in different versions. with some having the boot block at the high end of the memory space, and other versions having it at the low end.
So, here's the drill:
Pick a device that you want to start with. Read the data sheet. Really. Hook it up. Try reading it. Unprogrammed devices will read 0xff for all bytes, so it's possible to fool your self if you do it wrong. (Leaving CS or OE high for example will show you all ones, since you will have pullups on the data lines.) If you have a 'scope or other test equipment that can read the address lines, make sure the shift register (and associated software) are working properly.
Try to program some byte of your choosing at an address of your choosing. Follow the flow chart in the data sheet.
Try to read the byte back.
If there are questions, you can ask. But be specific. Describe your hardware setup and show the entire program that you are trying to get working.
Maybe someone can help.
If you are still interested, I think that's enough to get you started on the basics of Flash memory reading and writing. See Footnote:
Regards,
Dave
Footnote:
But (and this is a Big But): What are you going to do with these things after you program them?I
If you are going to write files (of any kind), then you have to keep track of where they are located. That implies some kind of "directory" that associates a block of memory with a particular file. The directory contains (at least) the "name' of the file, the starting address in Flash and the length of the file.
People typically devote a certain amount of device memory to this directory (fixed length and at a fixed location), and each time they want to write a file, call a function that looks for an unused block of the desired length. The program enter the name and starting address and length in the directory.
Then, to read a file, you would tell the program what the name is and the program would look in the directory to find out where it is.
The big deal is, again, what are you going to do with the data from the file?
For example: If the file consists of 16-bit samples of a monaural .WAV file, you could get 16-bit values from successive bytes in Flash and feed the bytes to a D/A converter.
Stuff like that.