Can we use the prop as an RTC and how long will it run on a supercap?
Cluso99
Posts: 18,069
The code for the prop in a single cog (while sleeping) would be something like...
The prop would have the xtal running so this would use some power. 1 cog would be running pasm but it would mostly be sleeping.
For those of you who have tested the prop in low power mode, what do you think?
Any ideas how long it would run for on a supercap (1F)?
It would be a cheap RTC!
loop waitcnt counter,clkfreq 'wait 1 sec
add secs,#1
mov pins,ina 'pin change to come out of sleep?
and pins,#..
tjnz pins,#loop 'no: sleep again
......
The prop would have the xtal running so this would use some power. 1 cog would be running pasm but it would mostly be sleeping.
For those of you who have tested the prop in low power mode, what do you think?
Any ideas how long it would run for on a supercap (1F)?
It would be a cheap RTC!
Comments
Hardly cheap, or small ?
RTC's start from 82c 1 off, 33c in 1000's and even a trimmed one, with few-ppm calibration, and crystal in one package, is ~$1.50 :
PCF2129AT 1 : $1.56 100 : $1.50
I think RTC code can be added to any of the standard drivers (I've got a PropTime example).
I think the hard part is adding in the loss of prime power detection and then the stop all cogs and start RCFAST...
Then, you have to figure out how to start up again when prime power is restored...
-Phil
One thing to avoid, is slow edges on any pins, if you want lowest possible Idd.
The PCF8523 hits 1.2uA toggling a pin at 32KHz, but it can generate lower CLKs, for proportionally less drain.
A WAITCNT with a 1024Hz Clk will be usable, and the Clock overhead of that would be << 1uA, Prop data says ~ 3.3uA so a total budget of 4uA could be reached with care.
You could feed the 1KHz ref ck into both the Xtal pin, and a CTR pin, if you wanted to calibrate the on-chip RC osc, for the fast-run times.
Virtually nil cost when part of an existing design. Depending on the design, the minimum I would expect is $1.03/100 for 330mF 5V5 from DigiKey #P110640ND, plus a shottky diode and resistor. However, for a low cost short duration, an electrolytic may do the job sufficiently.
I have a cog that takes the original RTC value and keeps the time. Quite similar to what Kye has done in the FAT driver. So, it can be part of the FAT driver.
Rayman: Yes, you would have to put it to sleep. And to wake it up, press a button (not reset of course).
Kye: Cannot use the waitpeq instruction because that would not work with the waitcnt which is required to keep the time accurate.
It would be possible to use a slower waitcnt that 1s. In fact, with an 80MHz xtal, IIRC ~90s is possible. Of course, this means that the pin is also only scanned every ~90s, so it would be a tradeoff between power usage / delay in seeing the interrupt (pin change). The other issue is separating the power to the prop from all the other power and ensuring no other problems.
I figure the RC oscillator is not accurate enough, so the standard xtal needs to be used. However, it may be better to slow the pll to x1.
BTW I was not considering keeping hub memory, although this could be a byproduct.
Postedit:
Perhaps it may be possible to chain the counters so that reading them later could give the elapsed time? Kuroneko... any ideas???
This way we could put the cog totally to sleep with the waitpxx, and upon wakeup calculate how much time elapsed. Wonder how much power the counters use (if chaining is possible)?
Phil: From your thread...
With a 5MHz xtal and changing to pllx1 mode, the cnt overflows ~14mins. Now if we could count that it would be helpful.
We can most likely use P28 or P29 (eeprom) to chain the counters. If both these have pullups, the other pin could be used as the input for a pushbutton to ground to signal coming out of sleep (waitpxx). This should not have any detriment to the eeprom, particularly if unpowered.
The problem is not counters - it is oscillators, and Linear pin current.
If you want to chase single-digit uA, you cannot run a 5MHz oscillator.
Something that takes >> 100uA to keep the time, is not really a RTC. That is why you first need to define your Idd
BTW I already use the DS1430C in a commercial prop design with 1225 battery.
http://forums.parallax.com/showthread.php?129731-Prop-Limbo!-how-low-(power-voltage)-can-it-go!&p=1033397&viewfull=1#post1033397
It would be interesting to find what voltage Phil's 32kHz xtal oscillator will run down to, as is or with some tweaked passives.
You can certainly use P28 and P29 to sense loss of supply and/or software reset. These were among the ideas we were discussing for a "secure cog" last May
edit: actually thinking some more, probably can't run on RCSLOW as the counters won't update fast enough to keep the xtal oscillating...
But, that probably costs more than that RTC chip...
High performance bursts, yet low long term current consumption are a couple of my main persuits. Typically, with RCSlow, and a WAITCNT state, one can get down to the 5 to 10 uA range. An issue for me, also, is keeping reasonable track of time while in the wait state.
To take care of accurate time keeping, a crystal Is required, and I have been intrigued with Phil's counter driven 32 KHz oscillator to accomplish that, but have not yet had time to experiment.
For a slightly less accurate approach I have considered -but also not yet tried- the concept of running with RTCSlow while in the WAIT state, but then on re-activation switch to high speed 80 MHz. There is nothing novel about that. The twist to add to this approach is to do a very quick calibration cycle using some RC timing (I already have the RC for on board battery voltage measurement) and measuring a slope duration with 80 MHz ticks, and then again with RCSlow ticks, letting me relate one set of counts to the other. This approach would not yield as high precision as continuous crystal operation, but a reasonable approximation, especially if it were done once per second which is my wake-up tick interval.
Just another approach that might be useful for some.
Cheers,
Peter (pjv)
Doing it on the prop would certainly be cheaper than adding more parts, if we already have a free cog and a super cap.
I have a 1F 5.5V super cap next to my Prop Pro Dev board, if somebody comes up with a nifty scheme to test.
-Phil
Yes, you are completely correct.
However, in my particular application the unit is battery powered (target is 5 years on 3 "D" cells), and power remains applied to all circuits; they are all put in low power mode.
Cheers,
Peter (pjv)
The Prop alone can go to single digit uA, the link above says 4.5uA at 16Khz RC, but it cannot sustain a crystal at that level.
(Low power & precision : Choose one )
So you need some external heartbeat, or external drive into the crystal pin.
If the RC osc can get to 4.5uA, I'd favour leaving the Xtal pins for a possible Xtal, (or resonator, which will start faster) and instead providing an external heartbeat.
A real RTC can do that for under 1uA added Icc, or you could look at something like a HEF4060 @ 32KHz, which will be cheaper than a RTC.
( under 20c )
I can't find my numbers for a HEF4060, but I can find my figures for a 4069, which was ~ 5.4uA at 3V & 32KHz Xtal, and a HEF4060 will be similar.
Perhaps a HEF4060 could give the middle ground of a"a poor mans solution".
It could wake up a dozing Prop, down as slow as 2-4 times a second.
A HC4060 can also do 32KHz oscillation at 3-5uA, but the ideal Vcc for that is a somewhat unfriendly 1.3-1.5V
At these single digit uA operating points, you are best to current feed the Logic.
One reason RTCs have an edge, is they have lower crystal amplitudes,
One approach, if the "awake" event is not frequent, is to shut down all cogs except the "sleep cog", and reload the necessary cogs from eeprom or SD card during the waking phase.
With 10M Bias, 39K Rf, and 60pF and 15pF resistors. - just a quick first guess.
Higher Rf lowers running Icc, but needs more Vcc to start.
There may be better values, with some experimenting.
Current fed with 290K from 5V, it operates 'self biasing' at ~3.1V and uses 6.6uA.
Fed from 15K, it starts at 3.4V and uses 7.6uA
Once started, it will run down to 2.1V, and draws 4.7uA there, so the main issue is the start-up..
So it is 'cheap and cheerful', but unlikely to go under 5uA, and needs a little care starting.
It would be a strange application that could tolerate the Price of a Prop + BootChip, and not tolerate ~ 50c for a proper RTC, if you were motivated to push battery life.