RE: [avr-gcc-list] External EEPROM verses internal EEPROM datahandling

[Stu Bell]

> The OP might consider writing to FLASH for his data logger assignment.
> Is harder to use as one must write bigger blocks at a time. 
> Might be a wear limit depending on how many write/erase 
> cycles are needed.

While using Flash is possible, this tends to raise more problems than it
cures.  

-> His structure is 58 bytes, but flash must be done in pages, usually
at least 128 bytes.  If he wants to store each time record separately he
needs to either read and rewrite the page to pack 2 records per page
(doubling the cycles of wear-out) or dedicate one 128-byte page per
record.  If he dedicates a page per record, 500 records is 64,000 bytes
(exactly, oddly enough).  Looks like he just graduated to an ATmega2560.
Well, maybe not; an ATmega128 or ATmega1280/1 might do the trick if his
app is small enough.

-> During the flash write, the app will not be able to do anything else,
so data logging will cease for those (granted few) milliseconds the
flash is being programmed.  With EEPROM, if his data collection uses
interrupts, there is no effect as the EEPROM will run concurrent with
the app.

-> As you said, wear-out is 10,000 cycles instead of 100,000 cycles for
EEPROM.  At 15 minutes per record, he starts wearing out memory after
about 104 days.  Even with internal EEPROM (which won't work, too small)
that would be about 2.8 years.

On the whole, I think that an external EEPROM (or better, SD card) is
the answer.

Best regards, 

Stu Bell 
DataPlay (DPHI, Inc.)