This post begins a series of posts on selecting the micro for your low power design. It would be hard to argue that selecting the right micro is the most important factor in designing a low power product. Selecting the wrong micro is the most expensive mistake you can make in designing a low power product and the most difficult mistake to recover from. Unfortunately, there is no right micro for all low power designs. As you will see, the specific requirements of your product should steer you to the best micro for your application.
For many years, the basis for the micro selection for a new product design was either use the same micro as on previous products or pick the latest micro from your favorite micro manufacturer. While there are many good reasons to work within the same family of micros, if low power usage has recently become a requirement for your products it may be time to evaluate other micros. Particularly for firmware intensive products it pays to do your research up front and select a micro that will allow you to have a power efficient design. You must go way past the operating and sleep mode current specs in the datasheet and research the low power modes and the peripherals a part has to make sure you can use those peripherals in the power savings modes you need to implement. Debugging your code isn’t the time to discover you can’t use a particular on-chip peripheral while the micro is sleeping.
It should go without saying but the micro selection should be a collaborative effort between the hardware and firmware engineer, with each having an equal say in the final decision. If the ultimate in power savings is your goal, it will pay to get a eval board for your choice of micros so you can run some code on it and take some current measurements. If your firmware will be written in C, this should also give you the opportunity to review the assembly language the compiler generates so you can see how efficient the compiler is. If an eval board isn’t available, an apps engineer with the micro manufacturer should be willing to compile some code for you to review.
8-bit vs 32-bit Micros
It seems like a no-brainer that an 8-bit micro would inherently use less power than a 32-bit micro. This isn’t necessarily true and for most applications just looking at the data sheet current specs won’t provide an accurate comparison. Most 8-bit micros have much lower operating and sleep mode currents than 32-bit micros of similar vintage but a 32-bit micro is likely to spend considerably more time sleeping than an 8-bit micro because it can perform its tasks much faster. In applications with complex algorithms or floating point math, a 32-bit micro may be considerably more power efficient simply because it can complete tasks in considerably fewer clock cycles than an 8-bit micro (floating point operations can take thousands of clock cycles on some 8-bit micros). Even in simpler applications, for firmware written in C the math required to calculate addresses for structures or arrays can greatly increase the power consumption of an 8-bit micro for a given task compared to a 32-bit micro.
There are also some 16-bit micros that shouldn’t be ignored, particularly if an 8-bit micro is suitable for the task and your firmware is in C. If your firmware fits in a 64KB address space then a 16-bit micro can greatly reduce the number of instructions required for calculating structure and array addresses. The main drawback to 16-bit micros in general is most of them are older architectures and may not have many of the power management features implemented in the newer generations of 8-bit and 32-bit micros.
Many of the micros released within the past 2-3 years have operating currents 1,000X to 10,000X higher than their sleep and deep sleep mode current. The upcoming generation of low power micros will increase this difference by another 10X or more. For the ultimate power savings it is crucial that the micro spend as little time executing code and the most time possible in a sleep or deep sleep mode. If your firmware will be written in C, for anything but the simplest applications 32-bit micros will have a significant advantage in executing code quickly. Consider the equation below for the current used during a specific event:
Ievent = (Timeoperating x Ioperating) + (Timesleep x Isleep)
Assume a hypothetical 8-bit micro with a 1mA operating current and 50uA sleep current and a 32-bit micro with twice the current levels (2mA and 100uA). The micro must perform a specific task that includes 100mS of sleep time while waiting on a mechanical action. Assuming the 8-bit micro takes 50mS to perform the task and the 32-bit micro is able to perform the task 4X faster than the 8-bit micro, the two equations below show the current required is cut by about one third with the 32-bit micro.
8-bit micro => (50 x 0.001) + (100 x 0.00005) = 0.055
32-bit micro => (12.5 x 0.002) + (100 x 0.0001) = 0.035
Architecture
It would be hard to say any one particular microcontroller architecture has lower power consumption than another for a given application. An architecture with single clock cycle instruction execution would use less power for a given task than a micro that requires multiple clock cycles per instruction given that everything else is equal (which is rarely the case). For applications that are very data intensive, a Harvard architecture with separate data paths for program and data memory may use less power than a micro with a shared data path for program and data memory because it can complete tasks faster. On the other hand, for an application that has very little RAM use, the shared data path architecture could be lower power than a Harvard architecture simply because there is less circuitry to power.
It would be fair to say that a more modern architecture will likely provide better control over power consumption. A more modern architecture may allow clock and power control for individual peripherals instead of the all or none approach that older micros used for power management. This can be crucial for power savings in applications that utilize a number of on-chip peripherals like timers, UARTS, DMA, etc.
Next week I will get into more details on what to look for in selecting a micro for your low power design.