Instrumenting for power managment

Assuming the processor has a nearly zero power wait_for_interrupt instruction or state, just monitor, how long each routine is executing.

A typical small RTOS will just scan the task list after a significant event (interrupt completed or task state change) to find the highest priority runnable task and execute it. If no runnable tasks have been detected, go to sleep to wait for the next interrupt. Time stamping at the scheduler should give an estimate, how long a task is executing and how much power it is consumed.

A very low-power processor may expend a significant part of its power in peripheral operations. That can be particularly true with high speed clocks to things like SPI-connected peripherals. Different tasks may have different power drain in the same time interval.

In some applications, I've found it useful to use a high-side current monitoring chip (MAX471 or equivalent). I generally filter the output with an RC filter and sample the current as part of the internal timer tick chore. The trick is to balance the power drain from the monitoring and record-keeping against the need for the data.

Mark Borgerson

That doesn't address the power used in I/O devices, etc. It also doesn't work well in an environment where every/most task is using it's entire timeslot (i.e., this *looks* like each task is using an "equal amount" of time/"power"). Finally, it doesn't address the "work" done by each task and the "cost" of that "work" (e.g., a task that is running lots of back-to-back multiply-and-accumulates is undoubtedly putting a bigger strain on resources than one that is twiddling bits in a register).

That's not a problem -- assuming you ignore the cost of I/O's that happen to be running "in the absence" of executing code (and the cost of their IRQs).

I think that would only work for trivial tasks that use "comparable" resources. E.g., a task/process that has wired down 100M of address space is probably costing you more than one that executes in 3KB :-/

Part of the effort is to determine when it makes sense to scale back algorithms that burn power to gain speed in favor of other approaches that sacrifice speed to conserve power. Without those metrics, you can't even tell the *user* what his choices *might* be!

Exactly. Or, what's the cost of "displaying" information (vs. the cost of *preserving* it?!)

You also have tasks that can quickly (in terms of CPU cycles) do things that result (eventually) in big power consumption. For example, turning on the "vibrator" (e.g., in a phone). This can probably be done in 10 CPU clock cycles -- yet burn enough power to run the entire processor for more time than the annunciator is active!

But I suspect you are just trying to track your *total* power consumption -- not "charge" that to a particular "task"? I.e., you just want to know when you are headed for disaster and then, perhaps, implement some a priori scheme for conserving power (?).

I'm wanting to look at the costs of particular activities and adjust them dynamically to *manage* power in just the same way you would manage "execution time", "memory", "temperature", etc. in a device.

That's true. I generally look at overall power consumption for a fairly fixed set of data logging tasks. I go a bit finer grain when looking at the cost of individual tasks, such a writing a block to SD, but I'm mostly concerned about how many months an instrument will be able to log data with a particular set of lithium primary cells.

However, I suppose that a high-priority interrupt could measure power and assign the measured current to the task which it had preempted.

OK. That is a bit different. I generally work with a fixed set of tasks that allows little flexibility. About all I can decide is whether to use 1, 2 or 4KB of buffer before I write to SD.

Mark

Hi Mark,

[much elided]

Mark Borgers>>> In some applications, I've found it useful to use a high-side

Yes. Sorry, I should have elaborated on the different nature of the application :-/

E.g., in your case, you're pretty much pared down to doing the *least* that you can -- while still satisfying your overall design goals. So, there's nothing to "throw away" when power gets in short supply.

And, power reserves are a monotonically decreasing function; you *know* you'll have less power available at EVERY time in the future than you have now.

I'm not sure whether just taking a snapshot of the *current* (taking your comment literally) would work. I.e., that assumes it has been constant over the past quantum. I think you have to integrate *power* consumed instead of just looking at instantaneous current.

Also, assuming that the power consumed "now" is chargeable to the "recent task" can be misleading. Especially in synchronous environments. E.g., task A starts some (hardware) process/device, then blocks. Power consumption changes *while* task B (which follows task A) executes and B is charged with that -- even though the power consumed was a result of A's actions! I.e., if B is unlucky enough to get stuck following A all/most of the time, then B is wrongly accused of using more power than it actually *did*.

(the same problem happens in *time* when A sets up an ISR that occurs *during* B's time slot -- B pays the price for A's actions by losing the CPU cycles that A's ISR consumed)

Understood. I'm trying to come up with metrics that can let the "application set" tune itself to better use available power;

*and*, so that "it" can better inform the user of the costs of particular user actions.

E.g., if your cell phone told you that "listening to music (MP3's)" is costing you W minutes of talk time per minute of music "consumed" or X minutes of standby time *and* you currently only have Y/Z minutes of talk/standby time ON RESERVE, then you could better manage your phone usage -- ESPECIALLY IF RECHARGING IS NOT PRESENTLY AN OPTION!

I haven't found anything that addresses this sort of issue to date. Instead, any metrics tend to look at the *overall* power consumption and, at best, say (in effect) "if you keep using the device in the same way that you have *been* using the device recently, then the best estimate is that you have X reserves available". This is essentially useless information as it doesn't let the user know how to *change* his usage pattern to alter those reserves -- nor the *range* of possible reserves that he might attain best'/worst case *if* he altered his usage patterns! (e.g., if drastically altering usage only results in a tiny incremental advance in reserves, then the user might as well keep doing what he is doing!)

Well, that's ALMOST true. However, the polarization effects on chemical batteries can result in short-term increases in cell resistance that disappear after a resting period. I've had that result in systems that reset when writing to SD, then re-awaken and run OK a while later. That requires good brown-out detection and hysteresis in the reset generator.

That's the reason that I usually have a pretty long time constant in the RC filter on the current sensor.

I guess you would have to not only capture which task is running, but the state of various peripherals. Then the monitoring task is starting to consume a significant percentage of the current in shorter tasks.

This is definitely a more complex problem than those I have faced. Good Luck.

Mark Borgerson

[much elided]

Yes. But that assumes you can "power off" and then power back on. I had assumed your devices got turned on, sealed up, thrown overboard and then fished out sometime later (possibly *after* the batteries had been exhausted).

In my case, the device can be powered off, recharged, etc. so making decisions about "The Future" has one extra unknown (i.e., when/if/how-much power will be reintroduced to the battery)

But, you don't "reset" that at the start of the next integration period (?) -- presumably, you could "do the math" to eliminate the need for this?

I was thinking more along the lines of integrating the charge pulses coming out of the inverter(s) and using that to reflect the near-instantaneous demands of the system (assuming you chop at a frequency >> the jiffy)

Yes. Though you can decide that certain tasks can be efffectively approximated by "Kt" (you can determine this a priori by looking at how they behave "on the bench").

The big problem is the power hungry tasks -- those that intentionally use peripherals that draw lots of power *or* those that, by their nature, *need* lots of resources to achieve their goals.

E.g., to fall back on the cell phone analogy, I suspect you could track power in the radio and backlight and get a good first-order handle on overall consumption. So, showing the user the (relative?) costs of "talking" vs. "looking at the screen" vs. "waiting for a call" shouldn't be difficult.

I suspect this will become more commonplace as I can't see battery technology progressing much faster than our demands for features, etc. Decades ago, 100% CMOS processors were few and far between (1802, 8085 and perhaps 6502 variants?). Then "sleep modes" on processors (often crudely timer driven instead of any particular heuristics). Sooner or later, you will be able to query the core itself for an accounting of its recent power requirements...

What figure are you going to report to the user in this example ?

The time remaining at minimum cellular transmitter power ?

The time remaining at maximum cellular transmitter power ?

The time remaining at most recent phone contact transmitter power ?

After all, a user movement of less than one meter would make all alternatives viable. Of course, telling the worst case time could require using the full handset transmitter power, while the marketing department would expect you to tell the time available, when climbing the cellular tower :-).

I don't think actual numbers are as important as something that gives the user a way to modify his behavior to *meaningfully* alter those results. Even a range of figures is informative if the user can see how changes in his behavior affect them.

We, as users, *want* to use these devices. More than we *need* to use them. But, without meaningful feedback on the consequences of our usage patterns, we have no way of ensuring the device's availability when we *really* "need" it.

For example, when I travel, I carry one or two portable GPS's with me (a "large screen" unit that acts as an electronic map and a smaller "pocket size" for walking/hiking). It's fun to turn them on *while* flying -- both to get an idea as to where you currently are located (since you can rarely identify landmarks from 35,000 feet!), how soon you will "arrive" as well as the novelty factor: "current speed 550 MPH"

However, I have to balance my desire to "play" with them (flights are boring; I only carry one book on the plane and that will typically only occupy me for 3 hours before "FINI") with my need for them to be operational when I touch down!

What is the cost for me to use them in flight? Does blanking the screen save me anything? How much? Will I have enough battery left when I land to reach my ultimate destination? If I can see how my behavior drives that reserve time up or down, then I can make a value judgement on the worth of "playing" with them instead of reading *another* book, etc.

Marketing would want to sell a small cable to let the user connect directly to the tower! :>

I suspect using the phone as an MP3 player (with screen NOT blanked) is a sizable fraction of "typical" power usage "as a phone" (screen blanked). Dunno. I never use any of my cell phones *as* phones! :>

We have some of the same interests---although with slightly different goals. On a recent cruise from Ketchikan AK to Bellingham WA, I often had 3 GPS units running: a Garmin GPS76C, an IPAD, and a custom-built logger that saved positions only once per minute. (On an 8-knot trawler yacht, that's often enough for a good cruise track.) The GPS76C would last about

10 hours on 2 AA alkaline cells. The IPAD lasted more than 8 hours on a charge, while displaying the position on Navionics nautical charts. The custom logger lasted about a week on 4 D Cells. It is the last system that I need to optimize---but the 60mA as the GPS gets lock is a limiting factor.

Get yourself one of the e-book readers that will download free books from your local library. I got one of the Kobo readers for about $130. It will last several weeks on a charge and hold enough books for many months of reading.

I exchange text messages with the kids and make about 2 calls a month. I've got an SD card of music on the phone, but haven't yet gotten headphones with the smaller jack. Just sitting idle at home (1/4mi from a cell tower), the phone needs charging about once every 10 days.

Mark Borgerson

My point is that you aren't given any/enough information (by the device or its manufacturer) to intelligently manage your usage of those devices. *And*, if you really

*need* them (which is the case with many of the devices that I "use" -- when not in use, they sit, ignored, in a desk drawer), you don't want to take the *risk* of experimenting!

Sort of like wondering where "empty" ACTUALLY is on your car's gas gauge... I'm too lazy to throw a gallon of gas in a can in the trunk and "drive it dry" just to satisfy my curiosity :>

I have never been able to get accustomed to reading anything "of length" in any form other than paper -- much to my dismay. :< Nowadays with the 1,000 page datasheets for many devices, this is *really* frustrating as I end up going through a ream of paper *just* so I can take the sheets into another room and *thumb* through them.

I have cognitive problems *listening* to read text so that option is also "out". Means I am pretty much stuck with paper (which, I suspect, will be around at least as long as *I* am likely to live! :> )

Thankfully, my music listening hasn't clinged (clung?) to

*vinyl*! :>

Besides, after three hours of reading, I want to do something

*else* -- not read Yet Another Book :-/ (Next trip I'll load some movies onto a PDA or PSP and keep that as a distraction)

I dislike the telephone, in general (i.e., don't even answer the land line at home), prefering email, instead. At one point, I thought about this philosophically and came to the realization that The Phone exists for the convenience of the *caller* (this is incredibly obvious once you think about it) often at the INconvenience of the "callee". (i.e., just because *you* want to talk to me *now* doesn't mean *I* want to talk to *you* now! ;-)

Email is far more egalitarian. I write when *I* want to; you reply when *you* want to! (it also has the wonderful side-effect of documenting conversations)

I use mine primarily as a tiny WiFi "terminal". Screen is a bit too small to be useful -- I prefer a 4" screen for *real* utility -- but the tradeoff of overall size is a win in many cases (I'm always afraid of sitting on my PDA and cracking the screen whereas the phone fits nicely in a *front* pocket).

I have an assortment of MP3/media players that I rotate through on a regular basis depending on my needs, etc. E.g., on daily walks, I've taken to carrying a little Sony "Network Walkman" (no idea where they came up with that name) as it is relatively small, robust and easily operated "without eyes" (except, of course, for the clock :-/ ). I recently inherited a Zune but can't see a real use for something that holds more than one movie (as does my 60G iPod-w-video).

All are more useful as examples of user interfaces -- what's good vs. what's bad (hint: iPod sucks!)