Autonomous MCU Peripherals Provide Embedded Designs with Numerous Features

Autonomous peripheral cores that offload an MCU’s main processor from many routine tasks are becoming an increasingly popular way to enhance an embedded processor’s real-time performance while dramatically reducing its energy consumption. Presently available on select variants of several popular MCU architectures, these so-called “smart peripherals” are dedicated hardware elements which can work alone or with other cores to perform complex data acquisition, I/O, and housekeeping functions while the CPU remains in a low-power sleep mode. In addition to dramatic power savings, these intelligent peripherals provide deterministic response to real-time events without the need for complex interrupt service routines or RTOS software. In this article, we will look at the architectural details of the intelligent peripheral systems recently introduced by Energy Micro (Figure 1) and Atmel for their 8- and 32-bit platforms and some of the advantages they offer in real-world applications.

Figure 1: This cargo container monitor relies on the autonomous peripherals in Energy Micro’s EFM32 MCU to help it provide shippers with location and status data for a year or more on a single set of batteries. The monitor mounts on a standard shipping container’s main door and uses the EFM32’s compliment of autonomous peripherals to handle routine data collection (GPS coordinates, temperature, shock/vibration, door openings, and tamper detection) while the CPU spends nearly all of its time in a low-power sleep state. (Courtesy of Starcom Systems.)

Intelligent evolution

Intelligent peripherals are a natural extension of the I/O controllers, algorithmic accelerators, and other specialized hardware modules already used in many MCUs. Today, even many low-cost 8-bit microcontrollers such as Microchip Technology’s PIC18 or STMicro’s STM8 family include specialized state machines or accelerator cores, which offload tasks such as matrix operations, encryption, error correction, or controlling a touch screen. Nevertheless, the accelerator modules, screen controllers, and other I/Os all rely on the main processor (CPU) for one or more aspect of their operation, and often compete with it for access to the memory bus and other shared resources. In contrast, autonomous peripherals only require the CPU when they are being initialized and configured to perform a particular set of functions and, in most cases, communicate using a separate bus.

By offloading the MCU’s processor from many routine tasks, smart peripherals allow it to spend as much time as possible in a low-power snooze or sleep state that conserves the limited energy resources available from its batteries or energy harvesting system. This is a critical advantage since many applications require the MCU to frequently respond to both scheduled and unscheduled events in real time — or at least semi-real time.

Examples of scheduled events include:

• ZigBee/802.15, Wi-Fi, and other wireless technologies use time-slotted protocols, which require the host processor to periodically check for messages from other network nodes
• Real-time clock interrupts that prompt initiation of system-related tasks or collect data at regularly scheduled intervals

Typical unscheduled events can include things such as:

• Alarm conditions and other urgent, unscheduled events which require the host processor to respond within a few milliseconds to prevent system damage or avoid loss of critical data
• Some wired and wireless protocols which transmit at random intervals, requiring the system to be ready to respond to an incoming packet at any time

In both cases, a device alerts the MCU to a real-time event by a toggling its interrupt line, causing the processor to jump to an interrupt service routine (ISR). As a simple example, let’s consider an MCU which is required to execute event-related tasks. In this case, the MCU must read an analog to digital converter when a timer/counter’s register signals an overflow, or capture the value in a timer/counter’s register at the instant a user presses a button. After the interrupt wakes the MCU from its sleep state, the interrupt service routine directs the MCU to react to the button press or timer-based event. However, problems may arise if the system must deal with real-time events that are too frequent or too complex, they may force the MCU to spend too much time in its active mode. This can dramatically shorten its battery life or exceed the capacity of its energy-harvesting system.

In addition, real-time events add another layer of challenges to software development. The time it takes the MCU to respond to an event will depend heavily on how many other interrupts are competing for its attention at that moment. If, for example, the MCU must attend to one or more other interrupt-driven peripherals before it can respond to the counter/timer, the count read from its output register might be much higher that it was at the instant of the actual button push. Likewise, if the MCU takes a few milliseconds too long to initiate the A/D conversion, the signal it is attempting to sample may have changed, or vanished entirely. In many cases, carefully crafted interrupt service routines can insure the MCU will promptly attend to the highest-priority events within their critical time windows, but the software’s added complexity can add significantly to a project’s labor budget and production schedule.

Smart cores to the rescue

These issues were addressed a decade or more ago by advanced communication processors such as the Freescale MPC8xxx PowerQUICC® series, which used multiple dedicated communications engines to handle the tasks associated with basic packet header processing and networking protocols without ever involving the QUICC’s PowerPC CPU. However, it took a long time for similar technologies to become available in the low-cost MCUs used in most embedded systems.

Energy Micro became one of the earliest companies to offer intelligent peripherals when it introduced its EFM32 “Gecko” family, which is based on the Arm® Cortex™-M3 Processor (Figure 2). Designed specifically for ultra-low-energy operation, the basic M3 core has been enhanced with the addition of four selectable sleep/standby “energy management” modes (EM 1 through EM 4) that allow the designer to select the level of functionality, response time, and power consumption that meets their needs.

Figure 2: Energy Micro’s Gecko MCUs feature a set of autonomous peripherals (APs) that operate independently of its Cortex M3 CPU.

All members of the EFM32 family are equipped with a rich compliment of analog and digital peripheral elements. Most of these elements are so-called autonomous peripherals (APs), which can function without CPU intervention and remain active in one or more Sleep Modes. This contrasts sharply with conventional MCUs, whose lowest energy-saving modes only support very basic keep-alive functions such as GPIO wake-ups and RTC operation.

In addition to the counters/timers, ADCs/DACs, GPIO, and serial communications found on most MCUs, Energy Micro’s complement of APs includes:

• Capacitive sense processor – senses touchpad contact and coordinates within an n-by-n grid (up to 16 points) without CPU. The processor remains active down to the EM2 energy mode, which disables the CPU’s high frequency system clocks and other non-essential loads.
• LCD driver – can drive numeric LCD or TFT display via DMAs from memory without CPU
• Analog comparators – enable monitoring of threshold voltages for alert/alarm conditions without CPU intervention
• Low-energy UART (LEUART) with DMA can remain in EM2 while receiving a large amount of data without waking up the CPU

The activities of most peripheral functions, including serial communications, counters/timers, analog and digital comparators and higher-level I/O are coordinated by a separate low-power reflex bus. Events and signals from one peripheral can be used as input signals or triggers by other peripherals and ensure timing-critical operation and reduced software overhead. These advanced features enable Energy Micro’s EFM32 family of MCUs to bring the computational power of a full-featured 32-bit device to an application while consuming only a fraction of the energy required by most conventional 16- or 32-bit MCUs.

Atmel embraces autonomous peripherals

Atmel has also hopped on the autonomous peripheral bandwagon with an architecture which it refers to as the Peripheral Event System (PES). Originally developed for the 8/16-bit XMEGA® branch of its AVR® processor family tree, the PES is a distributed network of intelligent analog and digital I/O peripheral elements which operates independently of the CPU and its DMA system (Figure 3).

Figure 3: Atmel’s Peripheral Event System provides a separate control and data bus for the MCU’s peripherals to execute multi-stage, conditionally based operations without using any of the host CPU’s computing or bus resources.

A typical XMEGA’s complement of autonomous peripherals includes:

• GPIO
• Asynchronous timer (RTC)
• General-purpose timer /counters
• Two-wire interface (TWI)
• Power manager
• Analog comparators and ADCs
• Capacitive touch controller

The XMEGA’s intelligent peripherals communicate with each other via the Event Routing Network, a separate parallel bus that allows peripherals to interact without intervention from the microcontroller’s CPU. The Event System can be configured to control any combination of its peripherals and have them selectively react to external inputs — or interact with each other.

The Event Routing Network is an event-driven system in which each event is an indication that a change of state within a peripheral has occurred in response to an internal or an external stimulus. A closer look reveals a set of programmable multiplexers (Fig.4) which connect events from the initiating peripheral (a.k.a. event generator) to its intended destination (the event user). Each channel also includes programmable control and filtering logic that is used to define a peripheral’s behavior for a particular event, and the inputs required to produce it. This inter-peripheral communication allows actions to be triggered by external events, by events generated by other peripherals, or by the CPU as a software-generated “manual” function. The XMEGA’s peripherals and their associated multiplexer/filter logic is programmed by writing the appropriate data to each peripheral’s control registers. The code used to configure the controller and its peripherals can be created (and documented) easily, using a visual interface that’s available in Atmel’s Studio6 integrated development environment.

Figure 4: Atmel’s Event Routing Network can be configured to make its autonomous peripherals perform complex functions such as data collection, timing, and communication, or respond to real-time events without any intervention from the CPU.

Atmel’s PES operates in parallel with the CPU to insure precisely timed execution of critical real-time tasks or enter a so-called “SleepWalking” state which extends the PES’s capabilities into the MCU’s sleep domain. During SleepWalking, the PES’s configuration logic selects the peripherals that will continue to function when the MCU enters its low-power sleep state, and the conditions which will cause the peripherals to wake up the system. PES-enabled AVR MCUs also include a compliment of conventional peripherals, such as AES and DES crypto modules, PWM output generators, and CRC generators which use the CPU’s DMA to move data to and from memory and require some intervention from the CPU.

Recently, Atmel brought its autonomous peripheral technology to the 32-bit world with a PES-equipped ARM CORTEX-M4 RISC processor (Fig.5). Known as the SAM4L, its real-time capabilities, ultra-low-power operation, and simplified programming are well-suited to advanced applications such as intelligent sensor nodes for HVAC and alarm systems, glucose monitors, and point-of-sale terminals.

Figure 5: Atmel’s SAM4L MCU integrates a 32-bit ARM CORTEX-M4 RISC processor with a rich set of I/O elements and other peripherals. Many of the SAM4L’s peripherals are controlled by its Peripheral Event System, which operates independently of the CPU for better real-time performance and lower energy consumption.

Smart pays in many ways

Regardless of which processor architecture you choose, using an MCU with autonomous peripheral capabilities provides significant advantages for many applications. As mentioned earlier, smart peripherals can trim an embedded design’s energy budget, extending its service life or enabling the use of a smaller, less-expensive battery or energy-harvesting system (Figure 6).

Figure 6: The energy profile of Atmel’s SAM4L MCU demonstrates how autonomous peripherals reduce energy consumption by allowing the main processor to spend more time in a low-power standby or sleep state. In this example, the SAM4L’s Cortex-M4 RISC processor is awakened in response to an event that requires its attention, but only remains operational as long as its capabilities are needed.

Most intelligent peripheral architectures also provide deterministic response to real-time events without the need for carefully written interrupt service routines or the added overhead of a real-time operating system (RTOS). Allowing hardware cores to handle time-critical tasks can allow you to choose a slower, less-costly processor to handle the system’s present workload — or provide a reserve of processing capability to support additional capabilities.

In many cases, the reduced software complexity can also help trim the time and labor costs associated with both writing and testing the code. In addition, it is likely you will realize even more savings further down the product’s life cycle from code that is much easier to maintain and upgrade. At present, the added cost and relatively limited number of MCUs offering smart peripherals means that not every design will be able to benefit from them. However, of course, that is the same situation “dumb” on-chip peripherals were in a decade and a half ago when they first started to gain a toehold on low-end MCUs.