Datalogger with Flash

For a flash you need a RAM buffer anyway. This because the flash is block oriented. A good path are the Atmel Dataflash, because they have buffers included.

Rene

If your moving up to a flash part, your increasing your memory size by leaps and bounds. 2 times, 8 times, 1,000,000 times.

Write your code with the erase block size in mind.

Keep two blocks available, and erase the oldest block.

Which device are you looking at using.

The Atmel devices have 256 to 1024 byte blocks.

You are already over writting 16 bytes in a full eeprom.

Good Luck

donald

I handled a similar problem with a logging instrument using am

1. using the onboard 1Kbyte+ (data block size) buffers.

1. Having the data storage wrap around at the end of flash. That way you lost the oldest data, but kept the most recent megabyte.
2. Using the extra bytes in the block (1024 data, about 32 'extra' bytes) to keep track of the date and time that the block was written, as well as some other session data. It was simpler than implementing a DOS-type directory system and wear leveling. (or so I thought at the time. With the availability of Lewin's DOSFS and cheap SD cards, I'm reconsidering for my next project).

The problem with this scheme is that you will potentially lose data in the buffer if you lose power. I handled this with a backup battery and power supply switcher. If the main power dropped out, I wrote the data and went to sleep.

Mark Borgerson

it

There aren't any 'extra' bytes! They are for error correction codes (ECC) to correct small numbers of bit errors in the sectors. The devices are not very reliable - sectors fail or go bad and this situation needs to be detected and allowed for.

Peter

I agree about the estimates of low reliability. In a data logging application as in my project, I would guess that each block might get written perhaps 5 times per year. That would only happen if the instrument was sampling continuously---which is very unlikely as you have to pull it out of the water and clean off the biofouling on a regular basis. I was satisfied that checksums would suffice, as there was significant redundancy in the directory information and the data consists of individual 4-byte floating point values where later values do not depend on earlier values. Were I working with a compression scheme or a data format where a single byte error could compromise a whole block, I would have done things differently.

Mark Borgerson

Thank you very much!, you have been a great help!

Regards,