Few if any decisions can have more impact on the power profile of a new design than the choice of an MCU. Choosing between new “ultra-low-power” MCUs can be confusing. While low-power is important it’s low energy that really counts—which ultimately makes the choice of an MCU application specific. Here’s what to look for:
First, there is no commonly agreed upon definition of ultra-low-power. Thanks to Ohm’s Law reducing the core voltage results in a dramatic reduction in power; processor cores running at 0.9V are becoming increasingly common. Shrinking line geometries have enabled higher device densities but at the expense of higher leakage; in low-power sensor applications, where the MCU spends most of its time in sleep mode, leakage current may contribute more to overall energy consumption than a high active current, possibly making an older 90-nm MCU a better choice than the latest 20 nm design.
Modern MCUs may have as many as 7-8 power-down modes, which can be valuable but tricky to program. You need to check which peripherals are still operating during each sleep mode. What is the wakeup time between each sleep mode and run mode? Can certain peripherals power down when they’re not needed, and how fast can they come back when they are? Can peripheral modules poll and process information without waking the CPU?
Once you’ve determined than an MCU has all the peripherals you need, that it can process the data fast enough, and its power requirements seem to be low enough—then profile your application, looking at how long it will remain in each available power mode and the state transition times. The result will be an energy profile, which should make the choice of MCUs clear.
Engineers have numerous tricks to minimize power consumption in solid-state devices: static and dynamic process temperature compensation; power gating; clock gating; reduced core voltage; voltage islands; dynamic voltage and frequency scaling; and a variety of power-down modes. Managing all these controls has gotten so complex that it’s generated a whole category of power management ICs (PMICs), some of which are customized for a particular MCU.
Almost all leading MCU vendors offer PMICs designed to work in conjunction with their processors. These PMICs are complete power management solutions that typically contain multiple independent voltage regulators that meet the supply requirements of a particular MCU family. PMICs may include linear (LDO) and switching regulators (buck/boost/or both) and controllers. They can also handle voltage sequencing, current limiting, and surge protection. Many are programmable.
As MCUs become more complex, power management is increasingly handled on-chip. This is a distinct advantage when different portions of the chip need to move quickly between numerous power-down modes. Dynamic voltage and frequency scaling is a complex function that is more easily handled on-chip.
Integration reduces component count and cost but it’s not cost free. Switching regulators generate EMI, to which analog components—and anything else powered by an analog supply rail—are sensitive. Moving power management components onto the MCU increases the chip’s power dissipation, a problem that is made worse as line width is reduced to maintain a small package size.
The best power management solution typically involves a PMIC that can handle an MCU’s overall power requirements paired with a processor that can take care of the details.
With seemingly every portable device going wireless, the need for low-power wireless design has never been greater. While there are no simple answers, there are a number of things it’s important to keep in mind.
All things being equal, the less time spent transmitting RF the less power will be required. Low-power wireless sensor nodes wake up for a few microseconds each second, poll for data, transmit it in a short burst, and go back to sleep. Protocols such as Wi-Fi (802.11) that are constantly polling for streaming data consume a lot more power than say Bluetooth (802.15.1), which can be in active, sniff, hold, or park mode.
Low-power wireless protocols such as Bluetooth Low Energy, Texas Instruments’ simpliciTI, and Microchip’s MiWi use small software stacks designed for low data rate applications such as wireless sensor nodes. They’re designed for point-to-point communications but can also work in star networks. ZigBee, while low energy, can operate in ad hoc mesh networks where a central node may be unreliable or even lacking.
The required data transfer rate can heavily impact power consumption, though the effect on overall energy consumption will depend on whether it’s more efficient for a given application to slowly feed bits to the power amplifier or to power up, burst out data, and quickly power down.
The choice of frequency has numerous consequences. The 2.4 GHz ISM band is often contested by competing Wi-Fi, Bluetooth, and ZigBee devices. The 5 GHz ISM band is less crowded and offers a lot more bandwidth, but signal strength degrades much more rapidly and readily than at lower frequencies. The “sub-GHz bands” (868 MHz in Europe and 915 MHz in the U.S.) provide much greater range, but a PCB-mounted antenna for those frequencies is too small to be efficient.
The choice of RF components and protocols is ultimately driven by the application. Whatever your application Mouser is very likely to have a component or board-level solution that meets your requirements.
Low-power and analog at first glance don’t seem to go together. Class A op-amps consume correspondingly more power as the input voltage rises; and achieving a good SNR may result in relatively high current drain.
There are various ways around the problem: First replace Class A op-amps with rail-to-rail common mode Class AB op-amps, which are biased at small currents and thus dissipate less quiescent power. In doing so be careful that you can still provide sufficient gain and output power, maximizing gain while preserving an acceptable bandwidth and slew rate.
Digitize the signal as soon as possible. You can often use digital filtering to compensate for a weak analog signal that might otherwise be too close to the noise floor.
When evaluating analog-to-digital converters (ADCs) choose one that can match the bandwidth and SNR of the signal to be quantized; if the sampling rate is more than twice the bandwidth of the signal (the Nyquist rate) then you can largely ignore quantizing error. On the other hand, oversampling can degrade your power profile, so be cautious about choosing an ADC that may have much higher resolution than you need. At the same time note that any source of noise—whether quantization error, clock jitter, or noise from a preceding preamplifier—will reduce the effective number of bits (ENOB) of resolution.
There are many types of ADCs, the two main ones being successive-approximation (SAR) and sigma-delta (or delta-sigma). SAR ADCs make a series of comparisons between an input voltage and a known reference to home in on the input value. Sigma-delta ADCs oversample the input signal and then use feedback and filtering to reduce noise and increase resolution. Generally, SAR ADCs are less expensive, lower resolution, and lower power than sigma-delta ADCs. As always, the application dictates the choice of components.
While most of the low-power buzz has centered on MCUs, memory is often the real power hog.
Flash memory is very popular for temporary data storage, both on- and off-chip. Flash is fast, with one typical 16-Mbit multi-purpose flash memory chip displaying read access times of 70-90 nsec. While the 3 μA standby current is low, this spikes to 9 mA in Write mode. Moving a lot of data to flash memory can take a big bite out of a power budget. If data is moving to and from off-chip flash, the number of wait states needed to keep memory in sync with the MCU can have a similar impact. Basically, choose an MCU with as much on-chip flash as you’re likely to need. If possible choose one that can also handle memory accesses by peripherals without waking the CPU.
SRAM is widely used for cache memory in high-speed applications. It’s fast, non-volatile—at least while powered up—and relatively low power. Asynchronous DRAM is cheaper (1T vs. 6T) and faster, but it needs to be constantly refreshed, which argues against using it much in applications where the processor will be in standby-mode most of the time.
Synchronous DRAM (SDRAM) is synchronized with the system bus and is considerably faster than traditional DRAM. DDR3-1600 SDRAM has a peak data rate of 12,800 MB/s, which makes DDR3 a popular choice for computer DIMMs. Running any memory at high speed doesn’t help with reducing power consumption, but low-power DDR (LPDDR) goes a long way toward addressing this tradeoff.
Data interfaces are often dictated by the system into which a device will be connected—automotive applications may have a CAN, LIN, FlexRay, or MOST interface; computers, USB or Ethernet; other embedded devices may communicate by I2C, UART, SPI, or a host of other protocols. The environment dictates the architecture; the power requirement is a secondary consideration.
But this needn’t always be the case. Protocols that continually poll other devices on the bus will draw far more power than those that wait for a signal or event. USB 2.0, for example, continually polls every device on the network to see if any one of them wants to send data; a USB 3.0 controller, on the other hand, waits for a device to raise an “attention needed” flag before waking up and acknowledging the request; other devices on the bus remain in a quiescent state while the host and device complete their transaction. USB 3.0 also implements link power management, which further reduces power consumption.
While a slower interface will consume less power than a faster one, that doesn’t necessarily translate to less energy. Polling aside, there will be cases where it works best for an MCU or peripheral to wake up from a power down mode; put out a quick burst of data, and go back to sleep. Would the power profile look better if you dropped the data rate, which would reduce power consumption, but took longer to transfer the data? It depends on the application.
While there are no truly ultra-low-power interfaces, look for buses that enable multiple idle states at different power levels. Scaling back the bus clock clearly saves power, but asynchronous buses like USB 3.0 are better still.