Changing clock rates in program

agimuhing · 2010-09-08 18:10

Is it possible for a program to change the clock rate while running?

I'm looking for a way to make a sleep mode to reduce power usage

Kye · 2010-09-09 05:00

Please read up on the "clkset" command.

Bobb Fwed · 2010-09-09 15:38

Here is some methods I use:

PRI _rcslow_prop
'' put propeller into slowest power save speed (using internal oscilator)

  clkset(%0_0_0_00_001, 20_000)                                                 ' ~20kHz no PLL

PRI _rcfast_prop
'' put propeller into ~12Mhz (using internal oscilator)

  clkset(%0_0_0_00_000, 12_000_000)                                             ' ~12MHz no PLL
  
PRI _rc_to_slow_prop
'' put propeller into slowest power save speed (using XTAL), intended to be used after propeller was put in rcslow/rcfast mode

  clkset(%0_0_1_01_001, 20_000)                                                 ' turn on crystal, but don't use it
  waitcnt(351 + cnt)                                                            ' wait [at least] 10ms for PLL/crystal to stabilize
  clkset(%0_0_1_01_010, 5_000_000)                                              ' 5MHz no PLL 
    
PRI _rc_to_med_prop
'' put propeller into a medium speed (20MHz), intended to be used after propeller was put in rcslow/rcfast mode

  clkset(%0_1_1_01_000, 12_000_000)                                             ' turn on PLL/crystal, but don't use it
  waitcnt(120000 + cnt)                                                         ' wait 10ms for PLL/crystal to stabilize
  clkset(%0_1_1_01_101, 20_000_000)                                             ' 20MHz

PRI _rc_to_fast_prop
'' put propeller into a fast speed (80MHz), intended to be used after propeller was put in rcslow/rcfast mode

  clkset(%0_1_1_01_000, 12_000_000)                                             ' turn on PLL/crystal, but don't use it
  waitcnt(120000 + cnt)                                                         ' wait 10ms for PLL/crystal to stabilize
  clkset(%0_1_1_01_111, 80_000_000)                                             ' 80MHz

PRI _slow_prop
'' put propeller into slowest power save speed (using XTAL)

  clkset(%0_0_1_01_010, 5_000_000)                                              ' 5MHz no PLL 
    
PRI _slow_to_med_prop
'' put propeller into a medium speed (20MHz), intended to be used after propeller was put in slow mode

  clkset(%0_1_1_01_010, 5_000_000)                                              ' turn on PLL, but don't use it
  waitcnt(500 + cnt)                                                            ' wait 100us for PLL to stabilize
  clkset(%0_1_1_01_101, 20_000_000)                                             ' 20MHz

PRI _slow_to_fast_prop
'' put propeller into a fast speed (80MHz), intended to be used after propeller was put in slow mode

  clkset(%0_1_1_01_010, 5_000_000)                                              ' turn on PLL, but don't use it
  waitcnt(500 + cnt)                                                            ' wait 100us for PLL to stabilize
  clkset(%0_1_1_01_111, 80_000_000)                                             ' 80MHz

jmspaggi · 2010-09-09 17:15

Hi Bobb,

Very usefull methods! Thanks.

Is there a significant reduction of the power required when we slow down the propeller from 80 to 20 or 12?

Thanks,

JM

Bobb Fwed · 2010-09-09 18:05

Yes, for each cog it is approximately a linear scale. Half the speed is about half the power.

There are some stipulations. There is power that the propeller uses no matter at DC or 100MHz clock speed. There is power the propeller uses whether any cogs are running. It's all in the manual and/or datasheet. Look it up. Don't forget you have 5 options on the crystal 5/10/20/40/80 MHz (with a 5MHz crystal). You can get different options by using different crystals, to optimize the power consumption.

I have a battery operated project that during standby periods drops all cogs except one that runs at 5MHz. It runs (including hardware on my PCB) at about 8mA. But during normal operations it runs at 40MHz, with 6 or so cogs (some in various stages of waiting) it sucks about 60mA.
The 8mA standby is my most important time to save battery life. I have found my 3.3V regulator wastes about a third or a half of that. My next design has a far superior ULDO regulator that should have a quiecent current (according to my calculations) of about 700µA, so that will greatly reduce the power consumption during lower power mode.

Humanoido · 2010-09-09 21:59

agimuhing wrote: »

Is it possible for a program to change the clock rate while running? I'm looking for a way to make a sleep mode to reduce power usage

Agimuhing, you can get this down to less than 1ma power consumption with the right combination of everything. I have a project that will soon be released that discusses how to do this, complete with schematics. At this rate, maybe you could run the Propeller chip for years, depending on your application. It's true about the regulator being the cause of a great amount of power loss.

Humanoido

jmspaggi · 2010-09-10 04:15

Hi Bobb,

Thanks for all those details! I think I will integrate all of that in my propeller! It will be installed on my car, so I don't want it to suck all the battery when I park it for the winter...

JM

Bobb Fwed · 2010-09-10 08:17

jmspaggi wrote: »

Hi Bobb,

Thanks for all those details! I think I will integrate all of that in my propeller! It will be installed on my car, so I don't want it to suck all the battery when I park it for the winter...

JM

While off, modern cars will suck 10-fold what a propeller would. If you really care about your battery going dead, you should disconnect your battery leads, put a high-amp contact switch on it, or trickle charge it every couple months. If you have left your car for the winter before (presumably you have), and you have been fine in the past, there is some other circuitry to turn off the power to the circuit board and propeller to make it use only a few hundred pico-amps. Then with a press of a button it will fire right back up. You can even have the propeller detect that it hasn't been used in a few hours (or days) before it shuts itself down completely.

Prophead100 · 2011-05-24 17:51

Are there other issues that can occur going between speeds? This code works great but when I go to RCSLOW and the back to XTAL1+16PLL the video locks up. I can slow down to RCFAST but not slow. (note: the board has seen some abuse/rough use at my hands so it could be tired)

Bobb Fwed wrote: »

Here is some methods I use:

PRI _rcslow_prop
'' put propeller into slowest power save speed (using internal oscilator)

  clkset(%0_0_0_00_001, 20_000)                                                 ' ~20kHz no PLL

PRI _rcfast_prop
'' put propeller into ~12Mhz (using internal oscilator)

  clkset(%0_0_0_00_000, 12_000_000)                                             ' ~12MHz no PLL
  
PRI _rc_to_slow_prop
'' put propeller into slowest power save speed (using XTAL), intended to be used after propeller was put in rcslow/rcfast mode

  clkset(%0_0_1_01_001, 20_000)                                                 ' turn on crystal, but don't use it
  waitcnt(351 + cnt)                                                            ' wait [at least] 10ms for PLL/crystal to stabilize
  clkset(%0_0_1_01_010, 5_000_000)                                              ' 5MHz no PLL 
    
PRI _rc_to_med_prop
'' put propeller into a medium speed (20MHz), intended to be used after propeller was put in rcslow/rcfast mode

  clkset(%0_1_1_01_000, 12_000_000)                                             ' turn on PLL/crystal, but don't use it
  waitcnt(120000 + cnt)                                                         ' wait 10ms for PLL/crystal to stabilize
  clkset(%0_1_1_01_101, 20_000_000)                                             ' 20MHz

PRI _rc_to_fast_prop
'' put propeller into a fast speed (80MHz), intended to be used after propeller was put in rcslow/rcfast mode

  clkset(%0_1_1_01_000, 12_000_000)                                             ' turn on PLL/crystal, but don't use it
  waitcnt(120000 + cnt)                                                         ' wait 10ms for PLL/crystal to stabilize
  clkset(%0_1_1_01_111, 80_000_000)                                             ' 80MHz

PRI _slow_prop
'' put propeller into slowest power save speed (using XTAL)

  clkset(%0_0_1_01_010, 5_000_000)                                              ' 5MHz no PLL 
    
PRI _slow_to_med_prop
'' put propeller into a medium speed (20MHz), intended to be used after propeller was put in slow mode

  clkset(%0_1_1_01_010, 5_000_000)                                              ' turn on PLL, but don't use it
  waitcnt(500 + cnt)                                                            ' wait 100us for PLL to stabilize
  clkset(%0_1_1_01_101, 20_000_000)                                             ' 20MHz

PRI _slow_to_fast_prop
'' put propeller into a fast speed (80MHz), intended to be used after propeller was put in slow mode

  clkset(%0_1_1_01_010, 5_000_000)                                              ' turn on PLL, but don't use it
  waitcnt(500 + cnt)                                                            ' wait 100us for PLL to stabilize
  clkset(%0_1_1_01_111, 80_000_000)                                             ' 80MHz

kuroneko · 2011-05-24 18:13

Prophead100 wrote: »

Are there other issues that can occur going between speeds? This code works great but when I go to RCSLOW and the back to XTAL1+16PLL the video locks up.

Are you saying that you have video enabled while running RCSLOW? How do expect that to work? Then again I'd expect the (video) PLL to re-sync when you switch back. Have to run some tests to verify ...

Update: While in RCSLOW the display is gone (as expected). Switching back to 80MHz restores it.

Prophead100 · 2011-05-24 19:22

The code shuts down the cogs for video, graphics and two for motorminder objects and goes into low power until a pin goes high then restarts everything. It works with RCFAST as listed below but not RCSLOW

If Hibernate '

If the Hibernate Flag is set then Slow and Wait

Hibernate:=false ' Clear Hibernate Flag
'
Repeat p from 1 to 7 ' Stop unecessary cogs to save power
Cogstop(p)
Clock.SetClock(rcfast) ' Slow clock to RC Slow ~ 20Khz to save power

dira[0..7]~ ' Set Pins to Input for watch
Repeat while ina[7..0]==0 ' Wait for ANY bilge pin to go high
test_bilge_leds ' Run method that sets pins to output in order to uses LEDs as a heart beat
waitcnt(clkfreq+cnt) ' Pause
dira[0..7]~ ' Set Pins back to Input for watch

Clock.SetClock(xtal1 + pll16x) ' After trigger reset clock to full speed = 80 mhz
tv.start(@tv_status) ' Restart TV object
gr.start ' Restart graphic object
gr.setup(16, 12, 128, 96, display_base) ' Reset graphics and point to video memory used
mm[1].Start(Starpin, @SPeriod, @SPulseCount) ' Relaunch Launch Starboard Motor Minder
mm[0].Start(Portpin, @PPeriod, @PPulseCount) ' Relaunch Port Motor Minder

kuroneko · 2011-05-24 19:49

That's odd. For testing I grabbed a VGA demo program and added the following few lines:

waitcnt(clkfreq*5 + cnt)                              ' 5sec normal op
  clkset(%0_0_0_00_001, 20_000)                         ' RCSLOW, display disappears ...
  waitcnt(clkfreq*5 + cnt)                              ' ... for some time

  clkset(%0_1_1_01_001, 20_000)                         ' |
  waitcnt(120000 + cnt)                                 ' |
  clkset(%0_1_1_01_111, 80_000_000)                     ' switch back, display re-syncs

After that normal operations resume. Difference here is that I keep the video h/w enabled. Anyway, what's that Clock object you're using?

kuroneko · 2011-05-24 20:44

It's a bug in the Clock object. It violates the minimum SPIN waitcnt offset (#381).

if not ((clkmode < $20) and (Mode > $20))
      clkset(Mode, NewFreq)     
    else
      clkset(Mode & $78 | clkmode & $07, clkfreq)
      [COLOR="red"]waitcnt((clkfreq / 100 #> 381) + cnt)[/COLOR]
      clkset(Mode, NewFreq)

After applying the fix it works as expected (I replaced the manual settings with method calls and the transition from rcslow to PLL modes never made it in a reasonable time frame).

Prophead100 · 2011-05-25 19:16

Thanks for the fix and explaining why it works. After I changed the clock code it worked correctly but I realized I did something similar later in the code where the slowed code tried to use waitcnt(clkfrq/1000+cnt) to flash an LED when in RCSLOW. It worked correctly after I changed it to waitcnt((clkfreq/1000#> 381)+cnt). I would have never realized it. THANKS!!

kuroneko wrote: »
It's a bug in the Clock object. It violates the minimum SPIN waitcnt offset (#381).
if not ((clkmode < $20) and (Mode > $20))
      clkset(Mode, NewFreq)     
    else
      clkset(Mode & $78 | clkmode & $07, clkfreq)
      [COLOR="red"]waitcnt((clkfreq / 100 #> 381) + cnt)[/COLOR]
      clkset(Mode, NewFreq)
After applying the fix it works as expected (I replaced the manual settings with method calls and the transition from rcslow to PLL modes never made it in a reasonable time frame).

kuroneko · 2011-05-25 19:36

FWIW, I sent Jeff an email and with any luck we will have an official fix in the near future. Until then the patch will have to do.

Changing clock rates in program

Comments