Sensor Node Controller - Powering Future Connected Sensors

By: Marios Iliopoulos, Fotios Kerasiotis, Nikolaos Moschopoulos, Dialog Semiconductor

IntroductionToday
's portable devices understand their surroundings through continuous activity monitoring and situational awareness. To achieve this function, devices integrate more and more sensors and peripherals, which generate a large amount of data. This in turn makes it necessary to integrate more powerful CPUs to perform more and more calculations. At the same time, the design size must be reduced, and the cost and power consumption must be reduced without sacrificing the ever-increasing functional requirements of the end product.

The concept of sensor hub is increasingly being adopted into today's SoC designs to meet the requirements of "always-on" sensor/peripheral access and control (even at high rates) without increasing power consumption and design cost. The sensor hub can be a small CPU core that interfaces with sensors/peripherals and acts as an offload engine for the power-hungry main processor by performing background operations and "waking up" the main processor only when needed.

Typical processor-based architecture for sensor acquisition
A typical microcontroller-based architecture used in a system integrating multiple sensors consists of the following components [1]:

a) A Microcontroller Unit (MCU) - Also known as a processing subsystem, the MCU controls the operation of all components within the system and processes data. It includes a processor, an internal or external memory, and all peripherals and subsystems required for local data processing. In a typical MCU-based architecture, the controller performs all sensor data collection, processing, and storage.

b) Sensor element (or sensor subsystem) - a set of sensors that can be any combination of passive or active, digital or analog. These sensors convert input information from the external environment into electrical signals. In most applications, sensors are used to monitor motion, light, air pressure, vibration, flow rate, temperature, ventilation, electricity, etc. Generally speaking, the sensor element generates a voltage or current signal at its output. These signals are generally amplified and converted into digital signals by analog-to-digital converters before the data is processed, stored and transmitted.

c) Radio - A short range transceiver that provides wireless communication with the host computer.

d) Power Subsystem - Usually connected to a battery or energy harvester. This subsystem acts as a controllable unit that turns the power of the system building blocks on and off individually. It is usually a software block in the MCU software. The power subsystem is responsible for providing the appropriate supply voltage to each individual hardware component.

In more complex microcontroller-based architectures with multiple sensors, intelligence is integrated into the hardware to control various subsystems. For example, transferring data from sensors to memory, which is time-consuming and power-consuming, can be moved from the processor to a direct memory access (DMA) unit. The power management unit (PMU) can also be programmed to react to specific events and shut down various subsystems, such as peripherals, sensors, and radios.

Figure 1. Typical microcontroller-based architecture

The purpose of this advanced architecture is to minimize the time that the main MCU is active. Tasks that previously required MCU intervention can now be performed by intelligent subsystems. However, there is still a problem. Every time there is an event from the sensors, radio or various subsystems, the MCU needs to be woken up because it is the only element that can deploy logic to handle these events.

Techniques for Optimizing Power - Adding Sensor Node Controllers
To extend the battery life of systems with multiple sensors, a variety of techniques have been proposed to reduce power consumption [2], [3]. Some techniques save power at the media access control level [4], [5], some start with data aggregation or fusion [6], [7], and some use chip design optimization techniques such as on-chip power gating [8] or dynamic voltage scaling [9].

This article introduces a different technique to optimize power usage in multi-sensor systems while minimizing the main processor wake-up time for data acquisition. The technique is based on integrating a complex hardware state machine that can take over repetitive tasks such as sensor polling and reading on the main processor, thereby realizing an integrated low-power sensor hub concept. The dedicated hardware state machine can wake up faster and use fewer modules to transfer data from sensors/peripherals to memory and vice versa, while the main processor remains asleep. In addition, the sensor hub can perform simple operations on the data, so the main processor only needs to wake up when complex data operations are required.

A good example of this approach is the sensor node controller (SNC) hardware module integrated into Dialog Semiconductor’s DA1469x Bluetooth low energy SoC solution [10]. The SNC is a tiny hardware state machine that runs microcode (μcode) consisting of a limited instruction set that helps developers operate communication controllers (i.e., SPI, I2C, etc.), sensors, and peripherals. It can run autonomously by using its minimal instruction set without waking up the rest of the system. This allows it to perform a wide range of operations - for example, polling sensor status bits, comparing registers to memory address contents (values), transferring data from the communication interface to system RAM, and comparing branches - while consuming minimal current.

Figure 2. Application processor architecture with sensor node controller peripherals.

The main characteristics of SNC are as follows (Figure 3):

• Sensor Node Instruction Set (SeNIS), which contains 10 microcode generation instructions for:

o Easily create pointers to memory buffers
o Poll serial interface status bits
o Compare thresholds

• System RAM is used for microcode storage and data

• DMA function for transferring data directly from the communication interface to the system RAM

• Direct access to all peripherals and registers

• Executed by PMU immediately after interrupt trigger and domain power-up (e.g. timer, GPIO)

• SNC to host processor notification, and vice versa

The SNC resides in the same power domain as all communication interfaces (SPI, I2C, and UART), and can also control other power domains. It executes microcode that resides in system RAM, where the SNC has a direct memory connection; runs at system clock speed; and can generate interrupts to notify the PMU that all operations are complete, so that the entire system can be powered down.

Figure 3. Sensor node controller block diagram

The main advantages of an architecture that uses this type of dedicated hardware to perform sensor and peripheral data operations are:

• Main CPU sleeps longer, saving power

• Saves MIPS because the CPU does not have to access slow peripherals or perform simple data operations

However, it has some disadvantages. The very simple instruction set of the SNC programming model only allows basic operations. In addition, programming the SNC requires the use of assembly language. Finally, because the SNC is a very simple module, debugging can be complicated.

Power and MIPS Savings
We have performed a series of measurements that demonstrate the power and MIPS savings that can be achieved using the SNC. These measurements were performed on Dialog's ARM Cortex-M33-based DA1469x SoC and compare the same tasks performed using only the main CPU and with support from the SNC. The first set of measurements focused on the power/MIPS savings when accessing slow peripherals such as I2C and SPI that are typically used for sensor readings. The second set of measurements looks at a real-world application case using the Bluetooth Low Energy (BLE) communication module included in the DA1469x.

Table 1 describes the energy consumption when transferring small SPI or I2C data transactions (such as writing/reading 16/128 bytes).

Table 1: Energy consumption when transmitting small data transactions (numbers are for 1.8 V, 8-bit transmission)

Compared to the CPU (CM33), the SNC takes much less time to execute a transaction, as shown in Table 2. Since the CPU may need to perform a busy wait, the time saved is equivalent to MIPS saved.

Table 2: The time required for the SNC to write/read 8-bit data and the time required for the CPU to respond

For a real-life use case, we compared the power consumed when advertising every 1500 ms (Table 3) and 500 ms (Table 4), while reading the accelerometer sensor every 100 ms using SPI.

Table 3: Energy consumption when advertising every 1500 ms, sensor reading every 100 ms using SPI

Table 4: Energy consumption when advertising every 500 ms, sensor reading every 100 ms using SPI

In complex applications, if multiple sensors need to be accessed, the MCU usage will be even greater due to issues such as cache misses and task switching.

Reducing Programming Complexity
As mentioned above, one of the biggest challenges when using an integrated sensor node controller is to ensure that programming, debugging, and full utilization of basic system functions are as simple as solutions using general-purpose MCUs. The main aspects of the challenge are:

• Provides developer-friendly abstract programming to effectively control the communication interface between the driver and the connected sensors/peripherals, as well as the basic functions corresponding to the communication with the main CPU.

• Utilizes 10-instruction assembly-style programming and provides higher-level programming structures to simplify and accelerate software development.

• Supports full system debugging as a whole - rather than debugging each CPU core individually, which may go undetected if system behavior errors occur when cores are running in parallel.

To address these challenges, we need a complete, easy-to-use programming framework. It must include abstractions and procedures that extend the paradigm of concurrent operating system tasks to corresponding (parallel) processing executed on the SNC. We have developed such a programming framework for the Dialog DA1469x solution (Figure 4). It has the following features: