Integrated tools streamline low-energy MCU development

by Rasmus Christian Larsen , TechOnline India - October 28, 2011

Microcontroller development is a complex process. Each individual model is different, with its own set of interfaces and control registers. Low-energy MCUs extend the range of options with a variety of power-down modes.

Microcontroller development is a complex process. Each individual model is different, with its own set of interfaces and control registers. Low-energy MCUs extend the range of options with a variety of power-down modes and in some cases intelligent I/O engines to offload some of the processing burden from the processor core.

The reason for the increase in intelligent peripherals lies in their ability to reduce overall system power. The duty cycle of a low-energy MCU is key to its battery autonomy. In a low duty-cycle system, the MCU sleeps for much of the time. It wakes only to collect data from sensor inputs, normally at a scheduled time or to respond to rare, unscheduled interrupts. This approach has proved highly effective in the design of utility meters where the processor core may sleep for 99 percent of its overall life cycle.

To try to reduce the duty cycle further, MCU vendors such as Energy Micro have added intelligent peripherals that offload complex sensor interfacing functions to programmable hardware. This approach works because of the lower energy overhead of dedicated and programmable hardware over a microprocessor core.  



Fig 1 a & b: Using a high-speed 32-bit CPU processing time is reduced. In addition new peripherals are designed to perform complex routines without involving the CPU at all, enabling system energy consumption to be further reduced. The CPU only needs to wake up when a peripheral flags the need for further processing.

Instruction supply to a microprocessor core, even from on-chip memory, can account for more than 40 per cent of total processor power consumption. The energy demand of moving variable contents from data memory to registers and on into the processing data path incurs a further overhead. This level of data movement, which generally involves higher-capacitance – and therefore higher energy – bus connections, is not needed in hardware implementations.

Many sensor operations can be controlled by a state machine, which, if made programmable, can be configured to handle a wide range of sensor-processing functions without waking the processor core. This philosophy lies behind the approach that Energy Micro took in implementing the Lesense peripheral block that has been added to the EFM32 Gecko series of MCUs.

In Lesense, states and the conditions used to select them are programmed through descriptors that can be chained together to form relatively complex operations where needed, or restricted to simple outputs if that is all that is required. In this way, it is possible to build quite complex logic before intervention need be sought from the processor core.



Fig 2: Lesense is a low energy peripheral capable of monitoring up to 16 sensors autonomously. Designers can setup the sensor interface to monitor inductive, resistive or capacitive sensors, and then on a specified event invoke the central processing unit or other peripherals.


In using functional blocks such as Lesense, as well as more conventional peripherals such as serial ports, there are a number of trade-offs and system-level decisions that the developer will need to make – and many of them will not become fully apparent until the engineers are some way into the project.

For example, a priori analysis of an application may lead the team to conclude that the initial architecture will meet its power budget. However, it can become apparent in later stages that interactions between code modules and functions are leading to excessive power consumption because the processor core is awake for longer periods than expected, possibly running an idle loop waiting for input instead of going to sleep and waiting on a hardware-generated interrupt. By profiling the application during development and altering the balance of hardware versus software implementation it becomes much more straightforward to hit energy-consumption targets, particularly if the development environment is designed with this in mind. This was the philosophy that lay behind the development of Simplicity Studio.

Having the right information to hand is the first step in achieving success in MCU application development. When the user starts on a project, the Simplicity Studio console auto-configures in response to user selection of a target MCU from a drop-down menu.  The console then provides the user only with the development support options applicable to that particular MCU and can be further customized by adding and removing components at the click of a button.

The auto-configuration ensures that the developer has the relevant information about the MCU to hand. For example, a user of a particular EFM32 Tiny Gecko, such as the EFM32ZG222F32, will not only see in the documentation set the manuals and applications notes for peripherals, but the instruction set manual for the Cortex M0 processor rather than the M3 used by other members of the EFM32 Gecko family.

Time saving through automatic updates

A key time-saving role of Simplicity Studio is to ensure users stay automatically up-to-date with all of the changes affecting their own development environment. One problem that many MCU users face when working on projects supported by conventional data books, whether printed or in PDF format, is that they may not be aware of errata or changes until they encounter a problem with their code that uncovers the altered functionality. Simplicity Studio avoids this problem by continually updating itself with new information from Energy Micro.



Fig 3: Simplicity Studio can be thought of as a tool box that always carries the latest available firmware and software updates. Simplicity Studio only shows the tools relevant to a specified MCU, and with automatic updates there is no need to have to search for new firmware, software or documentation.

Users receive alerts for example concerning new software releases, documentation and firmware updates and can access a change-log identifying exactly what has been updated and when.

For users getting started with a new MCU, downloadable code examples that integrate with the documentation and the target provide a quick and powerful way of learning about the functionality of a peripheral or a set of processor core instructions and testing various power reduction and control strategies.

Active feedback on energy consumption is a major feature of the Simplicity Studio that is realized in the energyAware Profiler. This tool takes the embedded development suite beyond its conventional use as a code-writing and debugging environment. In energy-sensitive applications, you can conceivably remove all the bugs from a design and still have a system that does not meet its most crucial target: its energy performance.

The Profiler makes it possible to analyze the code in a system not just for its functionality but its energy consumption – providing engineers with a tool to help determine which functions are consuming the most power and so guide whether some functions should be devolved to hardware, for implementation in a peripheral such as Lesense, or restructured to allow the processor core to sleep for longer periods of time.

The Simplicity Studio environment provides a dynamic view of how the target consumes power. The information is not just available as an aggregate current value, but using code-level instrumentation on a fine-grained function-by-function basis.



Fig 4: Embedded designers only need to connect the starter kit to their computer via USB to perform advanced power profiling. The energyAware Profiler software shows the associated code and energy consumption, which speeds up debugging and reduces the need for oscilloscopes or multimeters.

Take, for example, a system that monitors the health of an industrial motor. The MCU needs to monitor the input from a set of four inductive sensors that detect the rotation of the shaft being driven by the motor. At regular intervals, the MCU takes information from an accelerometer that is used to analyze vibration - excessive vibration indicates a potential problem with the motor.

In the initial implementation, the MCU is programmed to sleep after every set of vibration analysis calculations. However, power analysis shows that the system is exceeding its power target significantly. By drilling down into the function-call list, the engineer can determine which parts of the code seem to be responsible for most of the power consumption.

In this case, the problem turns out to be a while-loop that is being used to poll the sensor that is expected to be triggered next by the rotation of the driveshaft. On each successful read, the next sensor is 'activated' and polling continues there or, if a number of rotations have occurred, the function to perform vibration analysis is called. The result is that the MCU does not go into sleep mode until after vibration analysis, where it will be woken up by a clock timer set at a rate that is higher than the shaft's rotation rate.

The programmer alters the code such that the MCU can go to sleep after a successful read. But the MCU still shows higher than desired power consumption tied to the sensor interfacing code. The problem is that the MCU has to be awake in anticipation of an event from the driveshaft sensors. It would be better if the MCU could sleep until the analog comparator registers a positive reading, but without leaving the analog comparator continuously on. This can be done, the engineer finds, by looking at the embedded documentation by programming the state machine of the Lesense peripheral.

Using a code example associated with the online application note, the engineer tests the strategy -- which would allow the MCU to sleep until a sensor records a positive signal. Realizing that, for this application, it is possible to program the state machine to not wake the MCU until for example 100 complete revolutions has been made -- the engineer then edits the code to fit the target application. At this point, the Profiler shows that the application is now within the power budget.

By pulling together documentation, online updates and feedback on application performance, it is possible to streamline the development of low-energy embedded systems, as Simplicity Studio demonstrates.

About the author:

Rasmus Christian Larsen is  Support & Training Manager at Energy Micro. He is responsible for support and training of Energy Micro's customers and world wide sales force. Previously he worked on the design of the EFM32, and also was a digital design engineer at Atmel Norway. He has a masters in electronics from the  Norges teknisk-naturvitenskapelige universitet (NTNU).



blog comments powered by Disqus