Electronic – Inherent exploitability and power state machines

computer-architectureefficiencymobilepower supply

I'm working on understanding power state machines in regard to mobile computing devices. Most of the information on this subject seems to stem from this article. It's not particularly important to the question, but I figured I would provide some context of where my information was coming from.

enter image description here
Here's the question: With a power-state machine, the Ttr (total transition time) can be calculated as: Ttr=Ton,off + Toff,on where Ton,off is the time it takes to transition from on to a lesser power state.

To calculate the the total power consumed during a transition the formula:
Ptr = (Ton,off * Pon,off +Toff,on * Poff,on)/Ttr is used.

My first bit of confusion has to do with the Pon,off, Poff,on variables. I am assuming these are power on and off states accordingly, so for run->idle->run the power states would be 400 and 50?

The next part has to do with inherent exploitability. Given an idle period, using this formula will calculate the energy you will save: Es(T-idle) = (T-idle-Ttr)(Pon-Poff)+Ttr(Pon-Ptr)

So, using this formula for an idle time of 1000 micro seconds I got: Es(1000) = (1000-20)(400-50)+20(400-225). – The result of this if over 3.5 million mw, which is obviously absurd. Where am I going wrong here? It's difficult to find information on this subject outside of the paper I referenced, besides other sites – referencing that paper. Thanks!

Best Answer

I believe the OP's OQ has been answered in comments.

I cannot add comments yet, but would like to add a few details about state-machines for anyone that links to this.

This is the minimal (pseudo)code for a running micro-controller:

[Power on]
1: Initialize(); //Clock and other hardware
2: Goto 4; //void Main()
3: "Crash"/unhandled Exception/activate watchdog timer/undefined
4: NOP; //NoOPeration = do nothing; uploaded user code goes here
5: Goto 4; //User code typically runs in an infinite loop
6: Goto 3; //void Main() does not typically ever return

As long as the infinite loop is sustained, the controller is either running user code or "idle". The article the OP linked shows the idle bubble sub-texted with "wait for interrupt". In my experience with micro-controllers, there is no "state" for idle; idle just happens when there is nothing else to do.

The user code may, at any time, detect that it has nothing to do and tell the processor to wait for interrupts and/or go low-power.

WFI(); //Block execution until an interrupt fires

and/or

LOW_POWER_REGISTER &= 0x01; //Physically power-down peripherals and reduce clock speeds

If desired, the user code may enter a custom or specific low-power mode and then, also, WFI(). WFI() has a very high chance of saving power since it suspends the user code, but may also invoke one or more integrated hardware power-saving features.

The interrupt that wakes the controller will be responsible for restoring any power states that leaving WFI() does not automatically restore. Typically, WFI() is used to pause until one or more input pins change. A watched "pin" can be actual solder terminal, or attached, internally, to peripherals like a timer.

I could not define "inherent exploitability," even with Google's help. The real issue with power state transfers taking too long is data loss. If asynchronously-received data is what wakes up the controller, a portion of the packet is lost before the controller is even awake. Sending a do-nothing "wake up" byte from the host before the actual data is light-weight and ensures that any receivers are awake and ready to receive.

Related Topic