Flash Vs EEPROM

Jim McCorison

I am working on a data logging project which potentially needs to accumulate and store the data for an extended period of time. As such I'm looking for non-volatile storage media in the roughly 512k BYTES range. I'm new to this sort of stuff (I'm a software kind of guy.) so maybe I've overlooked something that others would take for granted. But it appears that my choices are EEPROM or Flash. What are the trade-offs between the two. Write cycles shouldn't be a problem as I'm looking to store a years worth of data. The target chip for prototyping is a BS2 and probably an SX for the end results.

Thanks for any insights that you can provide.

Jim

Paul Baker

They are the same thing, with 1 difference: eeproms permit erasure of a single byte, flash requires the erasure of an entire page and some flash require writing an entire page (sub page writes are held in a buffer and if power loss occurs before you flush the page you lose that data). The size of a page varies by part but a general rule of thumb: the larger the memory the larger the page. I am stabbing a guess but I would expect a page size of arround 512 or 1K bytes (Im too lazy to go look it up).

There is another option: non-volatile sram, but at the denisity your looking at it is cost prohibitive (the one 512x8 currently stocked by digikey is just over $100) but if data retention of a decade, fast (comparatively) operation, or many overwrites (>10K) is very important, the steep price may look more attractive. (mouser has 128K's for $15)

Or you can take a normal SRAM and add a non-volatile controller chip (DS1210 is $4.85 and the industrial temp version is $5.70) these chips provide enough power to an SRAM to preserve data retention from a battery, with a consumption of less than 100nA you can keep the data preserved for many years from a single lithium battery (actually thats just for the chip itself, they quote ram backup current of 10uA (for a total of 10.1uA) but it also allows you connect a backup battery as well (funny a backup battery for a backup battery (but who backs-up the backup's backup?, sorry I couldn't resist)).

Post Edited (Paul Baker) : 1/10/2005 11:52:45 PM GMT

Jim McCorison

Paul,

Thanks for the EEPROM Vs Flash info. EEPROM sounds like a better choice for what I'm trying to do.

Basically I want to periodically sample and store an averaged value on a 5 minute to 15 minute basis. I haven't really decided yet, memory size will most likely dictate the frequency. I'd like the data to be viewable through a small LCD screen in either an averaged crude graph or stepping through detail or individual averaged data. (Kind of like every 5 minutes, or hourly averages & totals, or daily averages and totals.) I'd like to be able to accumulate a years worth of data before wrapping. This would allow download and detailed examination at some future date if desired. What I've figured is that the data will range from 210K bytes for 5 minute averaging to 70K bytes for 15 minute averaging, for a years worth of data, per device monitored. I'd like to monitor 4 devices. If I can find lots of memory pretty cheap, I'd add min and max for each sample period as well. But that would require 230% more memory for a given averaging period.

Anyway, overwriting certainly won't be any issue unless the device is in use for 100.000 years. And since I'll probably only be sampling every 15 seconds or so, speed isn't an issue either.

Thanks for the help.

Jim

Paul Baker

Is your data logging device continually on (ie power is on unless some unforseen freak event occurs, or even if you microcontroller is sleeping but still has power applied) or are you powering up the device, taking the measurement and completely disconnecting the system from its power source? If its the former the DS1210 will only draw power from the backup battery if that freak occurance happens (generator fails, main battery goes dead or what not). And one last question, is there anyway this can be exposed to salt water (Im only asking this because its you) if there is a chance your board gets a not-so-healthy dose of saltwater such that you fry your board, a flash or eeprom could possibly be removed from the system and the data be salvaged (not a gaurentee though) but if both your batteries are shorted by salt water for a long enough time you will lose the data on the SRAM.

I have experience designing and building data-loggers that were sunk to 10m depth, and we always used eeproms, which saved us a couple time when the bouy fabricators didn't do their jobs right (the bouy tether snapped forcing divers to recover a logger that explosively compressed when it sunk to 25m and we still recovered all but the last data sample)


Post Edited (Paul Baker) : 1/11/2005 12:16:18 AM GMT

Jim McCorison

The data being logged is current consumption/generation. As such, I expect that it will usually have power available. However, as you surmised, it is going on a boat, and it is not uncommon for batteries to be switched off completely when the boat is left. Hence the need for non-volatile memory. I'll look into the SRAM and DS1210 combo as well.

If the system gets dowsed with salt water I suspect that whether it retains it data or not will be the least of the worries.

achilles03

Two quick points:

1. You might be able to reduce the size of the information you're storing. For instance, if you're storing a single number ranging from 0 to 15 (or less), then you can atleast reduce the required storage size by a factor of two. Just take two samples and record one as a highnib and the other as a lownib for the same byte.... just an example.

2. There's many 8-pin eeproms out there that can store 64kbytes (for SPI eeproms) and 128kbytes (for I2C eeproms). The I2C eeproms are a little harder to integrate (my opinion), but you can use several on the same lines. You can use the SPI eeproms similarly (clockpins and datapins all tied together), and have the chipset pins separate. So for 8 eeproms (512kB), you'd need 10 pins (1 clock, 1 data, and 8 chipsets). Everytime your address got to 65535. you'd move to the next chipset/eeprom and reset the address to 0. Personally, I prefer SPI, just because they're easy to use and I'm familiar with them. Just a suggestion...

Dave

Gadgetman

You can reduce the number of pins dramatically either by using a shift register which needs 2 pins(clock and Data) or a 74xx138 3-to-8 decoder, which'll need 3 pins to generate 8 Chip Select signals.

It's also possible to use ordinary EEPROMs by setting up one or more counters for the address pins.
When the system starts, reset the counters to Zero, then pulse the clock every time you write to it.
It's not the fastest for retrieval, but as you probably want to read the data sequentially, that shouldn't be a problem.
If you try something like this, you should probably have at least two, possibly more separate counters as clocking halfway through a 128KB address range takes some time. (Better to pulse the high-address a few times)

The old Psion Organiser I & II series PDA's used this strategy to store user data on EPROMs (It also had a charge-pump for the write-pulse, but many EEPROMs doesn't need that)
The only drawback was that you needed a UV Eraser to clear the chips periodically.
(Psion had a free eraser service)

Jim McCorison

Dave,

The data will range from -40 to +200 or there abouts. But I think I can cheat and store only the absolute value because no individual device can be negative and positive. So my config can tell me whether a reading should be + or -.

I've also been following the thread over on the SX forum about this issue http://forums.parallax.com/showthread.php?p=522150 and Paul has offered some nice advice there.

Of course the more I start adding up the various things that have to be done, and the capability of the different stamps, it's beginning to look like I may have to chalk up the BS2 as just a learning and experimenting tool and start my prototype on the SX instead.

Jim

Paul Baker

Jim, You needn't worry about computing the absolute value, your data range is 241 just work with an offset of 40, if you need to compare a negative and positive number, take it into account then, Using an offset is faster than computing the absolute value.

Jim McCorison

Paul said...
just work with an offset of 40

Great idea! That's the really good part about talking out ideas. Somebody always has a different, and frequently better, approach to the problem.

Thanks.

Jim