_CLOCKMODE=RCSLOW 'actual speed / power determination?

CounterRotatingProps

A search on "RCSLOW" returns an overwhelming set of results, so apologies for asking a basic, remote-telemetry question here ...

Up to this point in my Propellerness, I've not needed to mess with the clock, but now have two different new projects that do. One requires the low power of spinning down the prop as far as possible, but also needs ( the contradiction of ? ) precision timing. The other needs some sort of watch dog to wake it up. I'd prefer not to add to the external part count unless there's no other way.

The two problems:

1) When running in RCSLOW, the application needs to determine its actual rate. The Prop Man says the clock "may be 13KHz to 33KHz." Since this is the prop's fundamental baseline clock rate, I'm thinking prop code is unable to determine internally its actual running speed. RIght ?

[EDIT]: I've noted the XINPUT option, but that's more parts - maybe still the only way?

2) Re watch dogging - the system CNT, or one of the two a cog counters, do not / can not run standalone. Right? (CNT considered more below.)

Project 2 has to be fully asleep for long periods (hours to days) and then quickly (reasonably) blast off to full-tilt 80MHz. I could stop all cogs but one and have it do cascading waitcnt()s, but I'd rather put it to sleep.

Is there a way to do this without an external RTC which would whack it awake ?

Using the waitcnt() approach, I'm trying to figure out how hungry the hibernating prop will be ... If just one cog is watch dogging, then, according to the Prop Man, usage would be:

500uA per MIP, where a MIP := (Clock) Freq. in MHz / 4 * number of active cogs.
:= 500uA * 80Mhz / 4 * 1
:= 10 mA

But the Man also says that during waitcnt(), the wait hardware reduces the cogs consumption to 7/8ths of its normal power.

So, would I then take 7/8 of that 10mA, to arrive at a total of about 1.25mA total while "sleeping" ?

(Granted, a bit more would be used when the counter cascades and reloads, but I don't think that would amount to much.)

thanks for the assist!

kwinn

Don't forget that you can drop the speed from 80MHz to 5MHz before the waitcnt and back to 80MHz after. IIRC the switchover time is pretty fast.

ostrich

You could use PLL1X for a slower, precise clock (5 MHz).

CounterRotatingProps

kwinn wrote: »

... drop the speed from 80MHz to 5MHz before the waitcnt and back to 80MHz after.

ostrich wrote: »

You could use PLL1X for a slower, precise clock (5 MHz).

OK, making sure I understand ...

Internal clock ignored here:

When using an external crystal or resonator, the slowest possible clock speed is the fundamental frequency of that crystal / resonator itself. Right? So, if the Xtal is 5MHz, that's when I'd use the PLL1X for 5Hz, as you say; and PLL16X for 80 MHz, right?

Is this resulting power-draw calculation correct :

500uA / MIP, with 1 cog in waitstate @5MHz, the prop would need only a paltry 78.125 micro amps.

(500* (5/4*1 ) ) / 8 = 78.125 uA ?

kwinn

Sounds about right.

ostrich

I think I gave you some bad advice recommending PLL1X. That leaves the PLL circuit running, which draws a non-negligible amount of current according to the datasheet. You can still run at 5 MHz with the PLL disabled, but going back up to 80 MHz requires a few steps: reenabling the PLL, waiting for it to settle, and then switching over to that source. I know there's an object that handles this.

The real information is the manual (especially pgs 28-30, and 69), and the datasheet (pgs 26-28).

jmg

CounterRotatingProps wrote: »

Is this resulting power-draw calculation correct :

500uA / MIP, with 1 cog in waitstate @5MHz, the prop would need only a paltry 78.125 micro amps.

(500* (5/4*1 ) ) / 8 = 78.125 uA ?

You will need to measure this, as the XTAL osc itself has a significant current draw, I'd guess rather above 78uA

In another thread, this post
http://forums.parallax.com/discussion/comment/1410512/#Comment_1410512
has quite a nice looking WDOG element/timer. TPL5010 has 10's of nA run and ~1% precision, which is very good for 1uA/sub-uA OSC
If you need better precision waits, and lowest power, then a RTC is likely to be needed.
You can clock the Prop from a 32KHz RTC CLKOUT, for some middle ground smarts, if needed.

Tracy Allen

Here is a chart I made from using a protoboard, measuring mA current drain vs clkmode for a single cog under several conditions. For xtal1 executing a perpetual waitcnt in a single cog, I saw over 0.5 mA, far higher than the 78 microamps mentioned above. The pll1 adds another 0.5mA. Of course, the real low current champ is RCslow, less than 10 microamps. The graphs in section 8 of the Prop data sheet are scant on information about the test circuits and programs that were used to collect their data, and I'm been puzzled by the inconsistencies with my own findings. It's not hard to run these tests.



(Note: see corrected version five posts down. Pertains to current in RCSLOW mode, where it should read around 10µA not 80µA.

The XLS includes pasm versions, and, draw added by a cog counter.

I'm often running off batteries or harvested power, so excess microamps matter.

Tracy Allen

This is a pdf of the spreadsheet with pasm versions of the tests.

Note: see corrected version below. Pertains to the current when clkmode=RCFAST and the output pin is toggling.

jmg

Tracy Allen wrote: »

...The graphs in section 8 of the Prop data sheet are scant on information about the test circuits and programs that were used to collect their data, and I'm been puzzled by the inconsistencies with my own findings. It's not hard to run these tests.
I'm often running off batteries or harvested power, so excess microamps matter.

Nice tables and data

I'm curious about the Icc change on pin toggle, at low frequencies, that seems quite high ? - was the pin driving something else.
A purely digital pin, no load, no pullups, should have a

CPD power dissipation capacitance ~ Sum(CL * VCC^2 * ftog)
eg 10kHz toggle into 30pF (guess) is 2.7uA of added CPD, or 5MHz into 30pF is + 1.35mA

Tubular

There's some good info in this thread,
http://forums.parallax.com/discussion/129731/prop-limbo-how-low-power-voltage-can-it-go

Tracy Allen

@jmg, my bad. I was puzzled too about the 80µA on toggling the pin, RCslow at 11 Hz. I'm back at the shop and took out that board again and put on my spectacles. It has a 24kohm 0603 over to the neighboring pin on the bottom of the pcb, probably part of a sigma-delta experiment. That makes sense, 3.3V / 24k = 137.5 µA and at 1/2 duty cycle that comes out at about 70µA average in agreement with the observation. Thanks for flagging that and paying attention. I'll redo the table. I think the pin capacitance is only about 5pF, and the connections on the protoboard don't add much. I was careful to make the current without the scope' and counter connected. The 'scope at 1M/30pf had minimal effect, but the cable to the counter (HP5315A, 1M/40pF) was a meter of coax and had a marked effect at high frequencies.

Tracy Allen

I know you said you don't want to add external parts, however, the RCSLOW oscillator is not accurate and it has a strong temperature dependence, in contradiction with your requirement for timing accuracy. I've used a MEMS 1Hz oscillator as a time reference, Abracon ASTMK-0.001kHz-LQ-DCC-H-T. Tiny package, simply outputs a 1Hz square wave and draws about 1 microamp. The Prop can count up seconds while running on RCslow. I used that chip for a PIC data logger that turned out to need a more accurate timing than its internal RC oscillator would allow.

Tracy Allen

Here is a corrected version that treats the driven output pin correctly. In the earlier test, there had been a resistor load on the pin that made the current seem too high by about 70 microamps. In this version, the pin is unloaded.