Keeping Propeller in low-power state.

Bean

Am I correct that this code will keep a cog in low-power state forever ?

mov temp,#0 
waitpne temp,temp

Bean.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1st rule of finance...Don't lose money.
Never be ashamed of making an honest·profit.
Live within your means...Make do, or do without.
·

Mike Green

Well, mostly forever.

You're correct.

Ale

But, you cannot wake it up again unless you use coginit. To power it down, just use cogstop.

But if you want to wake it from time to time just use waitcnt with some future value and a jmp to the waitcnt. It will wake it just long enough to execute the jmp and the waitcnt and has to wait again.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU

Bean

Ale, If I use COGSTOP the pins will all become inputs (for that cog) right ?

I need the pins to keep their state.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1st rule of finance...Don't lose money.
Never be ashamed of making an honest·profit.
Live within your means...Make do, or do without.
·

Ale

Then, any of the waits can help you!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU

rokicki

BTW this trick can substantially lower the power requirements of an object that uses an assembly language cog that
polls for commands or the like. Instead of spinning furiously looking at a hub memory location asking if there is more
work to do, put in a short waitcnt (say, 100 cycles or 1000 cycles or whatever works) so that cog is *actually* almost
always idle.

Since spin code (to initiate the op) probably takes hundreds of cycles anyway to set the memory location, you're
probably not dramatically decreasing the overall performance of the program, but making a cog "mostly idle" can
cut power a lot.

Roger Lee

Bean said...
If I use COGSTOP the pins will all become inputs (for that cog) right ?

I need the pins to keep their state.

If this is true I may have to start over at the basics.
What do you mean by " inputs ( for that cog) "

Only one DIRA used by all cogs.

My understanding is a pin can be set to output by any cog. (Ignoring conflicts for now)
It will remain in that state until changed.


BTW, I get confused easily. Help me get back on track.

Roger

Phil Pilgrim (PhiPi)

Roger Lee said...
Only one DIRA used by all cogs.

Not so. Each cog has its own DIRA and OUTA. All the OUTAs are ORed together in those positions in each cog that have non-zero DIRA bits.

-Phil

Roger Lee

Thanks Phil
I'm OK now.

heater

I do so hope the Prop II has some method of "wait" for something in HUB that will put it into a low power state like waiting on a pin does. That something in HUB would be a signal from another COG(s).

The result would be like rokicki suggestion but better, no latency on waiting for a command and even lower power use.

I had thought this could be combined with locks so that you wait for your locked resource to become free and off you go.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Miner_with_a_PIC

To fix the I/O issue why not use a lock prior to exiting the cog? So here is how it would work

1) Cog X is about to exit and owns say 3 I/O pins which we want to preserve the state of post cogstop on X

2) Set a lock (lock A) >> prevents any other cogs from writing to the globals if they too are exiting or starting up (see step 3 below)

3) OR the contents Cog X's DIRA and OUTA with a two assigned RAM variables that are global

4) Clear lock A

5) Set a second lock (Lock >> the master cog will recognize this as a flag to update its DIRA and OUTA

6) Cog X waits for lock B to be cleared by master cog (preserve I/O state)

7) Cogstop X


8) The master cog recognizes that lock B is set and ORs the contents of its DIRA and OUTA with the two aforementioned globals

9) The master cog clears lock B (Cog X will use this to indicate it is free to stop)

>> The master cog does not have to be dedicated 100% to the above task and could spend most of its time either doing something or in a wait (power reduction)

Of course each routine designated for a cog must own certain I/O pins exclusively and regain control over those pins from the master should the particular routine be restarted again on another cog. This could be accomplished using the same locks as described above when the routine first loads.

All of this is alot of trouble (although once the code was written it would be reused in its most generic form) and could be spared if there existed global DIRA and OUTA registers...do these exist??

Post Edited (Miner_with_a_PIC) : 12/17/2009 5:59:56 PM GMT

rokicki

So you mean "wait for a write to this address"? That would be very useful.

heater said...
I do so hope the Prop II has some method of "wait" for something in HUB that will put it into a low power state like waiting on a pin does. That something in HUB would be a signal from another COG(s).

The result would be like rokicki suggestion but better, no latency on waiting for a command and even lower power use.

I had thought this could be combined with locks so that you wait for your locked resource to become free and off you go.

heater

Well, its not clear to me how this would/should work. It's just the idea if you have a network of COGs waiting on commands from other COGs then those waits should be low power waits like for the pins instead of polling loops as we have now.

So it could go like:

rdlong command, some_special_addres_in_hub

which does not return until sthe special address is written to. Same the other way for writes.

Or it could be mixed up with the locks some how. I'm sure Chip can think of something[noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.