Running Your Embedded System at 0 MIPS



Even where activities such as wireless connectivity for IoT applications dominate current consumption, making as many processes as possible run autonomously can greatly improve battery life.

Reducing current consumption has been a major focus in the microcontroller (MCU) market. Ultra-low power MCUs now enable greatly reduced active and deep sleep current consumption. The effect of this change is obvious, with greatly improved battery life in our everyday embedded applications, and a promise of energy harvesting in the future. However, to properly leverage the current consumption specifications of modern MCUs, developers must take many considerations into account. Developers can leverage autonomous operation of peripherals in modern MCUs to achieve the low-power promises conveyed in datasheets by getting closer to operating at “0” MIPS.

For modern MCUs and wireless MCUs (WMCUs) used in power-sensitive Internet of Things (IoT) applications, current consumption while executing code has dropped significantly, achieving numbers of even 40 µA/MHz and below. With these low-power specifications, you might wonder why we need sleep modes anymore. Why not run your clock at 500 kHz to achieve a 20 µA current consumption and enable your application to run for 10 years on a battery? It’s not that simple.

Sleep currents have also significantly improved over the last few years. Across the board, we can now see current consumptions in deep-sleep modes of below 2 µA, and some sleep modes are even below 50 nA. You might think that the availability of these modes automatically makes a system low power, but that is not the case. Instead, the application’s ability to use the sleep modes is key.

Why Active Mode is Good … and Bad

The most straightforward way to use an MCU or WMCU is to have the CPU micromanage everything. For example, you can start an analog to digital conversion (ADC), put some data in a communications interface, such as a USART for transmission, read the ADC data, and make some decisions on the data, with everything controlled directly by the CPU. Direct CPU control offers ease of development, but at a cost: the MCU will find itself in active mode every time a peripheral or external event needs attention, and active mode consumes a lot of current.

These days, some datasheets specify active mode at 40 µA/MHz and below, typically at a relatively high frequency, with lower frequencies seeing higher µA/MHz numbers, resulting in higher absolute current consumption. This is because current in active mode does not scale linearly with frequency. It consists of the following two components, where the second has a smaller impact during higher frequencies of operation:

  1. The processing itself, which scales with the clock frequency
  2. A baseline current for infrastructure components such as regulators, brown-out detectors (BODs), etc.

It’s beneficial to offload as much as possible to other peripherals in the MCU, and have the CPU sleep as much as possible, to stay away from the high currents that active mode brings.

The Energy Budget

For battery-powered applications with a limited amount of available energy, it is important to know where the energy is used so that you can start optimizing it. Table 1 shows an example budget for a poorly optimized radio application that is monitoring a sensor.

The consumption is measured or estimated by averaging the current consumption of each component. If the CPU is used at a two percent duty-cycle, and is operating at 20 MHz @ 60 µA/MHz, the contribution of the CPU is 24 µA.

Note that the energy budget Table 1 shows is divided into functions. For example, the baseline sleep current includes a low-frequency oscillator and a real-time clock (RTC) to time system events and allow deep sleep. The sensor measurement contribution comes from sampling a sensor at 0.5 kHz using interrupts and deep sleep between the interrupts. This Bluetooth low energy enabled device is transmitting advertisement packages every second, which is very common for low-power Bluetooth devices. Finally, there is a contribution from non-MCU components. The MCU might not have direct control over some of these components, including power management peripherals, but the sensor that is sampled by the ADC is directly duty-cycled by the MCU in this scenario. If it wasn’t, the sensor current would completely dominate the picture. For this example, the continuous sensor current is about 390 µA, but when properly duty-cycled, it is only on for 10 µs for every ADC sample, which reduces the current drastically.

new-table

Table 1. A current consumption budget for the target application

If this wireless application was powered from a CR2032 battery, with 225 mAh capacity, a first order lifetime estimation would give 0.4 years of operation given 61.5 µA consumption. We can do better.

Improving the Situation

Let’s look at ways to reduce the MCU sensor measurement current. While this example concerns the ADC measuring an external sensor, a related example could focus on a series of different types of measurements and interactions with the external environment. In both cases, there are frequent interactions between the MCU and the external environment.

f1

Figure 1: ADC sampling using interrupts, showing that current consumption rises as number of interactions per second increases.

The most straightforward way of implementing low-power sensing is to have the CPU sleep as much as possible, waking up only to take a sample, and going back to sleep again as quickly as possible. For very low sample rates, this approach is fine, but as you can see in Figure 1, when the sampling rate or number of interactions per second increases, the current consumption of the system also increases significantly:

Many types of applications must have a high level of activity while still preserving battery life. Activity rates of more than a kHz are not unheard of, and actions are required to enable those applications in a low-power setting.

Figure 2 shows two additional approaches at sensor management. A Peripheral Reflex System / Direct Memory Access (PRS/DMA) approach takes the CPU completely out of the picture and allows the ADC sampling to be done in its entirety in deep sleep mode. Instead of an RTC waking the CPU so the CPU can start an ADC conversion, the RTC sends an event directly to the ADC, through an event system such as Silicon Labs’ PRS. The ADC autonomously starts an ADC conversion when receiving this event. When the conversion is done, the DMA, which in this case is also able to operate from deep sleep mode, fetches data from the ADC and stores it in RAM. The benefit of the PRS/DMA approach is a significant reduction in current consumption. At 1 kHz, system current goes from 58 µA to 25 µA.

Figure 2: This ADC sampling graph shows various approaches for minimizing current consumption.

Figure 2: This ADC sampling graph shows various approaches for minimizing current consumption.

An even more efficient way of driving the ADC is the PRS/Comparator (CMP) driven approach, where the RTC still triggers a conversion through the PRS system, but in this scenario, the ADC immediately does an evaluation of the sample using a comparator function, without invoking the DMA or CPU unless something interesting is found. This approach gives the ultimate energy conservation, at 3.5 µA system current at 1 kHz sampling rate.

Dynamic ADC Comparator

Using the PRS/CMP approach, the CPU will only spend time looking at a sample if necessary, and thus many samples will be thrown away. This approach is mostly useful when monitoring slowly changing signals, or when looking for specific events in a signal.

When monitoring a signal using the comparators, one approach is to measure the value of the signal, and set the comparators on either side of the last-known value of the signal. As long as the signal stays within the comparator thresholds, the system will stay in deep sleep while the ADC is monitoring the signal, and the CPU will stay asleep.

f3

Figure 3: Dynamic ADC comparator values are changed through CPU interrupt whenever the signal crosses the threshold.

If the signal changes, however, and crosses the threshold, the system will know about it and should take appropriate action. Before going back to sleep, the ADC thresholds should be reconfigured to fit around the new signal value, so the system can again go to sleep until the next signal change. Figure 3 shows an example of this technique. The circles indicate ADC samples, and the arrows indicate that whenever the CPU wakes up, it takes note of the change and reconfigures the thresholds.

With this approach, the system effectively loses some signal accuracy, as the signal can move anywhere between the thresholds between triggers. However, the gain is a significant improvement in current consumption.

If the goal of the system is to measure the dynamic value of a signal, the PRS/DMA driven approach is ideal, as it makes all data available while still providing very beneficial energy savings.

Autonomous Subsystems

The ADC example is just one of many ways sleep modes can be leveraged to significantly reduce the current consumption of an application. Modern MCUs focused on low-power applications, such as Silicon Labs’ EFM32 Gecko MCUs, have significant amounts of functionality that can operate in deep-sleep modes, allowing high levels of autonomous behavior.

For example, the Gecko MCU’s LESENSE (low-power sensing) peripheral enables fully autonomous duty-cycling sampling and evaluation of up to 16 sensors, entirely without CPU intervention, allowing high-frequency interaction with sensors while running off a battery for up to 10 years on a single charge.

Figure 4: This autonomous ADC system includes automatic sensor duty-cycling and a watchdog monitor.

Figure 4: This autonomous ADC system includes automatic sensor duty-cycling and a watchdog monitor.

In many cases, single peripherals can autonomously perform their duties, but there are also many cases where interaction is needed. In this situation, we can leverage the peripheral interconnects such as the PRS system, present in some of today’s modern MCUs. These interconnects allow multiple peripherals to be linked to autonomously perform more complex tasks.

Figure 4 shows an example of such an autonomous system, which uses a chain of events to perform its function:

  1. An RTC sends a PRS signal periodically to an ADC to start a conversion with a given time offset.
  2. The RTC signal also starts excitation of the external sensor, which will be ready by sample time.
  3. The ADC takes a sample and alerts the DMA, which fetches the sample and transfers it to RAM.
  4. A completion PRS signal from the ADC ensures the external sensor is powered down.
  5. The CPU only gets an interrupt when the buffer is full, or alternatively on ADC threshold crossing.
  6. Optionally, a PRS watchdog monitors the event loop, making sure it keeps running.

Note that the DMA can be taken out of the picture, and this setup can be used with a dynamic comparator setup for the lowest possible current consumption.

These autonomous subsystems have a couple of major benefits:

  1. Significant energy savings
  2. Deterministic sensor operation, even during times of significant CPU load

The downside is that not all MCUs support this type of operation, and you will want to think like a hardware designer when setting up the interactions. For many battery-powered applications, the benefits significantly outweigh the problems.

Results

By leveraging a variety of energy-saving techniques, the CPU is almost completely taken out of the equation when it comes to sensor measurement. For the wireless application shown in Table 1, this would reduce total average current consumption from 61.5 µA to 37.5 µA, an improvement of 39 percent, which results in a battery life increase of 64 percent, from about five months to eight months, or allowing a reduction in battery size to improve system form factor.

For a non-wireless application, the energy savings would be even more dramatic. The example in Table 1 would be improved from 29.5 µA to 5.5 µA, giving a theoretical improvement in lifetime from 10 months to 4.6 years from an energy source the size of a CR2032 battery.


HiRes-Sq-Oivind_Loe-6653-Edit_WEBØivind Loe is a senior product marketing manager responsible for Silicon Labs’ MCU portfolio. He joined Silicon Labs in 2013 following the company’s acquisition of Energy Micro, where he started working in 2008 as a digital design engineer and subsequently played a key role in the development of the EFM32 MCU architecture and product portfolio. Oivind has also served as a design manager at both Energy Micro and Silicon Labs, and now works as a marketing manager at Silicon Labs, focusing on MCU technology. He holds a master’s degree in Engineering Cybernetics from the Norwegian University of Science and Technology.

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • TwitThis