topic Re: Safe Serial EEPROM speed in 8-bit Microcontrollers

Safe Serial EEPROM speed

alexod — Sat, 27 Sep 2008 01:51:23 GMT

Just a quick question, I think I know the answer but here goes.

I am developing code for a board which has a removable SPI EEPROM. For now there is only one EEPROM module to plug in, but we may add more varying vendor, density etc. I see SCLK speed is a variable between devices, from the data sheets I have seen, I would say 1MHz is about the slowest EEPROM out there, the Microchip 25LCxxx we are using is 10MHz, and Atmel seem to offer 20MHz for a similar part.

The intent is to have the EEPROM formatted, and the header to include a speed field, the EEPROM will be read at slow speed, then speed turned up when we know what it can handle.

Has anyone seen slower than 1MHz?

Has anyone had success in "trial and error" speed determination?

Thanks

Alex

Re: Safe Serial EEPROM speed

PeterHouse — Sat, 27 Sep 2008 02:08:08 GMT

Alex,

You should clock at the highest, slowest speed you can!

Here is my experience: In general, the faster you clock, the more noise and errors you generate. A typical '08 may be able to clock at 2MHz which sends an entire byte in 1us. This is near the instruction time for most instructions and while you can send a single byte at this rate, the best code will likely only transfer a byte every 10us or so. Given this information, I would clock no faster than .2MHz or the nearest available higher multiple of clock frequency supported for your chip.

When you are writing data to the EEPROM it will likely take milliseconds to write a byte or a block and your overall speed will be limited by this time more than anything else.

The concepts here are good and you should work the math for your uC and determine your best speed.

Good Luck,

Peter House

Re: Safe Serial EEPROM speed

bigmac — Sat, 27 Sep 2008 02:37:40 GMT

Hello Alex,

For the Microchip part, the maximum clock rate will be dependent on the minimum supply voltage applicable to your project. The 1 MHz limit would seem to apply for operating voltages down to 1.8 volts, with a significant increase of speed for higher operating voltages.

I wonder how much will actually be gained with the use of a variable clock rate? There will be the extra "overhead" for reading the header, and there would be negligible advantage for each write. There might be a small advantage when sequentially reading large blocks of data. Is it worth the extra complication?

You will probably find that the time required for the SPI transfer represents only a small fraction of the total time required to process each byte read.

Regards,

Mac

Message Edited by bigmac on 2008-09-27 05:51 AM

Re: Safe Serial EEPROM speed

alexod — Sat, 27 Sep 2008 03:40:37 GMT

Mac, Peter,

Yeah, the faster reading won't be needed. It was Pavlovian reflex after having a couple of previous speed optimized flash based projects.

What I really want is to know if 1MHz is slow enough for the common speed. I re-read the datasheet for write speed after reading Peters posts, there is a 16byte page write limit anyway on the Microchip, the overhead managing writes will be possibly more than the byte time, so why worry about bus speed. The Microchip has a 3MHz FCLK at 1.8v, we are 5v though.

Now I wonder are there any 8 byte pages out there! Again, I had flash code where I accidentally used superset functionality with an Atmel flash part, and when we changed vendor my algorithm failed due to block or page size differences.

Thanks for the pointers.

Alex

Message Edited by alexod on 2008-09-26 01:42 PM

Re: Safe Serial EEPROM speed

peg — Sat, 27 Sep 2008 05:21:23 GMT

Hi Alex,

It seems, in general, that older devices used 4-byte pages and newer ones use 16-byte. I used to use a Xicor part that had 4-byte pages and when it became obsolete in DIP I changed to a CSI part with the same basic part number. It had 16 byte pages, however, after some investigation I left the code the same and it works fine. I was mostly accessing only up to 4 bytes at a time anyway and larger "at a time" accesses did not divide by 16 anyway. This also allowed me to still use other devices that I may be able to obtain.

Basically changing the code to allowing 16-byte page accesses would save a couple of milliseconds a day but then limited the type of devices that I could fit. So it would seem to be a good idea to check the available page sizes available and code for the smallest one.

Re: Safe Serial EEPROM speed

bigmac — Sat, 27 Sep 2008 12:02:46 GMT

Hello Alex,

You did not say what size of EEPROM you are considering. It would seem that higher capacity devices will be of more recent design, and are likely to have a higher clock speed limit, and a larger page write buffer. A very commonly available size would be 64Kbit (8K byte) - perhaps this should be the minimum size under consideration.

I have a collection of datasheets, accumulated over the years, and quick review of the 32K/64Kbit SPI parts suggests that the page write buffer is likely to be 32 or 64 bytes. For the 4.5V-5.5V supply range, a clock rate of 2MHz would seem to encompass all the parts that I reviewed.

For cases where the maximum clock rate was 1MHz, this applied to either lower voltage parts and/or smaller capacity parts of earlier origin. The minimum page write buffer size was 8 bytes, applicable to an early, low capacity Atmel part.

Where fast writes of large amounts of data are required, the Ramtron FRAM devices (e.g. FM25640) might be considered. They do not require a write buffer because they can immediately write each byte at their maximum clock rate. Therefore, any number of bytes can be sequentially written.

Regards,

Mac

Re: Safe Serial EEPROM speed

alexod — Tue, 30 Sep 2008 01:39:36 GMT

Hello Mac,

We are using a 16K bit EEPROM. There are options to use smaller or larger EEPROM, but the smallest is 8K bits, in the Atmel family that is the AT250080, the A version has an 8 byte page, the B version has 32. Microchip would be the 25AA080, A version is 16byte, B version is 32 byte.

Looks like I need the 8 byte interface, then put a not in the design file so we know not to go smaller/older than that.

I am convinced I am moving so little data that I won't need to worry about speed, other than keeping it to the lowest common denominator, and that seems like 1MHz shoud be safe.

Thanks to all who commented, I now have a clear way forward.

Alex