I know this pretty much defeats the purpose of a RTC, but does it actually need a clock signal?

I've been looking for ways to implement a battery backup system in my project so I can store data between on and off cycles without having to write it to eeprom all the time (which I always forget to save before reprogramming!!) So far a simple RTC seems to be easiest and smartest way to do it.

What I'm thinking is since I'm more after this for the battery backed RAM than the current time I could use the clock part more as a run time counter by supplying a clock signal only when I want to increment time. The clock signal to the RTC will be then supplied by a microcontroller PWM or oscillator. Everything I've read seems to indicate this is possible with a few changes to registers... I'm assuming since you can turn off the oscillator input on some RTCs you have to be able to turn it back on also which would mean the clock source is just for timekeeping.

At the moment I'm considering the MCP7940... datasheet here --> http://www.microchip.com/mymicrochip/filehandler.aspx?ddocname=en557502

 

Or use an output pin from the uC to stop the oscillator by grounding pin X1 through a diode. That way you get crystal accuracy when running.

ak

 

Or use an output pin from the uC to stop the oscillator by grounding pin X1 through a diode. That way you get crystal accuracy when running.

ak

Well it could work but its "dirty"?

Theres usually a register switch for this and also many of these IC have a LF output.

 

I know this pretty much defeats the purpose of a RTC, but does it actually need a clock signal?

I've been looking for ways to implement a battery backup system in my project so I can store data between on and off cycles without having to write it to eeprom all the time (which I always forget to save before reprogramming!!) So far a simple RTC seems to be easiest and smartest way to do it.

What I'm thinking is since I'm more after this for the battery backed RAM than the current time I could use the clock part more as a run time counter by supplying a clock signal only when I want to increment time. The clock signal to the RTC will be then supplied by a microcontroller PWM or oscillator. Everything I've read seems to indicate this is possible with a few changes to registers... I'm assuming since you can turn off the oscillator input on some RTCs you have to be able to turn it back on also which would mean the clock source is just for timekeeping.

At the moment I'm considering the MCP7940... datasheet here --> http://www.microchip.com/mymicrochip/filehandler.aspx?ddocname=en557502

Coincidentally, I am currently working with EERAM and you may want to consider that route. These are I2C static RAM chips with an EEPROM shadow. In the simplest implementation, the RAM is automatically backed up to EEPROM upon power off. Only one capacitor (apart from the normal bypass cap) is needed. They are about $1. No RTC, no battery. You only need to write to, and read from, static RAM - just as you have to do with an RTC.

 

Coincidentally, I am currently working with EERAM and you may want to consider that route. These are I2C static RAM chips with an EEPROM shadow. In the simplest implementation, the RAM is automatically backed up to EEPROM upon power off. Only one capacitor (apart from the normal bypass cap) is needed. They are about $1. No RTC, no battery. You only need to write to, and read from, static RAM - just as you have to do with an RTC.

Thanks a million for the suggestion. I guess I just never heard of that before... it really solves a whole mess of problems, is insanely simple, and even saves the data for good in the event you need to retrieve it from a cooked project (as long at the EERAM survives).

 

I've been looking for ways to implement a battery backup system in my project so I can store data between on and off cycles without having to write it to eeprom all the time (which I always forget to save before reprogramming!!) So far a simple RTC seems to be easiest and smartest way to do it.

Is there a problem with writing to EEPROM or just forgetting to preserve it when reprogramming?

If the latter some external EEPROM may be the simplest/cheapest solution.

The only thing cheaper would be changing the link script to avoid overwriting the data when reprogramming.

 

Is there a problem with writing to EEPROM or just forgetting to preserve it when reprogramming?

If the latter some external EEPROM may be the simplest/cheapest solution.

The only thing cheaper would be changing the link script to avoid overwriting the data when reprogramming.

I really need to sit down and do some figuring. I haven't yet tried to calculate just how long it would take before the number of writes to EEPROM would exceed the number of writes the datasheet claims. The write cycle counts could be anywhere from zero for a week or two all the way up to 100 or more in a single day depending on what I'm doing. I like the EERAM idea the best. The microcontroller is going to be constantly powered, but in sleep mode when not needed. I'm more or less after a way to ensure if the battery goes dead while it's not being used that the data will still be valid after a charge.

 

Probably you are better off with a serial flash and a small battery like AAA NiMH and a booster.
Maybe a supercapacitor the 0.1F kinds are cheap.

You could mitigate the wearout to the battery (more easy to buy and replace).
A supercapacitor also will go nuts after some years.

http://www.sramsun.com/list-234-1.html
ipsilog serial SRAM standby current is some 10s uA

You could look at lithium backup battery, only use it when power is lost, possibly keep track the usage.

If you potentially write to EEPROM 1000 times a day you get a few years at best then youll see bit errors. Like your typical laptop...

EERAM capacity typically is rather small.

 

Thanks a million for the suggestion. I guess I just never heard of that before... it really solves a whole mess of problems, is insanely simple, and even saves the data for good in the event you need to retrieve it from a cooked project (as long at the EERAM survives).

You’re most welcome and I think it is really good that you are receiving suggestions with a number approaches - kind of what the board is all about .

I would reiterate the serial EERAM solution. With regard to “EERAM capacity typically is rather small”, the only serial EERAM chips that I am aware of come from Microchip and there are only two capacities, 4K (512X8) and 16K (2KX8) - I have both of them on a board in front of me.

Each comes in at ~$1 US

I suppose those capacities are not particularly large, but, you didn’t mention in your original post what capacity you need for your purpose. You did, however, say that you were considering the MCP7940. Since that RTC has only 64-byte SRAM, I strongly suspect that either EERAM chip would suffice.

To me, the idea would be to get rid of any batteries and related circuitry if you could – why bother if you don’t need to use them?

Microchip has a comparison table http://www.microchip.com/design-centers/memory/serial-eeram that includes some of the other possibilities and it might be useful to you.

Not on that table and not previously mentioned in the thread is FRAM (Ferroelectric RAM) . I have not yet used these but they look to be, in general, a little more expensive than EERAM but can still be relatively inexpensive (e.g.,this one).

This small board from Adafruit looks like a really easy implementation. But, again, I have not yet tried them and have only been reading about them.

Please do let us know what you end up doing and how it works out.

 

Honestly I was more or less hoping the 64 bytes on MCP7940 would be enough in the beginning. Even at 4k the EERAM is more than enough.

Pretty much what needs to happen is the data will be written to RAM before the microcontroller goes to sleep, then when it wakes back up it will read the data back from RAM, compare the two, and from there I have yet to figure out what I want to do. The important thing is that the data will be saved in some way it will survive until the next time the microcontroller wakes up... or in the event power was disrupted while sleeping the data will still be good. If it looses power or screws up while awake, then I have a bigger problem on my hands.

This is going to be an evolving project with more microcontrollers added over time as long as the device I'm building them for holds up. The extra unused memory of the EERAM will be better than running out. At the moment I'm up to 16 bytes give or take a few depending on if I have the micrcontroller store them in it's EEPROM since they won't change but maybe once a year. At least 10 so far will be written and read back every time before and after the microcontroller enters sleep mode.

I still have some bugs to work out with what I have built so far so it may be a while, but I will write something up when I get it working like I want and am ready to go the next step.

Thanks to all for your suggestions.

 

Loss of power while awake may be fast more likely then asleep since presumably you are drawing more power. As EEPROM writes take some time you need to provide secondary power to bridge the gap between loss of power and write complete.

Best do that up front because you may want to separate power to different areas.