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
(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!