help on eeprom write strategy

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

i have a circuit with atmega88 and 8 predefines modes of work, that can be changed acting on 2 switch buttons.
Modes can be changed very often, more than one time in a second, depending on the human hand speed.
I want keep the current mode stored in eeprom, so that at next reboot device remember to start in that mode.
But i don't want write the eeprom at every button pushed, to avoid too frequents eeprom writes.
What is the common approach to develop this ?
thanks
angelo

Angelo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1. While the erase/write operation wers down EEPROM, reading does not. So first line of defense is: If the mode in the EEPROM is the same as the mode in the running app ten nothing needs to be done.

2. If you are actually talking about cutting power to the thing and the the mode should be remembered at power up: Implement some means so that the AVR has power to run for a short while (milliseconds) after the power switch has been thrown to off. Reat to the power off, e.g. by the brown-out detetor. Immediately do a write of the current mode to EEPROM. Then it's OK to die.

3. If the mode is all you need to store in EEPROM then you can get a lot more than 100000 erase/write cycles out of it. Divide the flash into parts. Use one part to keep track of in which other part you currently save the state. In each such part you also need to keep track of how many times you've written to it. When you are closing in on 100000 write to one place you i) update the "master pointer" to point to the next part, and ii) write a 1 in the count field and the current value of the state. Now you might have millions upon millions of writes to the EEPROM before you risk it wearing out.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

More on my point 3 above:

The ATmega168 has 512 bytes of EEPROM. Say that you need to save one byte of data. Let’s say you decide to only write 64K times to a cell. To count those writes you need two bytes. So each “part” will be 3 bytes.
You want to save once per second, but remember that you will only need to actually write half of the time. So one such “part” will give you 128K seconds.

512 bytes can hold about 170 such parts, so now you have 128K*170= 22282240 seconds. That is 257 days, or roughly 8.5 months.
So far for strategies described here at AVRfreaks earlier.
Now I’m brain-storming: I suppose one could get rid of those two count bytes per “part” if you could maintain a “run-time-clock” that you save only once a minute or some such. You then use the time to compute what EEPROM cell you write the state to. With this, and some margin I envision one could get much more “logging time” out of the EEPROM. (500 bytes * 100000 writes * 2 = 100,000,000 seconds of logging. That is 1157 days or 3 yars 2 months.

Is the gadget frequently turned off/on or restarted?

Is it catastrophic if the gadget start up in the wrong mode as compared to the mode it had when it went off last time, or is this only an inconvenience that one can live with if it does not happen too often?

What is the specified endurane of your switches?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You may also want to ask yourself what is the consequence if the stored mode is "out of date". Suppose you chose to cache the current mode in RAM and only commit it to EEPROM once a minute. I can't envisage what this device is where the user is furiously pushing buttons but say they'd made 3 more mode changes since the last save and then the power was removed (and again exactly how does that happen while they're furiously pushing buttons?) will the world end when the device restarts and is 3 mode changes out of date?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In my apps, I often "race" power loss as described e.g. in this thread:
https://www.avrfreaks.net/index.p...

A single byte can easily be saved. Usually with decent early warning and turning off power suckers such as a backlight there is about 100ms to play with.

Note that one must also consider external resets and watchdog.

I have a couple apps where I save the mode change upon every change. Yes, there is a 100000 limit. And an operator might rapidly make several changes. But over a long period? Probably not.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For these types of applications, we usually use a power fail circuit. This circuit monitors the "unregulated" DC power input, and warns the micro of an impending loss of power. Any state information that needs to be remembered is keep in RAM until the power fail is detected, then it's written to EEPROM.

In one method, the micro might periodically sample the unregulated voltage with the A/D converter. With this method, one must make sure that samples are taken often enough so that the power fail can be detected, and enough power is available to save your data.

Another method may use a comparator (internal or external to the MCU) to monitor the unregulated input voltage, and to generate an interrupt in the event power fail is detected.

With either method, you must have sufficient capacitance on the unregulated buss so that your micro can stay alive long enough to save your state data to EEPROM. Of course, this is only a benefit if your micro is powered down less often than your state changes.

Also, as someone else mentioned, it might be beneficial to shutoff all unnecessary functions once the power fail has been detected to reduce current draw (increase power down life) to allow the state data to be saved.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

spectrum wrote:
i have a circuit with atmega88 and 8 predefines modes of work, that can be changed acting on 2 switch buttons.
Angelo, perhaps I have misunderstood what you have said, but ... how do you get 2 switches to define 8 states when 2^2 is 4?

Cheers,

Ross

Ross McKenzie, Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

how do you get 2 switches to define 8 states when 2^2 is 4?


Let me count the ways...

-- NEXT then SET
-- UP and DOWN ("set" after no press for 1-2 seconds)
-- COUNT and SET (tap the COUNT button n times, then SET to that mode)

There are others I'm sure. Hold down the NEXT button scrolling through the mode options every .5/1 second, perhaps?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

many thanks for all the very advanced suggestions ! I found all of them very interesting.

Think is time to reveal my super-secret-strategic project.

It is just a single hobby experiment, a stupid led lamp for caravan, 6 blue leds, 3 red and 3 gren. Every group of 3 leds are in series and connected to collector of a NPN Transistor, base is driven from the cpu I/O.
Using Atmega88 and an FM driving pulse i change intensity of the colors, and can have all the color combinations (using a opaque transparent plastic cover over the leds the color is uniform).
One button allows to change between some predefined colors, White, Red, Blue, Green, Yellow, Cyan, Fuxia. The oher button, start a random variation process, and pressing same button again the current RGB combination stays fixed.

What is the purpose ? Absolutely nothing, just play with AVR and have a smooth blue light in the night while my wife put the baby to sleep.

Since i was waiting for replies, in the meantime i started with one strategy:

After a button has been pressed, i reset a timer and i wait 5 seconds, then I save the mode (0=predef., 1=RGB) (1 byte), then depending on it i save the predefined color (1 byte) or the selected RGB combination (3 words).

If one furiously change modes, i don't save at every key-press, but only after 5 seconds of "calm/no button press". And i don't save no more until a new button is pressed.

For now eeprom addresses are fixed.

What do you think ?

Angelo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi spectrum,

Not sure if this will help, but here is my library for extending eeprom writes:

https://www.avrfreaks.net/index.p...

Good luck,

Alan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi alan,

many thanks for your very useful module, now i already have something working, but i will try your solution eventually.

Angelo