External EEPROM faster than WRITE?

achilles03

I've been working on a fast datalogger for an accelerometer and pressure sensor to go on a high powered rocket, but had trouble in the past getting fast sampling rates when writing data to the BS2's eeprom.· However, when I incorporated an external eeprom (which I had assumed would be slower than WRITE) it sampled much faster with the same BS2.· Right now I'm averaging about 150 samples/sec (75 from accelerometer,·75 from the pressure sensor) with a dual-channel 12-bit ADC (which has to be addressed) on an external eeprom, while I couldn't break 100 samples/sec with the WRITE command while just the accelerometer on a·single-channel·10-bit ADC, which is faster and doesn't need addressing.· Thus, I assume that the WRITE command is slower than using an external eeprom.· Is this a correct assumption?· And if so, why is WRITE slower?

Thanks,
Dave

Jon Williams

WRITE actually IS using an external EEPROM. Remember, too, that WRITE is an instruction with several possibilities. The instruction itself has to be fetched and decoded from the EEPROM and then setup per the syntax of that instance in your code. I'm not terribly surprised that you can write specific code that outperforms WRITE ... but if you made your code as flexible as WRITE you'd find that's no longer the case I bet.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas Office

Tracy Allen

Hi Dave,
As with all commands on the Stamp, the WRITE command has to finish its execution before the Stamp moves on to the next command. The EEPROM has a signal that tells the Stamp when it is finished, which takes typically 3 milliseconds, but can take up to 10 milliseconds per WRITE at worst case specs. On the other hand, when you send data to an external eeprom, your program can continue immediately, which with a vanilla BASIC Stamp is a time on the order of 0.1 millisecond to read in the next instruction from the Stamp eeprom. To be safe, your program should check the eeprom ready flag before it sends the next byte, but usually the Stamp program will take plenty of time executing program instructions first, so the eeprom has plenty of time. It is matter of concurrent processing.

In addition to that, with most eeproms like the 24LC series, there is a buffer internal to the and for best efficiency your program can write blocks of 16 or more bytes at a time. For example, with an external eeprom, you can stream out two bytes with one I2C command, whereas with the WRITE command you have to do the two bytes separately, and each takes 3 milliseconds. (Watch out for boundaries between the blocks!) The Stamp eeprom (a 24LCxxx) also has the capability for block write and block erase, which are excersized when you RUN a program, to load the program from your PC into the eeprom. See how fast that goes, using block writes? But the WRITE command is strictly one byte at a time.

BTW, the command, "WRITE Word mydata" actually resolves to two separate WRITEs.

READ too is a relatively slow command, because the interpreter has to save its current program position, fetch the data from the other position, and then restore the program pointer. That overhead is also part of the reason WRITE is slow.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

achilles03

Tracy and Jon,

Thanks for the follow-up.· It makes sense that the WRITE would be slowed since it is waiting for confirmation that the data was written, and since it only does one byte at a time.· The samples I'm recording are word variables (2 of them), which I'm page-writing into the eeprom (4 bytes worth of data).· I guess that'd be a lot faster than write-enabling the eeprom and·addressing it·4 times.



Thanks,

Dave