Propeller Power Consumed Based on Code
Humanoido
Posts: 5,770
For those that have ammeters and can measure the real world current drawn by a Propeller chip, what is the current drawn by different programs?
Is it possible to establish a list of short programs, each with one purpose or method, and then list their corresponding power consumption?
Or is power draw simply related to the number of cogs in use? i.e. how much power is drawn by 1 cog, 2 cogs ...
Actually it appears to involve several variables. The best reference is the Propeller data sheet where it shows current is a function of frequency. (shown as PLL current as a function of VCO frequency.
http://www.parallax.com/Portals/0/Downloads/docs/prod/prop/Propeller-P8X32A-Datasheet-v1.4.0.pdf
Even specific pins have varying power draw. See 8.5 Cog and I/O Pin Relationship.
The current is also different for a WAITLOOP, ASSEMBLY, or SPIN program. So maybe we need to narrow this down to Spin language.
Also the boot sequence profile determines power draw. See 8.6
The objective is to develop some guidelines and references, so that when coding, we can choose the most effective code thereby creating the lowest power consuming devices.
(maybe it appears one chip and a few mA is relatively meaningless, but in either a battery situation or a multi-chip situation, the current consumed can become important and significant)
8.5 While there can be a 1 to 1.5 ns propagation delay in output transitions between the shortest and longest paths, the purpose of the figure is to illustrate the length of leads and their associated parasitic capacitance. This capacitance increases the amount of energy required to transition a pin’s state and therefore increases the current draw for toggling a pin. So, the current consumed by Cog 7 toggling P0 at 20 MHz will be greater than Cog 0 toggling P7 at 20 MHz. The amount of current consumed by transitioning a pin’s state is dependent on many factors including: temperature, frequency of transitions, external load, and internal load. As mentioned, the internal load is dependent upon which cog and pin are used. Internal load current for room temperature toggling of a pin at 20 MHz for a Propeller in a DIP package varies on the order of 300 μA.
Is it possible to establish a list of short programs, each with one purpose or method, and then list their corresponding power consumption?
Or is power draw simply related to the number of cogs in use? i.e. how much power is drawn by 1 cog, 2 cogs ...
Actually it appears to involve several variables. The best reference is the Propeller data sheet where it shows current is a function of frequency. (shown as PLL current as a function of VCO frequency.
http://www.parallax.com/Portals/0/Downloads/docs/prod/prop/Propeller-P8X32A-Datasheet-v1.4.0.pdf
Even specific pins have varying power draw. See 8.5 Cog and I/O Pin Relationship.
The current is also different for a WAITLOOP, ASSEMBLY, or SPIN program. So maybe we need to narrow this down to Spin language.
Also the boot sequence profile determines power draw. See 8.6
The objective is to develop some guidelines and references, so that when coding, we can choose the most effective code thereby creating the lowest power consuming devices.
(maybe it appears one chip and a few mA is relatively meaningless, but in either a battery situation or a multi-chip situation, the current consumed can become important and significant)
8.5 While there can be a 1 to 1.5 ns propagation delay in output transitions between the shortest and longest paths, the purpose of the figure is to illustrate the length of leads and their associated parasitic capacitance. This capacitance increases the amount of energy required to transition a pin’s state and therefore increases the current draw for toggling a pin. So, the current consumed by Cog 7 toggling P0 at 20 MHz will be greater than Cog 0 toggling P7 at 20 MHz. The amount of current consumed by transitioning a pin’s state is dependent on many factors including: temperature, frequency of transitions, external load, and internal load. As mentioned, the internal load is dependent upon which cog and pin are used. Internal load current for room temperature toggling of a pin at 20 MHz for a Propeller in a DIP package varies on the order of 300 μA.
Comments
Well that is an interesting point and post. I doubt that I personally will ever be concerned with it, but I am sure there are others that will find it of significant importance.
Good explanation. A+
Bruce
At the end of the day the code must firstly do its job, then you can consider how to minimize the power, reducing frequency is an obvious one, so many tasks don't really need an 80Mhz clock. You can also use waits instead of polling. As you might expect the power consumed comes down to how much the propeller is doing and how quickly, when a transistor is on then it has a low resistance hence a low I^2R loss when off the I is almost zero so the loss is small, switching is what uses power if we forget about what external devices we might be driving. All commands involve switching of internal states, the higher the clock rate the more power is consumed for a given program.
Graham
idbruce: thanks for the kind comments. It is hoped some people will benefit from these considerations.
So far we have eight main points on our list to reduce power consumption when programming Propeller chips. http://forums.parallax.com/showthread.php?124495-Fill-the-Big-Brain&p=1017511&viewfull=1#post1017511
I think there's several techniques to shut off a Cog to save power. Can anyone comment on this with more detail?
I'd like to know if super cooling the prop chip could make it run at less current draw? Some quoted specs or a shot of super freeze spray on a busy chip could determine this rather quickly.
I just did a few tests yesterday. I'm trying reduce the power used in my Panic Button project.
I'm using several QuickStart boards in the project. I'm using this code as a baseline of minimum power use of a running program.
CON _CLKMODE = RCSLOW PUB Main repeat waitcnt(cnt)I used four NiMH batteries as a power supply. The battery pack's voltage was 5.08V.
The unaltered QS board used 9.98mA when running the above program. After I removed the 220 ohm resistor (used to limit current to power LED) the current dropped to 2.65.
I then tested the current using an 80MHz clock speed.
CON _CLKMODE = XTAL1 + PLL16X _CLKFREQ = 80_000_000 PUB Main repeat waitcnt(cnt)At 80MHz the current on the QS board, without power LED, was 7.50mA.
When I commented out the waitcnt line the current increased to 16.95mA.
It's pretty obvious putting a cog into a waitcnt rather than a an active loop saves a lot of power.
I used the code below to light one of the LEDs on the QS.
CON _CLKMODE = XTAL1 + PLL16X _CLKFREQ = 80_000_000 PUB Main dira[16] := 1 outa[16] := 1 repeat waitcnt(cnt)The board used 9.83mA which is 2.33mA more than similar code that doesn't light an LED. This does not necessarily mean there was 2.33A passing through the LED. The LEDs on the QS board use a buffer to power the LEDs so the Prop itself isn't providing the current. The buffer allows the pins controlling the LEDs to be used for other purposes.
I don't know enough about the buffer used to know if the LED used 2.33A of current or some amount lower or higher.
So there are my couple of test programs. I'll probably be doing more power testing in the next couple of days and I'll post anything else I learn.
I'm pretty sure much of this information is in the data sheet but, as I've been told on the forum, the world makes a great analog simulator.
Duane
Perhaps, perhaps not. Totally pointless anyway, you will use more power cooling the thing than any you might save.
0) If a cog is not running it is consuming minimal power.
1) If a cog is running doing a cogstop on it will get you to 0)
2) If a cog is running then during any waitxxx, will reduce it's consumption to that of 0)
That's about it I think.
Heater: Thanks for the three main points of Cog power reduction. Very useful! For other cooling experiments there's a free source of dry ice coolant (from a local restaurant) that won't consume any power in the lab.
Mike: Thanks for illuminating this useful technique that can shift in and out of precise timing for asynchronous serial I/O and power savings, and for confirming Heater's information.
Here is a little chart that I made using a protoboard with a mA monitoring tap between the 3.3V power and the Prop. It is like the stuff in the data sheet, but a tabular format. It compares the current at 80MHz with that at 5MHz (with and without pllx1) and at 10MHz. Also with 1, 2 or 3 cogs running with 0, 1, 2, or 3 of them in a waitxxx state.
Simple program attached.
The waiting cogs use less current right? (Yes, I know they do.)
Should the list of "waits" be "not waiting"?
If you didn't switch things around by mistake, I'm very confused.
Duane
Edit: the data at 80MHz and 3 cogs look reversed. Not all the 80MHz is incorrect. Just looked again, all the 3 cog data looks reversed.
Tracy, The 10MHz sets for 1 and 2 cogs are still reversed.
Thanks for making the table. It's interesting how much more power the PLLs add.
Duane
Well I guess I missed the main point. Perhaps the power savings would be insignificant, but I thought the quote that Humanoido offered was quite significant.
@Humanoido - How about this experiment. A person could build a current supervisor to measure current coming into the Prop with a dedicated pin or set of pins to monitor the supervisor. And let's say the same test code (except for pin and cog usage) will be used for testing various cogs and pins. The code would measure current from point A in program execution to point B in program execution. I believe that might answer some of your questions. I don't think it would be that hard to accomplish such testing.
Bruce
EDIT: After reviewing a little further, I now see Tracy has provided a test and results
With CMOS the power consumption is usually insensitive to temperature as the switching losses are determined by the charge that flows on gate switching which in turn depends on the supply voltage and capacitance. Temperature affects how fast the charge is switched but the average supply current depends on the switching frequency and charge-per-switching, neither depend on temp.
First Clockless Processor...is Revolutionizing CPU ... based on the ARM9 core...thought to be the first commercial clockless processor ... http://search.yahoo.com/r/_ylt=A0oGdW0keSBO9iQAKCRXNyoA;_ylu=X3oDMTE0ZGMyZThqBHNlYwNzcgRwb3MDMwRjb2xvA3NrMQR2dGlkA01BUDAwNl83MQ--/SIG=13d8da85p/EXP=1310772612/**http%3a//fullproducts.org/first-clockless-processor-from-arm-is-revolutionizing-cpu-design/
Anyway it's not the clock that causes the problem. Anytime you do any logical operation transistors are turning on and off. These transitions consume power.
Now if you can make a clockless processor perhaps less transistors are transistioning unnecessarily thus saving juice.
Asynchronous CPUs have been around for a while, even though they require clocks, either on the CPU die or the SMD / DIP-4 oscillators.
P. S. the scramjet here is just an example where surgical precision in timing is required. Either way, clockless CPU is an interesting idea.
If possible, moving a Propeller chip in and out of a clock to clockless state and back again may be a beneficial technique because it can create zero power consumed envelope. However, this poses another question. Can it be accomplished? How can we disable or temporarily suspend the clock in the Propeller chip and still have functions?
Something like this?
Is the manual lacking on the description of the _CLOCKMODE ? (Page 68 Propeller Manaul 1.2).
Seems clear to me. There is no setting. It is what it is.
Off course, asking for a second opinion is always appropriate. We all do it on a daily bias.
Frequency stability of RCSLOW is a bit crazy, though. You can try shoving the whole affair in the 12VDC peltier-based pop chiller (the one you take it with you while traveling to keep your pop cold) to see the change in ALU (core) frequency as it get quite cold, to see if it's stable enough then take it out, also, to see if it has taken a hit to the point it's being forced to reboot. I would love to know if anyone have done that.
Wait a minute, I think "clockless" means something like state transitions cause "handshake propagation". Of course, the prop itself is not designed to be clockless.
So are we talking about props that set themselves to RCslow when "waiting" and setting themselves to PPL16x "active"; and this being controlled across multiple propchips by this handshake propagation? I guess the goal is for the system to notice when it can put parts to sleep, and when to wake up as needed. Even though the individual props are clocked, the handshake propagation is the clockless part. Have I got that right?
In the propforth multiprop support, a master supplies clock an external prop. If the master goes to RCslow, the slave is affected.
The master can also set the frequncy its send to the slave as clock. If the master sets the frequency to 1 Hz for the clock its generating to the slave, can the slave prop still run? Will this save significant power? This won't make the system run any faster, but running parts slower could save power without sacrificing performance, as components only run at full speed when needed.
So is there a big advantage over just having each prop set itself to RCslow?
And, I already know that the clock can't be disabled, though. The only way to reduce the consumption is to turn the fire down. It will run da*ning slow, but again, there's always trade-offs. Either we can save the juice by running very slow or sell the battery's life expectancy for speed, pretty much like the engines in the cars.