标签: capacitance

One equation gets constantly bandied about when talking about power consumption of electronic devices. If you’re designing battery-operated ultra-low-power devices, it’s critical that you, well, ignore it. Power is proportional to junction capacitance times the voltage squared times the frequency, multiplied by the time the system is awake. I have seen engineers’ eyes light up by the V-squared term; they immediately start looking for a way to lower Vdd to get more battery life. As we’ll see in a future article, there is some benefit to dropping the power supply voltage. But this equation is irrelevant to ultra-low power systems because it measures power – watts – not current. High-performance systems live and die by power; have you seen the cooling towers on desktop CPUs? Battery-operated systems are constrained by battery capacity, which is measured in amp-hours; typically the units are milliamp hours (mAh). Power is not the issue for figuring battery lifetime. Think in terms of current. The following graph shows how one of Microchip’s nice low-power MCUs uses current as a function of clock frequency:   Note that doubling the clock rate from one to two MHz uses much less than twice the current. The reason is that the CPU is only one of the powered components. Memory and peripherals suck coulombs, too, and not all of these needs vary with clock frequency. There’s a static, constant draw, and one which is a function of frequency. It’s not hard to pick points off the graph at 3.5 volts and solve a couple of simultaneous equations, which gives: Constant current: 0.39 mA Dynamic current: 0.11 mA/MHz At one or two MHz most of the current is used by constant loads. At higher frequencies the constant draw is still significant. It’s clear that wise designers will run at the max possible clock rate to get back to sleep as quickly as possible. This is the advice given by all of the MCU vendors. And it’s wrong. Or at least naïve. Recently I showed how a battery’s internal resistance increases as it is depleted , and included the following graph, which shows the voltage delivered by the battery depending on load.     If one were to follow the advice to run as fast as possible, coming out of a sleep state means the system will be drawing perhaps a lot of current. Over time, the battery’s internal resistance will increase to a point where it may have a lot of capacity left, but cannot power a speedy current-hungry MCU. Wake up, and Vdd drops below the minimum allowed, so the processor crashes. At least one series of MCUs advertised for ultra-low power operation consumes 200 uA/MHz, maxing at 48 MHz. That’s about 10 mA just for the MCU. The battery might not be able to sustain a 10 mA load, but at 1 MHz - 200 uA - it can have plenty of life left. The moral is to wake up at a low clock frequency. Ramp it up while watching Vdd, stopping a bit above the MCU’s cutoff point. Be sure to factor in the needs of I/O you’ll be powering up. Alternatively one could apply some a priori knowledge (e.g., track consumed mAh in the code and use data such as in the graph above to estimate the operating point) to set the clock frequency. But if you take the vendors’ advice and wake up at full throttle, the useful battery lifetime may fall far short of your design goal.

One equation gets constantly bandied about when talking about power consumption of electronic devices. If you’re designing battery-operated ultra-low-power devices, it’s critical that you, well, ignore it. Power is proportional to junction capacitance times the voltage squared times the frequency, multiplied by the time the system is awake. I have seen engineers’ eyes light up by the V-squared term; they immediately start looking for a way to lower Vdd to get more battery life. As we’ll see in a future article, there is some benefit to dropping the power supply voltage. But this equation is irrelevant to ultra-low power systems because it measures power – watts – not current. High-performance systems live and die by power; have you seen the cooling towers on desktop CPUs? Battery-operated systems are constrained by battery capacity, which is measured in amp-hours; typically the units are milliamp hours (mAh). Power is not the issue for figuring battery lifetime. Think in terms of current. The following graph shows how one of Microchip’s nice low-power MCUs uses current as a function of clock frequency:   Note that doubling the clock rate from one to two MHz uses much less than twice the current. The reason is that the CPU is only one of the powered components. Memory and peripherals suck coulombs, too, and not all of these needs vary with clock frequency. There’s a static, constant draw, and one which is a function of frequency. It’s not hard to pick points off the graph at 3.5 volts and solve a couple of simultaneous equations, which gives: Constant current: 0.39 mA Dynamic current: 0.11 mA/MHz At one or two MHz most of the current is used by constant loads. At higher frequencies the constant draw is still significant. It’s clear that wise designers will run at the max possible clock rate to get back to sleep as quickly as possible. This is the advice given by all of the MCU vendors. And it’s wrong. Or at least naïve. Recently I showed how a battery’s internal resistance increases as it is depleted , and included the following graph, which shows the voltage delivered by the battery depending on load.     If one were to follow the advice to run as fast as possible, coming out of a sleep state means the system will be drawing perhaps a lot of current. Over time, the battery’s internal resistance will increase to a point where it may have a lot of capacity left, but cannot power a speedy current-hungry MCU. Wake up, and Vdd drops below the minimum allowed, so the processor crashes. At least one series of MCUs advertised for ultra-low power operation consumes 200 uA/MHz, maxing at 48 MHz. That’s about 10 mA just for the MCU. The battery might not be able to sustain a 10 mA load, but at 1 MHz - 200 uA - it can have plenty of life left. The moral is to wake up at a low clock frequency. Ramp it up while watching Vdd, stopping a bit above the MCU’s cutoff point. Be sure to factor in the needs of I/O you’ll be powering up. Alternatively one could apply some a priori knowledge (e.g., track consumed mAh in the code and use data such as in the graph above to estimate the operating point) to set the clock frequency. But if you take the vendors’ advice and wake up at full throttle, the useful battery lifetime may fall far short of your design goal.