MCU-Based Systems Profit from a User-Oriented Design Perspective



Designing for ultra-portable, wearable devices is driving a new approach to MCU selection and system design.

Instead of the conventional method of defining the set of functions and capabilities that will serve as the project’s top-level drivers, the new approach — pioneered by Apple and validated by other leading-edge companies — begins by defining the user experience that the product should produce.

Wearables are not the only devices that can profit from a user-oriented approach to design. Virtually any product can benefit. However, value is greatest in products that are in constant use and where an intimate user-dependency is established — where the human-machine interface is vital to the product’s acceptance.

Product categories include all wearable devices, of course, but also what might be considered ultra-portables such as health monitors and smartphones.

The wearables market is also driving an even stronger requirement for energy efficiency because the small batteries have a heavy duty cycle and the user expectation is that a charge will last for a long time. Wearables depend on the Internet of Things (IoT) to create their value; and the IoT, in turn, pushes other energy-consumption scenarios such as devices placed in remote locations that require batteries to operate for months or even years on a single charge.

MCU architectures are evolving to meet these challenges.

MCU vendors now offer architectures with multiple-energy modes tailored to the system’s activity level. Smart peripherals that process queued information without step-by-step directions from the MCU have now been joined by autonomous peripherals that require even less interaction with the MCU — they communicate directly with DMA. Also becoming more common are hardware-assist engines, such as floating-point units (FPUs) for executing algorithms that need intensive number-crunching performance.

As the number of energy-operating states, peripherals, and instruction sets proliferate, the number of permutations for a specific design rises exponentially.

Sometimes the best MCU choice for energy efficiency can be counterintuitive.

Baseline considerations

Begin with the desired user experience. This should be a rigorous exercise that considers every aspect of the user’s interaction with the product. There are, however, three basic categories from an electronic- design perspective: Easy setup; intuitive operation; and minimal maintenance (which includes extended battery life).

The desired user experience sets the parameters for a concept familiar to design engineers: The use case. There are three main elements: What tasks the device will perform; the resources needed to perform them; and the conditions under which it will operate.

In order to move to the next level of granularity, it is necessary — for further discussion in this article — to identify a specific type of device. For wearables, the use case includes details about the types of data the device will collect, how it will interact with users and other devices, its anticipated operating environment (temperature, water resistance, impact resistance, and more), its operational modes (data collection and analysis, user interactions, communication), and how frequently it synchronizes with other devices. Once these specifics are known, the design team can begin to assemble a bill of materials (BOM) and an energy budget (see Table 1 for a list of energy budget drivers).

Simplified list of energy budget drivers
Type of data Biometric
Environmental
Digital
Frequency of interaction with user Seconds
Minutes
Days
Months
Frequency of interaction with external world
Also, duration of interactions
Seconds
Minutes
Days
Months
How device interacts with user Remote interface
   Keypad
   Touchscreen
   Voice
Integrated data display
All or some of the above
Over-the-air communications Bluetooth
Wi-Fi
ZigBee
Sub-GHz
Other
Synchronization frequency with other devices
Also, duration of interactions
Seconds
Minutes
Days
Months

Table 1: Parameters for creating a use case for devices that use biometric data.

Energy-demand profiles

The use case provides a series of energy-demand profiles that depend on whether the user is interacting with the device; whether the device is acting autonomously (collecting data, for example); and whether it is in various levels of shut-down. This information is then translated into demand cycles for the system — and particularly the MCU.

Of special interest in this phase of the exercise are the algorithms used to translate physical data into information that can be used by the MCU to make calculations and decisions that lead to accurate, reliable results for the user. If the profile is defined rigorously, the resulting energy budget should be a good approximation of the values obtained under field conditions with prototype devices.

It is a good idea to be constantly aware of scenarios that diverge from the conventional decision tree that usually drives the design process. One of the most likely situations for wearable devices — or any device that collects biometric data — is the tricky choice of an MCU based on its core.

ARM cores are integrated into the MCUs of many leading semiconductor companies, which make ARM by far the most popular supplier for 32-bit embedded applications. The ARM Cortex-M series of processor cores was developed specifically for applications where MCU performance must be balanced against energy efficiency and low solution cost.

The M3 core is targeted even more narrowly at cost-sensitive applications that still require high-performance computing and prompt system response to real-world events with low-dynamic and static-power consumption.

Most designers would naturally be attracted to MCUs that integrate the ARM Cortex-M3 core; however, there are reasons why this might not be the best choice.

MCU selection

One of the more common wearables is a fitness monitor. In this use case, the MCU receives data about the user’s physical activity using a multi-axis accelerometer. It monitors heart rate using an IR proximity sensor, and may use other sensors to detect body temperature and blood oxygen level. After collecting the sensor data, the MCU filters the raw accelerometer data to eliminate noise and other artifacts before determining the actual step count and frequency or combine it with heart rate data to differentiate between specific types of activities.

The Kalman-filter algorithm is typically used to eliminate noise in applications that depend on these types of data. Its computational requirements are typical of the algorithms that have driven the adoption of 32-bit architectures in wearable designs.

One of the cardinal rules for achieving MCU energy efficiency is to keep the MCU in a reduced-energy-consumption mode as often as possible and for as long as possible.

In the case of a fitness monitor just described, executing a Kalman filter poses an interesting question: What is the energy trade-off between the Cortex-M4F (F for integrated FPU) and the Cortex-M3?

Compared to the M3, the M4F core integrates an FPU-hardware-assist engine and DSP-instruction-set extensions. It therefore consumes more energy when operating at full throttle. The M3, which must execute the algorithm in software, means it is in active mode longer than the M4F.

The trade-off is shown graphically in Figure 1. Saved energy (blue area) increases when an application is optimized by increasing the processing speed and reducing the active and sleep current.


Figure 1: Returning the MCU to standby mode quickly can make up for high-peak-processing energy consumption. (Courtesy of Silicon Labs)

When this analysis is applied to a fitness monitor that uses a Kalman filter algorithm to filter noise, it turns out that the M4F core delivers dramatically faster execution than the M3 core. This is due to (1) the M4F’s enhanced instruction set, which includes a library of powerful digital signal processing (DSP) functions; and (2) The M4F core’s single-precision FPU.

Figure 2 illustrates how quickly an MCU can calculate 512-point FFT in software with a Cortex-M3 core and with a Cortex-M4F core. The Cortex-M4F is about three times more energy efficient than the Cortex-M3 because it returns to sleep mode faster.


Figure 2: An MCU based on the M4F core is three times as energy efficient as the M3 core when calculating a 512-point FFT. (Courtesy of Silicon Labs)

MCUs with well-designed sleep modes multiply this energy-saving effect. Silicon Labs’ Wonder Gecko MCU has several distinct low-energy modes, including a 20 nA shut-off state and 950 nA deep-sleep mode (running real-time clock, full RAM, and register contents retained and brown-out detector enabled). The greater the difference between active- and sleep-mode power consumption, the greater the benefit of a rapid return to a low-energy state.

Based on a modified M4F core, Silicon Labs’ EFM32 Gecko family employs the energy states ARM provides and adds a few of its own.
  • Sleep/Standby – (EM1 mode for EFM32) Enables quick return to active mode with only slightly higher power consumption. In this mode, power consumption for EMF32 = 45 μA/MHz; typical equivalent 32-bit MCU = 200 µA.
  • Deep Sleep – (EM2 mode for EFM32) Leaves the MCU’s critical elements active while disabling high-frequency system clocks and other non-essential loads. In this mode, power consumption for EMF32 is as low as 900 nA; typical equivalent 32-bit MCU = 10 μA to 50 μA.
  • Stop – (EM3 mode for EFM32) A deeper version of deep-sleep mode. It delivers power savings while retaining limited autonomous peripheral activity and fast wake-up. In this mode, power consumption for EFM32 = 590 nA; typical equivalent 32-bit MCU = 10 μA to 30 μA.
  • Backup Battery – A unique EFM32 feature that offers an attractive alternative to Shut-off Mode, preserving a few more critical functions and enabling much faster wake-up.
  • Off/Shut-off – (EM4 or shut-off mode for EFM32) – Preserves minimal functionality needed to trigger wake-up from an external stimulus. Energy savings are created by significantly longer wake-up time. In this mode, power consumption for EFM32 = 20 nA (400 nA with RTC running); typical equivalent 32-bit MCU = 1.5 µA.
Silicon Labs offers a number of Wonder Gecko MCUs with the M4F core. They vary according to package type, memory, and connectivity and I/O options. A typical part is the EFM32WG230F256-QFN64. Silicon Labs also provides two starter kits and a development kit for the Wonder Gecko.

ARM Cortex-M4F-based MCUs from other companies include: Atmel’s ATSAMG51G18A-UUT, Freescale’s MK10DX256VLH7R, Infineon’s XMC4200F64K256ABXQSA1, STMicroelectronics’ STM32F358VCT6, and Texas Instruments’ TM4C123FH6PMI.

Autonomous peripherals

Most MCUs integrate peripherals that execute routine timekeeping, I/O and housekeeping tasks while the CPU remains in one of its low-power sleep modes. Some MCUs are also equipped with autonomous peripherals that perform more complex functions (i.e., counters/timers, ADCs, DACs, GPIOs, serial transceivers, among others) without CPU intervention.

For example, most of the on-chip peripherals supported by the Gecko EFM32 MCU family can function autonomously and remain active in one or more of the device’s sleep modes. This contrasts with most MCUs, in which the lowest energy-saving modes only support very basic keep-alive functions such as GPIO wake-ups and real-time clock (RTC) operation.

Other applications

Although no conclusions are possible until an application undergoes the user-experience analysis described earlier, it is clear that low-energy operation is not always about paring processing power to the bone. It is a good bet that any application that uses biometric data is a candidate for higher performance MCUs with FPU-assist engines.

Battery-powered ECGs (electro-cardiograms) are another example. Like many other portable devices, today’s portable ECGs have their processing throttled at the beginning of the design cycle by assumptions made about power and energy budget restraints. In the case of ECG’s, designers compromise system performance by reducing sampling rates. This, in turn, makes the devices less accurate and patients are usually required to return to the hospital from time to time for a comprehensive ECG examination. Using a higher-performance MCU could be a solution to this problem.

Any application that involves processing data with a fast Fourier transform (FFT) is another likely candidate. Preventing false alarms in glass-break detectors used in home security systems depend on FFT filtering to perform acoustical analysis. The detector must be able to distinguish, for example, between a pane of glass breaking and a water or wine glass that has been dropped into a sink.

Glass of different thicknesses and composition have characteristic sounds and vibration culminating in a resonance at the characteristic frequency of natural glass — around 13 kHz. The sensor analyzes the shattering frequencies and the audio of breaking glass within a defined time frame using the output from a wide-band sound transducer. After filtering the frequency information using a 512-point FFT, the duration and amplitude of the signal are checked to provide further verification of a valid alarm condition. Depending on duty cycle and other considerations, the fact that an FFT is being executed makes it likely that a MCU core with FPU assist will be more energy efficient — and provide better performance generally.

Conclusion

Battery-powered wearable devices are changing the best-practices approach to electronic design. The first step is to start with the desired user experience instead of listing functions and capabilities that will serve as the project’s top-level drivers. Rigorously identifying data types, the kinds of interactions, and the frequency of the device’s interactions is an important follow-on exercise. To an inquisitive design team, this can lead to a design that has superior performance and lower power consumption than the conventional design approach.

For more information on the parts discussed in this article, use the links provided to access product information pages on the Hotenda website.

Supplier