Question on the delay of 10 ms when writing to the EEPROM

[ralphtheninja]

In the video where you go through how to build an EEPROM programmer with the Arduino Uno you ended up using delay(10); at the end of the writeEEPROM() function. Did you come to any understanding why this was the case?

What if you want to write all the 2048 bytes, then it would take almost 20 seconds and it would be even worse for an EEPROM with 128 or 256 kbits.

Would it be possible to optimize the writeEEPROM() function to let it take an array of bytes and put the delay(10) at the end of writing all the bytes?

[greenonline]

Yes. You could potentially reduce the 10 ms delay by instead polling the MSB of the last byte written, and waiting for the MSB inversion to end, and then proceeding. However, how much time would be saved by the polling and waiting might not be all that significant.

This issue is partially answered/explained by this comment by Greg Clare under the video:

Hi Ben. Good educational stuff. But just thought I’d point out that the issue you saw with your incorrect read following write, is because you didn’t implement the (not)DATA POLLING, outlined in the 28C16 data sheet.
ie. "The AT28C16 provides DATA POLLING to signal the completion of a write cycle.”
DATA POLLING uses the inversion of the most significant bit (when a post write read is performed) to indicate the write busy state. Please also note that the other read bits (other than MSB), are indeterminate during the data polling busy state.
So when you saw two subsequent reads of 0x81 after writing 0x2A, you’ll note the byte you wrote (0x2A) has a 0 MSB, and the read value (0x81) has a 1 MSB (ie. inverted 0 indicating busy state). The remaining bits of the 0x81 byte being indeterminate.
By the third byte read, the busy state was complete, and the 3rd address data byte, and onwards, were then correctly retrieved.
Likewise, the same can be seen with your second attempt to write 0x00, where you then read 0xAA bytes. Again, note the MSB is inverted from 0 to 1, to indicate data polling busy state.
In summary: Although the Write Cycle Time is spec’d as max 1ms, you really shouldn’t just assume a 1ms delay will do the trick. The correct implementation would be to perform a read loop after a write, to poll for a non inverted MSB of the byte just written, to await busy state completion.

This is also backed up by at least two further comments in the main comment thread (not under the above comment):

• From MadManMarkAu

  If you read the datasheet carefully, it says if you read from the chip, and the write cycle is not yet finished, the MSB of the data will be the INVERSE value of the data you are writing. The other data outputs are undefined at this time.

  After pulsing the /WR line, you should enable the chip output and monitor the value of IO7, waiting until it matches the MSB of the byte you wrote. That way you're not stuck inserting arbitrary delays in your code, and you can never enter in to a race condition with the write cycle, like you are here.

  This is the reason you get funky data when reading the chip, directly after writing to it.

• From AJMansfield

  To get rid of the delay(10) in the writeEEPROM function, you could take advantage of the inverted data polling feature of those EEPROMs that lets you directly determine when the write cycle has completed. After clocking the write enable pin, switch back to reading that address and wait until the data you wrote appears on the output pins.

That said, if one reads the correct datasheet, for the CAT28C16AP-25 used in the video, t_WC (max) is given to be 10 ms, and under Byte Write it is stated:

Once initiated, a byte write cycle automatically erases the addressed byte and the new data is written within 10 ms.

So, for this particular EEPROM the delay of 10 ms is actually correct and appropriate.