Shop OBEX P1 Docs P2 Docs Learn Events
Reduce Prop Power — Parallax Forums

Reduce Prop Power

HumanoidoHumanoido Posts: 5,770
edited 2010-01-15 06:01 in Propeller 1
There was a software method (other than clock reduction or running the internal rc) to reduce the power consumed by a Propeller chip. Can anyone direct me to some sample code so I can put it into operation? I have a bunch of very power hungry props and I need to cut some power to stay afloat.

humanoido

Comments

  • BradCBradC Posts: 2,601
    edited 2010-01-13 13:33
    humanoido said...
    There was a software method (other than clock reduction or running the internal rc) to reduce the power consumed by a Propeller chip. Can anyone direct me to some sample code so I can put it into operation? I have a bunch of very power hungry props and I need to cut some power to stay afloat.

    Any of the waitxxx commands will put individual cogs into a low power idle state. The hub still consumes a bit of juice. How fast are you running them?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Life may be "too short", but it's the longest thing we ever do.
  • Miner_with_a_PICMiner_with_a_PIC Posts: 123
    edited 2010-01-13 16:01
    Its likely that your solution will have to be custom for your specific application as most propeller objects/code assume 80 MHz-pedal-to-the-metal power usage, but here is some advice:

    1) Using waitxxx commands as BradC suggested
    2) Stopping cogs
    3) Use only assembly code as spin is very slow and takes many more clock cycles to accomplish the same amount of processing...ie spend less time processing and more powered down
    4) In multi-propeller systems you could use one processor to cut power to other processors that are not needed
    5) Throttle clock speed using PLL settings at run time (I believe this is possible)
    6) In a multi-propeller system you could use one processor(perhaps an SX would be best for this) to supply a clock via an I/O pin to other propeller chips
    7) Consider voltage reduction/throttling...I believe we had a dialog in another thread related to minimum prop voltage...as voltage drops so does power consumption but speed usually takes a hit

    Post Edited (Miner_with_a_PIC) : 1/13/2010 4:07:49 PM GMT
  • HumanoidoHumanoido Posts: 5,770
    edited 2010-01-13 19:56
    Miner_with_a_PIC said...
    Its likely that your solution will have to be custom for your specific application as most propeller objects/code assume 80 MHz-pedal-to-the-metal power usage, but here is some advice:

    1) Using waitxxx commands as BradC suggested
    2) Stopping cogs
    What is the code to stop a cog?
  • TonyWaiteTonyWaite Posts: 219
    edited 2010-01-13 20:00
    COGSTOP
    T o n y

    ... at last a Spin question to which I know the answer!
  • HumanoidoHumanoido Posts: 5,770
    edited 2010-01-13 20:10
    TonyWaite: Thanks, I found some sample start stop SPIN code in the manual on page 83. This is actually what I was looking for and I see it states that the power consumption is greatly reduced. I hope the default start-up cog where the first program is loaded is zero. More reading I think......
  • HumanoidoHumanoido Posts: 5,770
    edited 2010-01-14 05:12
    I tried cogstop (5) or 1 through 7 and just get an error.
    Has anyone tried this? What is the syntax?
  • Mike GreenMike Green Posts: 23,101
    edited 2010-01-14 05:23
    cogstop(5) or using any value from 0 to 7 (other than the current cog's number). If you're getting an error, there must be something else that's wrong.

    Usually you would have your main program find its own cog # using COGID. After that, all COGNEWs would give you the number of the cog being started. This way, you'd have a list of the cogs being used and for what purpose, so you could stop the one you wanted (only). The Propeller OS I wrote a couple of years ago kept a bit mask in a byte that indicated which cogs were being used by the OS so the loader could stop any others that were running before loading a new program.

    Post Edited (Mike Green) : 1/14/2010 5:29:27 AM GMT
  • HumanoidoHumanoido Posts: 5,770
    edited 2010-01-15 05:07
    Thanks Mike. But I have a question. Based on the props boot procedure, loading a program in to RAM-only should have cog 0 working. There is no eeprom and no other program effects or routines needed in other cogs. (a simple SPIN code blinks an LED) If this is correct, then can COGSTOP 1 through 7 shut down unused cogs in the beginning of the code? This is what I'm trying to do.

    humanoido
    Startup procedure according to the Parallax Propeller Book said...
    "Upon power on, (+ 100 ms), RESn low-to-high, or software reset: 1. The Propeller chip starts its internal clock in slow mode (≈ 20 kHz), delays for 50 ms (reset delay), switches the internal clock to fast mode (≈ 12 MHz), and then loads and runs the built-in Boot Loader program in the first processor (Cog 0). 2. The Boot Loader performs one or more of the following tasks, in order: a. Detects communication from a host, such as a PC, on pins P30 and P31. If communication from a host is detected, the Boot Loader converses with the host to identify the Propeller chip and possibly download a program into Main RAM and optionally into an external 32 KB EEPROM. b. If no host communication was detected, the Boot Loader looks for an external 32 KB EEPROM (24LC256) on pins P28 and P29. If an EEPROM is detected, the entire 32 KB data image is loaded into the Propeller chip’s Main RAM. c. If no EEPROM was detected, the boot loader stops, Cog 0 is terminated, the Propeller chip goes into shutdown mode, and all I/O pins are set to inputs. 3. If either step 2a or 2b was successful in loading a program into the Main RAM, and a suspend command was not given by the host, then Cog 0 is reloaded with the built-in Spin Interpreter and the user code is run from Main RAM."
    Pub Cogstop
    cogstop (1)
    cogstop (2)
    cogstop (3)
    cogstop (4)
    cogstop (5)
    cogstop (6)
    cogstop (7)
    
  • Mike GreenMike Green Posts: 23,101
    edited 2010-01-15 05:35
    If your program is started from the bootloader, then it will be run in cog zero. If your program is started from some kind of operating system, like from an SD card or from some other EEPROM, then the loader is likely the one I wrote and it might be running in some other cog.

    Note that, if your program is started from the bootloader, then all the other cogs will already be stopped (shut down). That's one of the functions of a hardware or software reset. You don't need to do the cogstops. If your program is started using the loader I wrote, the other cogs will also already be shut down (by the loader) when your program actually begins running.
  • mctriviamctrivia Posts: 3,772
    edited 2010-01-15 05:36
    if a cog has not been started it is already shutdown.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    24 bit LCD Breakout Board now in. $24.99 has backlight driver and touch sensitive decoder.
  • HumanoidoHumanoido Posts: 5,770
    edited 2010-01-15 06:01
    What a relief!

    Thanks Mike and mctrivia.
Sign In or Register to comment.