Electronics/Computer Projects

Well, this post contains both good news and bad news: Good News part 1. I spent the later half of yesterday wiring up the arduino to the EEPROM board proper. I then began to check basic functionality such as proper voltages, proper and state of the EEPROM control lines. Everything checked out, so I decided to test with an NVRAM that has an identical pinout. I encountered a few errors in the software in this process. The controller was not allowing the device to complete a read or write cycle before moving on to the next byte, fixed by adding a 1ms delay between pulling the read or write lines low, and pulling them back up. I accidentally left out a = in the test part of some if statements, so it would read as 'if(Error=1)' instead of 'if(Error==1)'. This caused the send/receive portions of the write and dump routines to fail out, thinking the Xmodem packet was being improperly received or sent. The first 128 bytes of the NVRAM was being rewritten with data from the ...

I have decided to revisit my earlier plan of making an EEPROM programmer with as few I/O pins required as possible. I have decided to abandon that requirement in favor of making something functionally complete with a minimum of software development required. I'm using an Arduino Mega as the programming controller, with the sole reason being the large amount of I/O pins available. Rather than reflashing the controller every time an EEPROM needs to be rewritten to hold a new program, I've implemented a method to send the desired program over a serial connection, and program the EEPROM in 128-byte chunks. This is done via the Xmodem protocol, which allows for a pause between packets to allow time for programming 128 bytes at a time, before requesting the next packet. Due to the variant of EEPROM I have, a 12V level signal needs to be applied to the /OE pin in order to enable a full chip erase. This 12V line will be handled by an opto-coupler, and a momentary pushbutton acting ...