Monthly Archives: August 2013

Micro selection, part 4

This week I will discuss power savings modes in micros. You will need to thoroughly research the modes you want to use AND what the on-chip peripherals are capable of doing in these modes. On a firmware project I recently worked on, there was a single sentence with HUGE implications buried on page 358 of a 550+ page datasheet that said “During Sleep mode, all clocks to the EUSART are suspended.” Because of this, the micro was unable to be put in a sleep mode while communicating with a wireless radio module. More significantly at the product feature level, a data transmission to the device from another device in the system would not wake-up the micro, the micro would have to wake-up periodically to poll other devices to check if they had a message for it.

Low Power Modes

Modern micros provide a wide variety of power saving modes, from a simple run/idle/sleep selection to extreme control over individual circuits and on-chip peripherals. This can get very confusing because you can run into terms like “idle”, “nap”, “snooze”, “sleep”, “hibernate” and “deep sleep”. There are no standards regarding low-power states and the power levels and functionality available for a given mode name may vary widely from micro to micro.

There are several things you need to pay close attention to regarding power saving modes:

  • Make sure in the low power modes you want to implement that the on-chip peripherals you need are functional. For example, in some micros the UARTs are fully operational while the micro is sleeping, others like I mentioned above require the micro to be running for the UART to be operational. As discussed in a previous post, pay special attention to the clock chains in the micro you select. If the peripheral clock is the same as or is simply divided down from the CPU clock the micro will probably have to be running while any peripherals are functioning. You may still be able to put the micro in an “idle” mode which means it won’t be executing code but it’s internal clocks are still running and consuming power.
  • One popular family of small micros powers down its main registers and internal SRAM to achieve sub 1uA deep-sleep mode currents. On this micro, only the instruction pointer and two special registers for program state information are maintained while in deep-sleep. Other than these two registers, waking up from deep sleep isn’t much different than coming out of reset. One very important difference is any variables that the compiler caused to be automatically initialized on reset or are initialized in your reset code won’t be initialized when coming out of the deep sleep mode. Your wake-up code must handle initializing these variables and any on-chip peripherals, delaying the firmware’s response to the event that triggered the wake-up.
  • Pay close attention to what conditions bring a micro out of its low power states. In light and medium sleep modes, any internal or external interrupt will generally wake the micro. The lowest current modes usually have the fewest options for waking the micro. Some micros allow GPIO pins to be configured to wake the micro on a per-pin or per-port basis while some micros will only wake on transitions on external interrupt pins or a specific “wake” pin. For the micro mentioned earlier, the only conditions that will wake the part from deep-sleep are an alarm interrupt from its Real Time Clock or a specific external interrupt pin.
  • Micros with an on-chip voltage regulator for generating the micro core voltage will often have the core voltage on the device pins for filtering. If you select a micro that turns off or reduces its core voltage in a low-power mode, be careful with the amount of capacitance on these core voltage pins. These pins typically only require a filter capacitor so the smallest capacitor possible should be used since it will be charged and discharged every time the low-power mode is entered or exited.

This wraps up the discussion on micro selection. As you can tell, selecting the micro for your application will either enable a good low power design or set you up for failure in your power saving efforts. Unfortunately there is no “right” micro for all low power applications. For a low power design, the micro selection must be a collaborative effort between the hardware and firmware engineers working on the project. Without knowing the specifics of what the firmware needs to do, it is impossible for a hardware engineer to select the right micro for the job.

 

Micro selection, part 3

This week, I will discuss how using a micro’s on-chip peripherals can help to reduce your power consumption along with how GPIOs can help or hinder your power savings efforts.

Internal vs External Peripherals

With modern micro architectures, using internal peripherals tends to be considerably more power efficient than using external peripherals. There are a number of reasons for this:

  • The main reason is most modern micros operate with a lower core voltage so internal peripherals operate at the lower core voltage and external peripherals operate at the higher system voltage.
  • The trend towards using 2 and 3 wire peripheral interfaces like I2C and SPI to reduce pin count and package size means clocked serializer and deserializer circuits are required for external peripherals while internal peripherals have much faster parallel interfaces. These added circuits consume additional power plus the micro is also using power while waiting for data transfers with the external device to complete.
  • Passing signals through the micro’s I/O buffers to access off-chip peripherals consumes additional power. When you must use off-chip peripherals, high-speed serial SPI/I2C interfaces may be more efficient than 8 or 16 bit parallel interfaces since the I/O buffers will always consume power, not just during the data transfers. Using these serial interfaces will be even more power efficient on micros that have SPI/I2C controllers so the micro can sleep while the transfers take place. If you must use parallel interface external peripherals, the I/O pins used for data lines should be driven low when not in use to minimize power.

GPIO

There are a number of ways that GPIO can impact power consumption:

  • The I/O ports on most older micro architectures have fixed drive strength. Many modern architectures provide drive strength control on a per port or even per pin basis so the drive strength can be tailored to the circuit requirements.
  • Similarly, if your design uses more than a few GPIO outputs that change states frequently, for ultimate power savings look for a micro that supports programmable slew rates. Faster signal transitions require more power than slower ones for the same capacitive load.
  • Most micros provide options for internal pull-ups and/or pull-downs on their I/O ports. While convenient to use and a good way to reduce total parts count, these internal pull-ups tend to not be well controlled and can be as low as a few K-ohms on some micros, leading to excessive current draw.  Consider a 3.3V micro, with an internal 5K pull-up on a switch input that is normally grounded. This 5K pull-up will pull 660uA, compared to 33uA for an external 100K pull-up. Some micros also provide control of the pull-ups/pull-downs on a per port basis so all inputs on a port will have the pull-up/pull-down enabled just because one input needs it. If extreme low power is required, it’s much better to use discrete pull-up/down resistors only where needed and with as high a value resistor as can be tolerated in the circuit.
  • Unless the micro datasheet says otherwise, it’s usually best for low power usage to configure unused GPIO as outputs driving a logic low. In this configuration, the I/O pin is trying to sink current so it is using virtually no power.
  • Slowly rising or falling input signals can cause excessive power consumption and even generate noisy oscillations while the input is between the low and high input thresholds. Few micros provide Schmitt trigger inputs so an external Schmitt trigger buffer may be needed to provide fast, clean transitions to the micro. If the slow transition time is due to a weak pull-up it may be more efficient to use a stronger pull-up than to power the Schmitt trigger device.

Next week we’ll wrap up the topic of micro selection with a discussion on low-power modes. This is an area where there is no standardization so “idle mode” and “deep sleep” may have different meanings and levels of functionality even between micros from the same manufacturer.

Micro selection, part 2

Last week I presented some high level considerations for selecting a micro for low power design. In this post we’ll get into more details on how your micro selection can benefit or impact your power reduction efforts.

Program Location

For most microcontrollers, accessing on-chip RAM typically use less power than accessing on-chip Flash so you may be able to save power by executing code in RAM instead of Flash. A number of micros don’t support executing code in RAM (particularly Harvard architecture micros) and the power consumption when accessing RAM compared to Flash varies so be sure to research this in depth before counting on this power savings. This may also not be true if the Flash and RAM data busses aren’t the same width (a 16-bit path to Flash and 8-bit path to RAM for instance).

You should avoid using off-chip memory for program execution if at all possible. Besides taking more clock cycles to access off-chip memory, the power consumed by the off-chip I/O buffers and the external memory devices make off-chip memory accesses very expensive in terms of power usage.

C or Assembly Language

It is hard to beat lovingly hand crafted assembly language for efficient power usage. However, unless the energy usage for your application is so critical you are counting nanoamps, it is hard to justify the extra development time and maintenance issues associated with assembly language.

Most modern micros (even some 8-bit parts) are architected to work efficiently with compiled C code. If a micro has a very limited/fixed stack size, doesn’t support indexed memory addressing modes, can’t do arithmetic or logical operations directly on memory locations or doesn’t deal well with immediate addresses or values, it won’t efficiently execute C code and will waste considerable power because of it.

Clock Frequency

Most modern micros are implemented in a CMOS process where power consumption scales almost linearly with clock frequency. Consider again the equation for current used by a micro for performing a particular task:

Ievent = (Timeoperating x Ioperating) + (Timesleep x Isleep)

Don’t fall into the trap of thinking you can run the micro faster to use less current. Since the power scales linearly with the clock frequency, running twice as fast while using twice as much current produces the same number for the operating portion of the equation. Ironically, if the task occurs repeatedly at a specific interval, the total current used will actually increase since the sleep time increases.

A number of modern micros use a PLL to generate a higher speed clock for the micro core. Before using one of these parts, if you plan to use clock throttling as part of your power management scheme you must be aware that the PLL response time when turning it on/off or even significantly changing the clock speed can greatly increase the firmware’s response time for events that trigger the clock speed increase.

It is also important to consider the internal clock chains for anything but the simplest micros. As shown in the diagram below, the more branches on the clock tree the more control you generally have over clock speeds and enables. In simpler micros the peripheral clock is divided down from the micro core clock. Two things to keep in mind in this case are (1) the micro must be running when any peripherals are being used and (2) reducing the micro clock speed is not an option for saving power when a higher speed clock is required for a peripheral (like a high-speed UART).  Most modern micros will have at a minimum a clock for the micro core and another clock for the on-chip peripherals. This isn’t sufficient if your goal is the ultimate power savings.

Regarding UARTs, some of the more recent micros provide a fractional divider in addition to the basic baud rate divider for better accuracy at higher baud rates. The drawback to this capability is it usually requires a clock of at least 16X the desired baud rate so a 115K baud rate requires a clock of over 1.8Mhz, greatly increasing the power used by the UART. There is a family of Cortex M3 based micros that have the fractional divider that requires the 16X clock whether the fractional divider is being used or not so this can be an expensive feature power-wise even when not used.

Next week, we’ll continue looking into the detail level considerations for your microcontroller selection.

Micro selection, part 1

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.

Welcome to the CMicrotek Low Power Design Blog

We live in an era where saving energy is a topic that receives considerable attention. For design engineers, there are many different motivations for saving energy from your company being able to claim your newest gizmo has longer battery life than any of its competitors to conserving natural resources to reducing the air pollution and greenhouse gas emissions associated with generating electricity. Until recently, reducing energy usage in electronic circuit designs was primarily a concern for designers of battery power products. Today, legislative restrictions on energy usage are covering more and more types of products and the marketplace pressures for reducing energy usage are impacting nearly all types of electronic products from consumer electronics to IT equipment and even industrial and manufacturing equipment. In our “instant on” world where few things are ever really turned completely off, the energy a device uses when it is doing nothing is becoming more important than the energy it uses while operating. These so called phantom loads drive megawatts of electricity generation daily and are squarely in the sights of legislators writing energy efficiency regulations.

There are a number of ways to reduce the energy usage of your designs. Your hardware design will establish a baseline for the minimum amount of power your product consumes but for many types of products the firmware will really determine the overall power usage. Sophisticated software power management schemes that were once mainly employed in laptop computers and cell phones are being implemented in increasingly less complex products to reduce power usage. However, simply selecting the latest low power micro and implementing sophisticated power management is the “big stick” approach to power savings. There are dozens of hardware design decisions and hundreds of firmware design decisions that will either enhance or sabotage your power saving efforts. The accumulation of these smaller savings can often save more power than the big stick savings.

There are many things to consider in your designs, some will have big pay-offs in power savings but . The over-riding theme in the tips and techniques I will present is anything your design does that it doesn’t need to do is wasting energy. That sounds very obvious but many of the things we do in our designs that waste energy often are not obvious. Some of the information that will be presented can be found in other places on the Internet but newcomers to low power design may not have seen it. Many of the tips and techniques that I’ll discuss were learned through years of developing low power products. I look forward to helping with your power saving efforts.