non-volatile counter

[libor]

I have a PIC programmed to count the pulses coming from a reed-contact of a water-meter, pulses are relatively slow, 1 pulse / 1 liter. I make the PIC to sleep most of the time only wakeing up at rising edges on the input (of course using a debouncing algorythm), so it can run on a small lithium cell for several years counting the water flow in a register. I have to make the value of the counter to be non-volatile so it will not reset when the battery gets changed, I think of writing the value to the internal EEPROM each time it changes, but I have concerns whether it will overstress the EEPROM write cycle expectancy. Updating the EEPROM is a rather power hungry operation also.
What strategy (or addtional hardware) would you suggest to conserve the counter value during power outages?
Thanks, Laszlo

 

[Nigel Goodwin]

I have a PIC programmed to count the pulses coming from a reed-contact of a water-meter, pulses are relatively slow, 1 pulse / 1 liter. I make the PIC to sleep most of the time only wakeing up at rising edges on the input (of course using a debouncing algorythm), so it can run on a small lithium cell for several years counting the water flow in a register. I have to make the value of the counter to be non-volatile so it will not reset when the battery gets changed, I think of writing the value to the internal EEPROM each time it changes, but I have concerns whether it will overstress the EEPROM write cycle expectancy. Updating the EEPROM is a rather power hungry operation also.
What strategy (or addtional hardware) would you suggest to conserve the counter value during power outages?
Thanks, Laszlo

Using the internal data EEPROM seems a good idea, and it involves no extra hardware (which is also good). You can overcome both your reservations by only writing to EEPROM occasionally, if you write to EEPROM only every 100 counts you are increasing the EEPROM's life by 100 times, and reducing the power requirements by 100 times as well.

Obviously you would choose the actual interval based on your particular requirements.

 

[libor]

Thank you, I was also thinking to reduce the number of write cycles by not storing every counter movement but this would result in a cumulating counter inaccuracy at every power outage. This would be a meter-reading application for a utility company, so I have to be precise enough that no errors can not be apparently seen by a human operator (it is OK to miss some pulses during the rare battery change while it stays in the allowable error range, but a counter showing 531689 and then jumping back to 531600 after changing the battery would be disturbing even if such an error % would be allowed overall)
I was also thinking of adding a capacitor on the power pins to have it power the PIC for the short time of emergency backup and then safely shut-down the processsor. The emergency backup would be initiated when power voltage begins to fall quickly on the capacitor due to missing battery. What is you opinion of how can this be implemented and how reliable would that be? What other external parts would I need for this, or could I use the onchip brown-out detector for this somehow?

 

[Nigel Goodwin]

I was also thinking of adding a capacitor on the power pins to have it power the PIC for the short time of emergency backup and then safely shut-down the processsor. The emergency backup would be initiated when power voltage begins to fall quickly on the capacitor due to missing battery. What is you opinion of how can this be implemented and how reliable would that be? What other external parts would I need for this, or could I use the onchip brown-out detector for this somehow?

You could feed the capacitor through a diode from the battery, and monitor the battery side of the diode - when you disconnect the battery the PIC will immediately detect this, and can save the reading while the capcitor still has full charge.