What non-volatile memory should I use?


I read the internal Arduino's (ATmega's?) EEPROM's lifetime is limited to about 10k writes.

I am planning to make a device, which will require to read-write EPROM more often (to remember every change of settings). Let's say it will be 50-100 times per hour. That's - in the optimistic variant - less than 10 days of life for the Arduino.

What should I use? Is "normal" EEPROM (like AT24C256) good for me, or maybe I should focus on some other type of NVM?

EDIT: of course I'd like it to be as cheap as possible :)

Most non-volitile memory is based on FLASH and all FLASH technologies have s limited write-life.

If you need to write 50-100 per hour, you might consider battery backed RAM. That is a pretty high amount of use and probably not a good application for non-volatile memory.

As per the AVR datasheet, EEPROM is good for 100K erase/write cycles. External serial devices are usually specced to 1M cycles. With careful power and sleep mode management, it may be feasible to not have to use NV at all.

That write cycle limit is also per address - so if you are writing to the same location constantly it can be longer. Why not use SRAM, and then save the SRAM contants to EEPROM as part of controlled power down sequence? Writing to SRAM will be faster also, don't need to wait for slower EEPROM writes to finish up.

Well... I want to save settings when they are changed, to make the device start with the last settings when turned on the next time.

It would be easier if the turning power off could run the function, which would save the settings. But I really have no idea, how to do that without power backup - the backup should detect turning off, run the interrupt and keep the power up for a little time to allow the Arduino save the settings. But I haven't found a good power-backup schematic. I don't want to do it on battery backup, because it requires to be controlled sometimes.

Well... maybe it's time to search in that direction instead of NVM...

I didn't think about sleep mode, because it does not protect from the powerdown, which happens sometimes at my place ;)

Well... I want to save settings when they are changed, to make the device start with the last settings when turned on the next time.

And you expect changes to occur 50-100 times per hour? If a setting hasn't changed, why would you write it again?

And you expect changes to occur 50-100 times per hour?

That's very pesimistic variant and the real number of changes will of course be dependent on the user's "me wants to change now!" :)

If a setting hasn't changed, why would you write it again?

No, I would not. It's not planned as a timer, which would save settings with the exact time interval. Let's say there's an input and output. The user can change the value on the output by operating on the input. And only then I'd like to save settings, so when user turn the device off and then turn it on again whenever he/she wants, there will be the last set value on the output, read from NVM in setup()

As I said, the 50-100 changes per hour is waaaay to much, but... why should I make the device even for only a year? I'm seeking the best sollution, which would have a long life and wouldn't require changing batteries. Of course, I may seek in the wrong direction...

You could always build in a Li battery and charger, like a max1811. http://www.maxim-ic.com/datasheet/index.mvp/id/2536/t/al or a 2-cell charger, have it connected via diode to Vin same as the wallwart goes in. Go into sleep mode when you detect lack of activity from whatever it is you're dealing with, and wake via interrupt (external, or occasionally via internal timer, lots of options).

Since you havent said your actual application, it is tough to suggest a "best" solution.

However, nearly every device with settings "remembers" them with flash memory. A limited number of write cycles might seem limiting until you realize: 1) how rarely you save and 2) the rated spec is a minimum.

That being the case, in your application how often will someone make changes? Once an hour, on average? Average is the key here. Most other components are rated in tens or hundreds of thousands of hours. In that case, your write "limitation" really isn't the gating factor.

Implement some code that checks the setting after a write. Then you'll know if an error occured.

I don’t think you fully picked up on what CrossRoads said:-

That write cycle limit is also per address

So if you have 2K of EEPROM space free and only want to use 1 byte then each write can be to a successive address. When you have filled all the space you erase all the memory and start again. Those 2K writes only count as one of your permitted cycles.

Note that the eeprom and flash have different documented lifetimes. IIRC, eeprom is much larger than 10k writes, but the datasheet will say for sure.

That write cycle limit is also per address

Well, probably "per page."

Do you really anticipate the user going "me want to change now" 10000 times? Granted during initial playing, they might change something every minute for the first hour or so, but that doesn't really equate to them continuing 50x per hour, 24x7...

Well, probably “per page.”

I have no idea how the Flash fails but for EEPROM failures are apparently “by byte / cell”. In other words, writing to a single EEPROM byte 4,000,000 times will very likely cause that single byte to fail but no others.

Ah. The "paging" of EEPROM is apparently only relevant when programming it from external sources (ISP or parallel programmer.) When writing from a program, you can do one byte at a time...