Lowest power usage?

TL

According to the Propeller manual, the lowest power consumption is:

500uA per MIP, where a MIP = Freq in Mhz/4 * number of active cogs.

Does this apply if I have only one active cog, and that cog is held by a waitcnt command? Has anyone actually measured the power consumption under such conditions?

-TL

Mike Green

When a cog is waiting at either a WAITCNT or WAITPNE/PEQ instruction, it is idle just as if it were stopped. This particular factor is zero. There is still a base current draw for the system clock, any running cog counters (which can run even if the cog is idle) and some basic hub logic. I can't quote you a figure. Someone else may remember.

cgracey

We·plan to have a preliminary data sheet ready early next week.

It's true that a cog consumes about 500uA per MIPS, or 10mA at 80MHz (20 MIPS). When in a WAITCNT/WAITPEQ/WAITPNE instruction, current consumption drops to about·1/10th that. The hub takes about 3mA at 80MHz. I'm not 100% sure about these numbers, but they're in the ball park. We'll have the data out soon.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

TL

Argh. Compiler bug.

I cobbled together some wires to measure the amperage going into the demo board, and I lost continuity between the ammeter and the board partway thru the download. Someware lockup. Bother. Hafta reboot.

TL

Hmmm...

I'm measuring the current into the demoboard as 15mA at RCSLOW with the propeller idling during a waitcnt().

I 'spose a lot of that is due to power supply losses and the other stuff on the board?

Paul Baker

Here are a couple figures from the upcoming·datasheet, hope you find them useful.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Mike Green

Paul,
Whatever you've attached, it's not readable on my Mac, not even with Microsoft Word.
Mike

Paul Baker

Hmm, I can still read it. Well Mac users will need to wait until next week when I return to CA and can post the originals, though I have posted the main one on these forums before.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

cgracey

Paul, can you make a .pdf, instead?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

OzStamp

Hi

Windows wins again.... must be those magic paperclips that somebody mentioned

PDF file attached of the mA comsumption

Ronald Nollet·· Australia

Paul Baker

Thanks Ronald, the Y axis got mangled a bit, both axis should read "Current (mA)". Chip, I dont have print2pdf installed on this machine right now, I'll see what I can do about getting it added today.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Graham Stabler

http://www.cutepdf.com/Products/CutePDF/writer.asp

This is free and I found works well

Graham

Paul Baker

Thanks Graham, we have a package we use, I just don't have it on my laptop. As soon as the IT guy is in, I'll get it on my machine.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Tracy Allen

Paul, I don't understand why the Spin program running a simple REPEAT loop would exhibit twice the current of a assembly COG running a simple JMP loop. Huh, what am I missing? Shouldn't they be about the same, one COG plus the HUB?

aside: Ron, are you coming up from Oz to the ESC this year?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Mike Green

Tracy,
I'm guessing, but a cog running a simple JMP loop doesn't access the hub while a Spin REPEAT loop is constantly accessing hub memory and waiting for access to its slot for access. If hub access idles the cog, this would make up for it by cutting cog current drain during the wait for hub access, but that may not happen and the cog clock (and other logic) may be running a normal power drain while it's waiting.

Paul Baker

Mike is correct, the charge and discharge of the lines within the hub memory account for the difference in current consumption.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Tracy Allen

Here is the first diagram as a GIF:



Mike, I see your reasoning. I read the graph wrong at first, thinking ASM current was lower than Spin, but it is the other way around. (edit, ASM current IS lower than Spin current). So, it goes to low power state while waiting for the COG? That is a lot of waiting, then, as the current seems to be a factor of more than two higher for the ASM loop. Does this depend on the exactly what the Spin REPEAT loop is doing?

I'd guess that the bottom graph (HUB only?) With COG in WAIT state, would apply to either Spin or ASM.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Post Edited (Tracy Allen) : 3/28/2007 6:58:32 PM GMT

Paul Baker

ASM with no hub accessing is a lower current mode than ASM with hub accessing (or Spin which inherently has hub accesses). The lines of the hub memory must be charged/discharged in order to be accessed, this acounts for the difference in current consumption. While there is some energy savings in the wait period before the hub access, the hub access current is more than the energy saved.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Tracy Allen

Paul, Okay, so Spin current is greater than ASM current (I was looking at the graph with crooked glasses!). Does that mean that the COG does NOT go into an idle (low current) state while it waits for HUB access? I'm surprised that the HUB gate charge/discharge current would be that much. That would mean that the HUB state machine itself is pretty much idle unless a COG gives it something to do.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Paul Baker

The cog does go into idle mode, but the current consumed by the hub access is greater than the current saved in the idle mode. You can use the other graph to determine the current consumed by the hub when no hub accesses occur.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

TL

Just to get back to my original question...

The chart is in MHz. The documentation says RCSLOW clock setting is ~20kHz.
The question is how low can you go? We have a low power application which we've proto'ed with a BS2pe that uses generous NAP and SLEEP commands.

I'm wondering if we can use a prop and the variable clock instead. Terminate all cogs except one, set the clock to RCSLOW, and then do a WAITCNT.

Mike Green

As you mentioned, you would achieve a very low power consumption by running the clock with RCSLOW, having only one cog active and that would contain an assembly routine rather than a Spin program. It could spend most of its time doing a WAITCNT or, if you're waiting for an I/O event, you could use WAITPNE/EQ instead. If you look at the spec, an external clock can go down to DC, but there may not be much advantage in using an external clock from a power perspective.

rokicki

Remember that little green LED on the demo board takes some milliamps. (Mine doesn't have that LED;
I got a "low power one-off" from Parallax. )

Also, you might be able to get more efficient regulators if you're willing to wire something up yourself.

Tracy Allen

TL,

Download the data sheet and look at the figure in section 8.1 on page 21. It is a log-log plot so you can see the current at lower frequencies. At 20 khz RCslow, it shows the current with only the HUB running and WAITxxx pending at around 4 microamps, and even with a Spin REPEAT loop it is only 12 microamps. Compare that to the BS2pe, which draws about 50 microamps while in a SLEEP state, but about 20 microamps of that is the quiessent current of the LT1121 regulator. So, you can see that the Propeller can indeed operate with low current.

When the BS2pe wakes up, it draws about 17 millamps and runs in turbo mode at 8 mhz. Let's compare that one the Prop running a single COG with Spin at clkfreq=32mhz. Roughly comparable computing power? But the Propeller is consuming a meager 4 milliamps at that power point. So in a way, the Prop has a 4:1 electrical power : computing power advantage. That is further enhanced if the Propeller can drop into its RCslow mode and if the other quiessent drains are minimized.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

rokicki

It's also important to note that minor changes in the assembly language "driver" routines that spin on a command location waiting for a new command, can reduce power consumption a fair bit if they reduce the frequency of their checks (for instance, only checking once a microsecond or something rather than a tight loop).

Tracy Allen

Also, TL, even though there is no SLEEP or NAP command implemented on the Propeller, the same function can be implemented on the Prop because the clock mode can be changed on the fly. Here is a list of Spin commands that set various useful clock modes:

clkset($01, 20_000)  ' RCslow, nominal clock frequency 20khz
clkset($00, 12_000_000)  ' RCfast, nominal clock frequency 12 mhz, this is the default when the Prop  comes out of reset and bootloads a program.
clkset($28, 12_000_000)   ' RCfast is the operating clock, but now the xtal is enabled.  This mode is used while the xtal is coming up to speed.  (~10 ms for xtal)
clkset($68, 12_000_000)   ' RCfast is the operating clock, but now the both the xtal and the PLL are enabed.   This mode is used to allow both xtal and PLL up to speed. (~0.1 ms for PLL or 10 ms for xtal+pll)
clkset($2A, 5_000_000)    ' xtal1, 5mhz, the clkfreq=5 mhz directly from the xtal.
clkset($6f, 80_000_000)   ' pll16x with 5mhz xtal, clkfreq=80 mhz.

The procedure for going into SLEEP is to enable RCslow in the code just before it will monitor for breakout conditions. To come out of SLEEP, first go into RCfast (which switches over almost instantly I think), and enable the xtal and pll mode desired. Stay in RCfast for about 10 milliseconds to allow the xtal+pll to stabilize, and then complete the switch over to the time-determinant xtal+pll mode. Of course, RCfast might be fast enough for some purposes where the time determinancy is not important. That's nice, so many options! For many purposes, a heartbeat pulse from a real time clock to an input pin with WAITPEQ could calibrate the RCslow operations.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Jeff Martin

The Clock.spin object can be used for this as well; its SetClock method takes the same parameters as the _CLKMODE constant and it also takes care of the critical timing issues that Tracy mentioned.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin

· Sr. Software Engineer
· Parallax, Inc.