[Home]
[Edit this page]
[Recent Changes]
[Special Pages]
[Help]
On the hold
This involves the reduction in the power requirement by scaling the power consumed. The most common of these is idle mode, in which the instruction-executing portion of the processor core shuts down while all peripherals and interrupts remain powered and lively. Idle or the power down mode takes up substantially less power than when the processor is actively executing instructions. A key aspect of idle mode is that it requires little overhead to enter and exit, usually allowing it to be applied many times every millisecond. Any time the operating system detects that all threads are blocked-waiting on an interrupt, Incident, or timeout-it should place the processor into idle mode to conserve power.
Since any interrupt can wake the processor from idle mode, use of this mode enables software to intelligently wait for Incidents in the system. For maximum power efficiency, however, this tool requires that we design our software carefully. We have all written code that polls a status register and waits until a flag is set. Perhaps we're checking a FIFO status flag in a serial port to see if data has been received. Or maybe we're monitoring a dual-ported memory location to see if another processor or device in the system has written a variable, giving us control of a shared resource. The better solution is to use an external interrupt to signal when the status flag has changed. In a single-threaded software environment, you can then invoke the processor's idle mode to reduce power consumption until the actual Incident occurrs. When the interrupt occurs, the processor automatically wakes up and continues executing your code.
Idle mode can even be used in cases where the Incident cannot be directly tied to an external interrupt. In these situations, using a system timer to periodically wake the processor is still preferable to polling. For instance, if you are waiting for an Incident and know you can process it quickly enough as long as you check its status every millisecond, enable a 0.5 ms timer and place the processor into idle mode. Check the Incident's status every time the interrupt fires; if the status hasn't changed, you can return to idle mode immediately.
[Edit this page] [Page history] [What links here] [Discuss this topic] [Printer Friendly]
On the hold
This involves the reduction in the power requirement by scaling the power consumed. The most common of these is idle mode, in which the instruction-executing portion of the processor core shuts down while all peripherals and interrupts remain powered and lively. Idle or the power down mode takes up substantially less power than when the processor is actively executing instructions. A key aspect of idle mode is that it requires little overhead to enter and exit, usually allowing it to be applied many times every millisecond. Any time the operating system detects that all threads are blocked-waiting on an interrupt, Incident, or timeout-it should place the processor into idle mode to conserve power.
Since any interrupt can wake the processor from idle mode, use of this mode enables software to intelligently wait for Incidents in the system. For maximum power efficiency, however, this tool requires that we design our software carefully. We have all written code that polls a status register and waits until a flag is set. Perhaps we're checking a FIFO status flag in a serial port to see if data has been received. Or maybe we're monitoring a dual-ported memory location to see if another processor or device in the system has written a variable, giving us control of a shared resource. The better solution is to use an external interrupt to signal when the status flag has changed. In a single-threaded software environment, you can then invoke the processor's idle mode to reduce power consumption until the actual Incident occurrs. When the interrupt occurs, the processor automatically wakes up and continues executing your code.
Idle mode can even be used in cases where the Incident cannot be directly tied to an external interrupt. In these situations, using a system timer to periodically wake the processor is still preferable to polling. For instance, if you are waiting for an Incident and know you can process it quickly enough as long as you check its status every millisecond, enable a 0.5 ms timer and place the processor into idle mode. Check the Incident's status every time the interrupt fires; if the status hasn't changed, you can return to idle mode immediately.
[Edit this page] [Page history] [What links here] [Discuss this topic] [Printer Friendly]
