Post by thread:External EEPROM Choices (Revisited)

At 01:08 PM 3/27/00 -0800, you wrote: I know this thread is a month old but I just got around to reading it. One point to make with the I2C EEPROMs that has not been made during this thread is that the 24C01, 24C02, 24C04, 24c08 and 24C16 DO NOT support multiple eeprom devices on the one I2C bus. The reason is that the slave addr byte is used as the upper address byte (even on the 24C00, 24C01 when no upper address is actually required.) Therefore the suggestion below does not apply until you start using the 24C32 and larger devices. Even then, some only use two address select bits. (Atmel 24C512) Also, there is no standard for the page buffer size. Different manufacturers have different sizes for otherwise the same device, a real caveat to keep in mind. Just today, well yesterday now, I ripped out most of what little hair I have left until I woke up to this. The 93Cx family can be a real pain to work with as they do not have a burst or sequential mode, even for reading. SPI devices are the fastest to access. You can get 5Mhz bus versions and the overhead is the smallest of all types (no start/stop/ack bits) According to industry sources (atmel) SPI will mostly replace the 93C microwire type in the future. I2C will survive because it has other advantages. Also, the SPI code is the smallest as you can use the same code for byte I/O due to the separate i/o pins. The largest page buffer I have come across is 128 bytes in the atmel 24C512. Finally, the 10mS program time is really very worst case. Typical times according to the data I have from 3 different manufacturers (Microchip, atmel and xicor) are more in the range of 2-5mS per page or byte. (I have just spend the last five days doing nothing except coding for all different types of serial eeproms so I'm reasonably clued-up at the moment. :-) -Jim P.S. I recommend Dave Benson's "serial pic'n" even for advanced picsters, it bailed me out of trouble when I couldn't debug my SPI code. ;-) {Quote hidden}>Mike Mansheim <spam_OUTPICLISTTakeThisOuTMITVMA.MIT.EDU> wrote: > >> I've only used the 24LC01, which is an I2C device. If it is >> typical, one should also keep in mind that a write cycle takes >> upwards of 10ms. > > Actually, Mike, it takes a MAXIMUM of 10 ms from the end of > your "write" command until the write is actually complete. > >> Obviously this can be done in the background if you have other >> stuff to do, but if you are looking for "constant" quick access, >> like ram, this is VERY slow. > > Yes, BUT... If you have lots of data to write (which is the usual > reason for needing high-speed access to the EEPROM), you're > probably going to use multiple EEPROMs, and you can interleave > your writes to them in order to "pipeline" the slow write cycles. > > For instance, let's say you're using an EEPROM with a 16-byte > block-write mode. If you write one byte at a time to that chip, > it takes 10 ms/byte. > > If you use the 16-byte block-write mode, each 16-byte write to > the chip takes 10 ms, for an average write time of .625 ms/byte. > > And... If you have eight of those chips (the maximum that one > pair of I2C lines can handle) and you write your data to them by > sending 16 bytes to each of them consecutively, you can > theoretically get a maximum throughput of 128 bytes/10 ms, or > 0.078125 ms/byte. > > If even that isn't fast enough, chips with 32- or 64-byte > block-write modes can cut those times by a factor of 2 or 4. > > -Andy > > >=== Andrew Warren - .....fastfwdKILLspam@spam@ix.netcom.com >=== Fast Forward Engineering - San Diego, California >=== http://www.geocities.com/SiliconValley/2499 > Regards, Jim Robertson NEWFOUND ELECTRONICS ________________________________________ Email: newfoundKILLspampipeline.com.au http://www.new-elect.com MPLAB compatible PIC programmers. ________________________________________

> At 01:08 PM 3/27/00 -0800, Jim wrote: > One point to make with the I2C EEPROMs that has not been > made during this thread is that the 24C01, 24C02, 24C04, 24c08 > and 24C16 DO NOT support multiple eeprom devices on the > one I2C bus. The reason is that the slave addr byte is used as > the upper address byte (even on the 24C00, 24C01 when no upper > address is actually required.) Jim, The MChip 24C01A and the Atmel AT24C01 are not the same. Even the small MChip parts have three address bits that are tied high or low to set the slave address. With these parts, you CAN put 8 EE chips on the bus. Of course for the 24C01 it would be cheaper and probably simpler to use one larger part, but if you needed modularity or redundancy for some reason, it is possible. As you note, the larger Atmel parts (>16K) use the strapped address scheme like the MChip parts, so above 16K, I think they're more compatible. I mostly use the 64K parts myself, where arraying them for larger capacity makes sense. It takes some address translation logic to use several chips as one large area becuase of the need to "increment" the DEVICE address when one rolls from one chip to another. The rest of your points are right on. The page buffer size issue is a pain because its nice to write the largest block possible to improve throughput, but I've had to settle for "least common denominator" write page size to be able to second source. It sounds like you had the same experience. Regards, Barry ------------ Barry King, KA1NLH NRG Systems "Measuring the Wind's Energy" http://www.nrgsystems.com Check out the accumulated (PIC) wisdom of the ages at: PIC/PICList FAQ: http://www.piclist.org

The Atmel at45d081 1M Byte FLASH has two, 256 byte (actually 264 byte) RAM buffers and I have reliably read it at about 4k 256 byte pages per second (continuous) and written at about 75 256 byte pages per second (continuous) via a 12Mhz SPI interface to a 50Mips SX. This is pushing the chip a bit as 10Mhz is the rated max. Writing (and reading) pages from RAM buffer to FLASH and switching from the RAM buffer that is being written to FLASH to the free one and back etc... rather than single bytes makes a HUGE difference. Can't post the source but http://techref.massmind.org/atmel/at45d081 has a lot of information. Also, you can combine at least two of the four SPI pins (SI and SO) without external hardware. --- James Newton .....jamesnewtonKILLspam.....geocities.com 1-619-652-0593 http://techref.massmind.org All the engineering secrets worth knowing {Original Message removed}

At 11:55 AM 4/28/00 -0500, you wrote: >> At 01:08 PM 3/27/00 -0800, Jim wrote: >> One point to make with the I2C EEPROMs that has not been >> made during this thread is that the 24C01, 24C02, 24C04, 24c08 >> and 24C16 DO NOT support multiple eeprom devices on the >> one I2C bus. The reason is that the slave addr byte is used as >> the upper address byte (even on the 24C00, 24C01 when no upper >> address is actually required.) > >Jim, The MChip 24C01A and the Atmel AT24C01 are not the same. Even >the small MChip parts have three address bits that are tied high or >low to set the slave address. I have checked this again and in fact microchip listed 5 different types of 24C01. Only one of the 5 utilized pin strapping for address selection. This was the 24C01C. The same is true for the 24C02, only the 24C02C has device addressing. There is no 24C04C, 24C08C or 24C16C as these parts are over 256 bytes and require high address bit(s) which replace the device slave addresses thus creating the problem I was taking about. Some microchip parts appear to have A0,A1,A2 pins but looking at the fine print we see that they are not internally connected. With these parts, you CAN put 8 EE >chips on the bus. Of course for the 24C01 it would be cheaper and >probably simpler to use one larger part, but if you needed modularity >or redundancy for some reason, it is possible. Right for the 24C01C and 24C02C only. I was right in all but two cases. >I mostly use the 64K parts myself, where arraying them for larger >capacity makes sense. It takes some address translation logic to use >several chips as one large area becuase of the need to "increment" >the DEVICE address when one rolls from one chip to another. I would have thought it easier to interleave the addressing as Andy Warren suggested. Especially if the page buffer size is 256 bytes then you would only need to manipulate the high order address byte. >The rest of your points are right on. The page buffer size issue is >a pain because its nice to write the largest block possible to >improve throughput, but I've had to settle for "least common >denominator" write page size to be able to second source. It sounds >like you had the same experience. I think I will provide an option for the user to select the page size in the next programmer driver. Set it on the lowest common denominator by default and let the user up it at his/her own risk. {Quote hidden}> >Regards, > >Barry >------------ >Barry King, KA1NLH >NRG Systems "Measuring the Wind's Energy" >http://www.nrgsystems.com >Check out the accumulated (PIC) wisdom of the ages at: >PIC/PICList FAQ: http://www.piclist.org > Regards, Jim Robertson NEWFOUND ELECTRONICS ________________________________________ Email: EraseMEnewfoundspam_OUTTakeThisOuTpipeline.com.au http://www.new-elect.com MPLAB compatible PIC programmers. ________________________________________