OVERVIEW

This program component is directed to the development of Embedded Networked Sensing (ENS) platforms that are required for the many new environmental monitoring applications that are now being addressed and are emerging. Information about the new LEAP Low Power Energy Aware Processor platform is included below.

Background

A broad range of embedded networked sensor (ENS) systems for critical environmental monitoring applications now require complex, high peak power dissipation sensor devices as well as on-demand high performance computing and high bandwidth communication. Embedded computing demands for these new platforms include support for computationally intensive image and signal processing as well as optimization and statistical computing. To meet these new requirements while maintaining critical support for low energy operation, a new multiprocessor node hardware and software architecture, Low Power Energy Aware Processing (LEAP), has been developed. This architecture integrates fine-grained energy dissipation monitoring and sophisticated power control scheduling for all subsystems including sensor subsystems. The LEAP architecture enables complex energy-aware algorithm design by providing a simple interface to control numerous platform and sensor power modes as well as report detailed energy usage information.

This testbed includes distributed LEAP nodes and a system producing physical, mobile events that provide a development environment for LEAP-hosted algorithms. New design principles, detailed implementation, and the in network programmability and remote debugging capability of this platform are described as well. While this is the first report of the LEAP system, it has been deployed for nearly one year with 50 users developing energy aware systems.

Experimental results for LEAP nodes based on the distributed node testbed are included here. These demonstrate that by exploiting high energy efficiency components and enabling proper on-demand scheduling, the LEAP architecture meets both sensing performance and energy dissipation objectives for a broad class of applications.

Figure 1

The LEAP platform includes a processor platform, shown at right and an Energy Management and Accounting Preprocessor appearing in the center of this diagram. LEAP includes capability for independent energy monitoring and power control for each subsystem in an ENS platform, including processors, sensor systems, wireless interfaces, and other resources. At each instant, the proper resources can be matched to the sensing task. LEAP relies on the highest energy efficiency components - thereby achieving lowest operating energ.

LEAP System

LEAP, shown in Figure 1, includes an essential capability for independent energy monitoring and power control for each subsystem. The LEAP architecture has been developed to harness the use of properly scheduled, energy efficient multiprocessor components selected to achieve the lowest per task operating energy. It is partitioned such that high efficiency, high power components (used on demand) are assigned to a LEAP processor partition while continuously vigilant micropower components are assigned to a LEAP preprocessor partition.

The Energy Management and Accounting Preprocessor (EMAP) provides fine-grained monitoring and control of energy dissipation in all ENS subsystems. Additionally it schedules operation and power delivery to sensor systems and the LEAP’s host processor. Finally, while EMAP enables the entire LEAP system to operate at micropower vigilance, it also provides event detection and triggering capability. This allows event-triggered transition to states where sensors and computing systems are available on-demand according to schedules that match application sampling requirements. The LEAP architecture with the EMAP preprocessor further partitions ENS node subsystems into separately managed power domains supporting individual components (for example, individual sensor devices and processors).

Scheduling operation within power domains enables the LEAP system to define a broad range of power modes that are then matched to environmental monitoring demands. This allows users to develop systems with application specific operating modes intended to meet the minimum energy required for information acquisition subject to specific sensor system and sampling requirements of that application. The LEAP hardware architecture is combined with a software architecture providing developer access to system energy monitoring and management along with subsystem operation scheduling. Experimental results verify that this enables convenient developer access and promotes development of energy aware systems. It also provides an advance for in network programmability and remote debugging of all the components.

Figure 2

The LEAP platform includes a processor platform, shown at right and an Energy Management and Accounting Preprocessor appearing in the center of this diagram. LEAP includes capability for independent energy monitoring and power control for each subsystem in an ENS platform, including processors, sensor systems, wireless interfaces, and other resources. At each instant, the proper resources can be matched to the sensing task. LEAP relies on the highest energy efficiency components - thereby achieving lowest operating energ.

EMAP Preprocessor

1) The EMAP Module provides energy measurement, energy and platform management, and sensor interfaces. The EMAP partitions platform power into power domains allocated at run time according to platform requirements. These domains are typically allocated to 1) EMAP module, 2) Slauson processor module, 3) up to three external sensor systems (including in the experimental results here, the imager). EMAP power supply rails, either 3.3 or 5V, are jumper selectable. The EMAP may power down unused voltage rails to eliminate the quiescent current draw of the voltage regulator. Up to 2A current is available for high power sensors. The LEAP processor module may request the most recent charge accumulation values from the EMAP. The EMAP will respond with each domain’s voltage rail selection, sense amplifier offset value, and sense amplifier gain constants in addition to the accumulated sum values. The host processor then may accurately compute integrated charge and energy for each of the power domains.

In addition to detailed energy monitoring, the EMAP provides a power management scheduling capability. Each of the power domains is electrically isolated from one another when powered off. This is critical since current leakage paths (for example via current conveyed by input protection diodes) to ground may appear when nonisolated systems are operated in a suspend condition. Current inrush limiters also protect the LEAP system from individual domain current inrush and resulting supply voltage droop when enabling domains.

Two low voltage analog sensor inputs are provided with 12bit ADC inputs operating at sampling rates up to 10 kHz, and with a 3.0V precision voltage reference. These ADC inputs may be connected to a variety of low bandwidth sensors for simple event detection.

The EMAP Module - Processor communication is supported by an I2C channel, chosen since it provides a multi-master capability with implicit bus arbitration. This permits convenient expansion of the LEAP platform to include multiple EMAP modules and multiple high-performance processors.

For purposes of energy and performance control, the MSP’s CPU frequency may be controlled from 100KHz to 8MHz or fixed under software control by an external crystal. Further, the EMAP hardware and software has been designed to provide various power modes. The MSP enters the LPM3 power state when running the operating system’s idle thread. Further, a suspend (LPM4) state may be entered through software. The MSP processor and all EMAP peripherals are disabled. The system wakes only due to a sensor signal transition.

EMAP Module remote debugging includes remote software upgrade and source level debugging, the MSP processor’s JTAG interface has been provided to the LEAP processor through the inter-board connector. This allows the processor to assume control of the MSP processor’s execution, to program internal flash, and to perform any action on the MSP’s I/O pins. The host processor acts as the proxy agent for a remote user’s debugging system. Debugging commands that are issued by a remote user’s debugger are routed to the host processor and converted to JTAG command sequences.

Figure 3

The LEAP Processor block diagram, shown at right, includes an interface to the EMAP Preprocessor of Figure 2. The LEAP Processor is based on the Intel PXA255 32 bit processor and includes dual PCMCIA, ethernet, and serial interfaces

LEAP SOFTWARE ARCHITECTURE

Processor Software Architecture
In order to support the increasing demand to host complex ENS applications, the LEAP software framework is comprised of multiple tiers to ensure dependable operation. It is designed to allow recovery from many common faults. The tiers are described below in the order at which they appear at boot time.

The first LEAP software tier is the system bootloader, Redboot. This provides methods for flash memory manipulation, support for remote file retrieval, and loading and execution of other operating systems. The LEAP bootloader itself may be updated with RTOS library elements or completely replaced over remote links. Boot commands are stored in flash-based configuration script and boot the Linux operating system, the next tier.

The Slauson PXA processor supports the Linux 2.6 version kernel, the second tier, compiled with module support for device drivers, network protocols, and power management.

The third tier to appear at boot time is a compressed, read-only cramfs filesystem containing the Busybox utility set. At boot time, this tier validates the integrity of the read-write filesystem composed of a JFFS2 image.

The fourth software tier starting the init program located on the JFFS2 filesystem. The JFFS2 image contains the standard Linux directory structure and boot scripts and a larger set of filesystem utilities and libraries linked against the glibc library. This tier also includes the Processor to EMAP communication system. Applications operating over Linux on the SPM access EMAP utility functions that enable interaction with the EMAP via I2C communication.

A utility, msp-client, provides a convenient interface with both an interactive model for development and testing, as well as a command sequence model. EMAP control provided by msp-client includes access to sensor data, energy and charge data, and power control for all domains. Sensor data access provides the ability to measure instantaneous, average, peak, minimum, and other signal attributes. The msp-client command set also includes a powerful control interface to set, query, and modify power management schedules on a per power domain basis. These schedules may become arbitrarily complex by setting future start times, repeat period, power domain, and power management action. Each power management command issued by msp-client to the EMAP is assigned a unique key permitting additional msp-client access to observe and manipulate schedules. It is important to note that not only may sensor resources be scheduled for power, but the Processor may be powered down (or placed in suspend) to conserve energy and then to be re-enabled at a future time according to a scheduled action.

msp-client also includes many functions that permit control of system response to trigger events that may be set and manipulated. These are based on sensor input signals and may trigger an EMAP action to enable the Procesor or another power domain.

EMAP Preprocessor Software Architecture
Many operating systems are available for the LEAP Processor and EMAP preprocessor. The EMAP now operates with a preemptive RTOS known as uC/OS. This operating system was chosen to meet development requirements including supporting source level debugging, such as through the GNU debugger, gdb. The EMAP software architecture includes a set of uC/OS objects designed for compatibility with the small MSP memory footprint. The workload for EMAP is partitioned into the following software tasks: host processor communication using I2C messages, power management scheduling, sensor interface monitoring and threshold triggering, and CC2420 radio communications.

The I2C messaging task is responsible for receiving and composing messages to and from the host processor. It communicates with the msp-client application mentioned in the previous section. This task utilizes the I2C device driver layer to provide master and slave read and writes through MSP’s I2C hardware controller.

All commands received from the msp-client application are parsed within the I2C messaging task and any reply messages are composed, and returned. The I2C messaging task will handle messages that do not require specialized actions without waking other threads including read back of system settings or of charge accumulation values. The power management task is responsible for processing and scheduling all power management commands issued by the msp-client application. When a new msp-client message arrives it is processed by the I2C messaging task. If that command is a power management command, it is added to the power management task’s list of actions and the task is signaled to run. The power management task then chronologically sorts all new and existing power management actions in the scheduled actions list. By chronologically sorting the list, it can be parsed quickly for expired actions. The power management task then suspends itself until the time of the first scheduled action or until a new power management command arrives. If no new command message arrives, the action’s delay timer expires. The power management task then examines the scheduled action list looking for runnable actions. An action is runnable when it is on the scheduled actions list and it is in the past. The power management task removes each runnable action from the actions list. The action, which can be to enable or disable power, or to trigger a wakeup, is performed on the specified power domain. If the action is not periodic, the action object is recycled to the free actions list. If the action is marked as periodic, then the period interval is added to the actions scheduled run time and the action is reinserted into the actions list.

The sampling and triggering task is responsible for setting the periodic sample rates for the on chip ADC channels connected to the two external sensor inputs and to set the wakeup trigger threshold values. Sensor sampling and threshold settings commands issued by msp-client are first parsed by the I2C messaging task. Relevant messages to the sampling and triggering task will wake this thread to process the message contents. The sampling and triggering task checks the validity of sensor sampling commands such as assuring that the selected sensor sample rate is compatible with the charge accumulation sampling rate. This task is also responsible for resetting triggered wakeup actions and setting sensor threshold values and detection edges. Should this task be run by the ADC interrupt handler due to a threshold excursion event, it will perform all wakeup actions on power domains that are registered for wakeup event handling.

The last EMAP task is for communication through the CC2420 low-power radio. The CC2420 communications thread utilizes the SPI driver for reads and writes to the CC2420’s data port. Like the I2C driver the SPI driver uses DMA for data transfer. Unlike I2C, the SPI bus operates in full duplex. To support this, two DMA channels are necessary. One DMA channel reads incoming data from the SPI receive buffer while the second directs outbound data into the transmit buffer. The CC2420 communications task leverages a CC2420 utility library that abstracts the CC2420 into basic access functions such as power mode settings and to transmit or receive packets.

SUMMARY

The new LEAP ENS platform including a heterogeneous multiprocessor architecture has been developed based on a design approach addressing the challenge of supporting complex and powerful sensor systems, embedded computing platforms, and high performance communication interfaces. To achieve desired performance goals while simultaneously meeting energy dissipation requirements, this design approach focuses on exploiting high energy efficiency components that are scheduled for operation on-demand operation. The LEAP system relies on the EMAP module for maintaining low power, constantly vigilant operation while providing event detection and fine-grained energy accounting. The LEAP system is now in active use for development of a wide range of ENS applications in many environment monitoring applications. The feasibility of operation at low duty cycle with multiple power domain scheduling has been demonstrated and experimentally verified, as discussed here. Many users have developed complex and robust algorithm implementations based on the LEAP tool set including the EMAP msp-client interface.

PEOPLE

Dustin McIntire

Kei Ho

Bernie Yip

William Kaiser