System architecture directions for networked sensors

TL;DR: Key requirements are identified, a small device is developed that is representative of the class, a tiny event-driven operating system is designed, and it is shown that it provides support for efficient modularity and concurrency-intensive operation.

Abstract: Technological progress in integrated, low-power, CMOS communication devices and sensors makes a rich design space of networked sensors viable. They can be deeply embedded in the physical world and spread throughout our environment like smart dust. The missing elements are an overall system architecture and a methodology for systematic advance. To this end, we identify key requirements, develop a small device that is representative of the class, design a tiny event-driven operating system, and show that it provides support for efficient modularity and concurrency-intensive operation. Our operating system fits in 178 bytes of memory, propagates events in the time it takes to copy 1.25 bytes of memory, context switches in the time it takes to copy 6 bytes of memory and supports two level scheduling. The analysis lays a groundwork for future architectural advances.

Summary

1 Introduction

• As the post-PC era emerges, several new niches of computer system design are taking shape with characteristics that are quite different from traditional desktop and server regimes.
• One of the most interesting of these new design regimes is networked sensors.
• Three other trends are equally important: complete systems on a chip, integrated low-power communication, and integrated low-power devices that interact with the physical world.
• The basic microcontroller building block includes not just memory and processing, but non-volatile memory and interface resources, such as DAC, ADCs, UARTs, interrupt controllers, and counters.

2 Networked Sensor Characteristics

• This section outlines the requirements that shape the design of network sensor systems; these observations are made more concrete by later sections.
• Small physical size and low power consumption:.
• At any point in technological evolution, size and power constrain the processing, storage, and interconnect capability of the basic device.
• Obviously, reducing the size and power required for a given capability are driving factors in the hardware design.
• At a system level, the key observation is that these capabilities are limited and scarce.

Concurrency-intensive operation:

• The primary mode of operation for these devices is to flow information from place to place with a modest amount of processing on-the-fly, rather than to accept a command, stop, think, and respond.
• Information may be simultaneously captured from sensors, manipulated, and streamed onto a network.
• Alternatively, data may be received from other nodes and forwarded in multihop routing or bridging situations.
• There is little internal storage capacity, so buffering large amounts of data between the inbound and the outbound flows is unattractive.
• Moreover, each of the flows generally involve a large number of low-level events interleaved with higher-level processing.

Limited Physical Parallelism and Controller Hierarchy:

• The number of independent controllers, the capabilities of the controllers, and the sophistication of the processor-memory-switch level interconnect are much lower than in conventional systems.
• Typically, the sensor or actuator provides a primitive interface directly to a single-chip microcontroller.
• In contrast, conventional systems distribute the concurrent processing associated with the collection of devices over multiple levels of controllers interconnected by an elaborate bus structure.
• Diversity in Design and Usage: Networked sensor devices will tend to be application specific, rather than general purpose, and carry only the available hardware support actually needed for the application.

3 Example Design Point

• To ground their system design study, the authors have developed a small, flexible networked sensor platform that expresses many of the key characteristics of the general class and represents the various internal interfaces using currently available components [34] .
• It consists of a microcontroller with internal flash program memory, data SRAM and data EEPROM, connected to a set of actuator and sensor devices, including LEDs, a low-power radio transceiver, an analog photo-sensor, a digital temperature sensor, a serial port, and a small coprocessor unit.
• While not a breakthrough in its own right, this prototype has been invaluable in developing a feel for the salient issues in this design regime.

3.1 Hardware Organization

• The processor within the MCU (ATMEL 90LS8535) [2] , which conventionally receives so much attention, is not particularly noteworthy.
• The MCU is designed such that a processor cannot write to instruction memory; their prototype uses a coprocessor to perform that function.
• Additionally, the processor integrates a set of timers and counters which can be configured to generate interrupts at regular time intervals.
• More noteworthy are the three sleep modes: idle, which just shuts off the processor, power down, which shuts off everything but the watchdog and asynchronous interrupt logic necessary for wake up, and power save, which is similar to the power down mode, but leaves an asynchronous timer running.
• Three LEDs represent analog outputs connected through a general I/O port; they may be used to display digital values or status.

3.2 Power Characteristics

• Table 1 shows the current drawn by each hardware component under three scenarios: peak load when active, load in "idle" mode, and inactive.
• When active, the power consumption of the LED and radio reception are about equal to the processor.
• This figure should be contrasted with the 10 µA current draw in the inactive mode.
• Clearly, the biggest savings are obtained by making unused components inactive whenever possible.

4 Tiny Microthreading Operating System (TinyOS)

• Small physical size, modest active power load and tiny inactive load are provided by the hardware design.
• An operating system framework is needed that will retain these characteristics by managing the hardware capabilities effectively, while supporting concurrency-intensive operation in a manner that achieves efficient modularity and robustness.
• For reasons described in Section 6, existing embedded device operating systems do not meet this challenge.
• The problem the authors must tackle is strikingly similar to that of building efficient network interfaces, which also must maintain a large number of concurrent flows and juggle numerous outstanding events [20] .

4.1 Tiny OS Design

• Threads, commands, and handlers execute in the context of the frame and operate on its state.
• To facilitate modularity, each component also declares the commands it uses and the events it signals.
• These declarations are used to compose the modular components in a per-application configuration.
• The composition process creates layers of components where higher level components issue commands to lower level components and lower level components signal events to the higher level components.
• Physical hardware represents the lowest level of components.

4.2 Example Component

• Like most components, it exports commands for initialization and power management.
• In order to perform its function, the message component issues commands to a packet level component and handles two types of events: one that indicates a message has been transmitted and one that signals that a message has been received.
• Since the components describe both the resources they provide and the resources they require, connecting them together is very simple.
• The programmer simply matches the signatures of events and commands required by one component with the signatures of events and commands provided by another component.
• The communication across the components takes the form of a function call, which has low overhead and provides compile time type checking.

4.3 Component Types

• In general, components fall into one of three categories: hardware abstractions, synthetic hardware, and high level software components.
• Hardware abstraction components map physical hardware into their component model.
• This component exports commands to manipulate the individual I/O pins connected to the RFM transceiver and posts events informing other components about the transmission and reception of bits.
• The frame of the component contains about the current state (the transceiver is in sending or receiving mode, the current bit rate, etc.).
• The RFM consumes the hardware interrupt, which is transformed into either the RX bit evt or into the TX bit evt.

4.4 Putting it all together

• Now, that the authors have shown a few sample components, they will examine their composition and their interaction within a complete configuration.
• They monitor the temperature and light conditions and periodically broadcast their measurements onto the radio network.
• Each sensor is configured with routing information that will guide packets to a central base station.
• Thus, each sensor can act as a router for packets traveling from sensors that are out of range of the base station.
• There are three I/O devices that this application must service: the network, the light sensor, and the temperature sensor.

5 Evaluation

• Table 2 shows the code and data size for each of the components in their system, also known as Small physical size.
• It is clear that the code size of their complete system, including a network sensor application with simple multihop routing, is remarkable.
• In particular, their scheduler only occupies 178 bytes and their complete network sensor application requires only about 3KB of instruction memory.
• Furthermore, the data size of their scheduler is only 16 bytes, which utilizes only 3% of the available data memory.
• The authors entire application comes in at 226 bytes of data, still under 50% of the 512 bytes available.

Concurrency-intensive operations:

• Table 3 shows this aspect calibrated against the intrinsic hardware cost for moving bytes in memory.
• This low overhead is essential for achieving modular efficiency.
• The authors most expensive operation involves the low-level aspects of interrupt handling.
• Though the hardware operations for handling interrupts are fast, the software operations that save and restore registers in memory impose a significant overhead.
• Several techniques can be used to reduce that overhead: partitioning the register set [22] or use of register windows [14] .

Limited physical parallelism and controller hierarchy:

• The authors have successfully demonstrated a system managing Step 4 signals the application that the send msg command has finished.
• The application then issues another asynchronous send msg command in step 5 which post a thread at step 6 to send the packet.
• While send msg thread prepares the message, the RFM component is periodically scheduled to listen for incoming packets.
• Multiple flows of data through a single microcontroller.
• Table 4 shows the work and energy distribution among each of their software components while engaged in active data transmission.

6 Related Work

• There is a large amount of work on developing micromechanical sensors and new communication devices [39, 38] .
• The development of these new devices make a strong case for the development of a software platform to support and connect them.
• The authors believe that current real-time operating systems do not meet the needs of this emerging integrated regime.
• Many of them have followed the performance growth of the wallet size device.

7 Architectural Implications

• A major architectural question in the design of network sensors is whether or not individual microcontrollers should be used to manage each I/O device.
• This shows that it is an architectural option -not a requirement -to utilize individual microcontrollers per device.
• Moreover, the interconnect of such a system will need to support an efficient event based communication model.
• Tradeoffs quickly arise between power consumption, speed of off chip communication, flexibility and functionality.
• Additionally, their quantitative analysis has enabled us to consider the effects of using alternative microcontrollers.

Figures

Table 2: Code and data size breakdown for our complete system. Only the processor init, the TinyOS scheduler, and the C runtime are required for every application, the other components are included as needed.

Figure 3: A sample configuration of a networked sensor

Table 5: A comparison of selected architecture features of several embedded OSes.

Table 4: Details breakdown of work distribution and energy consumption across each layer for packet transmission and reception. For example, 66.48% of the work in receiving packets is done in the RFM bit-level component and it utilizes 30.08% of the CPU time during the entire period of receiving the packet. It also consumes 451.17nJ per bit it processes. Note that these measurements are done with respect to raw bits at the physical layer with the bit rate of the radio set to 100 µs/bit using DC-balanced ON-OFF keying.

Table 3: Overheads of primitive operations in TinyOS

Figure 2: A sample messaging component. Pictorially, we represent the component as a bundle of threads, a block of state (component frame) a set of commands (upside-down triangles), a set of handlers (triangles), solid downward arcs for commands they use, and dashed upward arcs for events they signal. All of these elements are explicit in the component code.

Table 1: Current per hardware component of baseline networked sensor platform. Our prototype is powered by an Energizer CR2450 lithium battery rated at 575 mAh [30]. At peak load, the system consumes 19.5 mA of current, or can run about 30 hours on a single battery. In the idle mode, the system can run for 200 hours. When switched into inactive mode, the system draws only 10 µA of current, and a single battery can run for over a year.

Figure 4: A timing diagram from a logic analyzer capturing event propagation across networking components at a granularity of 50 µs per division. The graph shows the send message scenario described in Section 4.4 focusing on transmission of the last bit of the packet. Starting from the hardware timer interrupt of step 0, events propagate up through the TX bit evt in step 1, into byte-level processing. The handler issues a command to transmit the final bit and then fires the TX byte ready event in step 2 to signal the end of the byte. This triggers TX packet done in step 3. Step 4 signals the application that the send msg command has finished. The application then issues another asynchronous send msg command in step 5 which post a thread at step 6 to send the packet. While send msg thread prepares the message, the RFM component is periodically scheduled to listen for incoming packets. The event propagation delay from step 0 to step 4 is about 40 µs while for the entire event and command fountain starting from step 0 to step 6 to be completed, the total elapsed time is about 95 µs.

Figure 1: Photograph and schematic for representative network sensor platform

Full text

System Architecture Directions for Networked Sensors
Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler, Kristofer Pister
April 27, 2000
Abstract
Technological progress in integrated, low-power, CMOS communication devices and sensors makes
a rich design space of networked sensors viable. They can be deeply embedded in the physical world
or spread throughout our environment. The missing elements are an overall system architecture and a
methodology for systematic advance. To this end, we identify key requirements, develop a small device
that is representative of the class, design a tiny event-driven operating system, and show that it provides
support for efficient modularity and concurrency-intensive operation. Our operating system fits in 178
bytes of memory, propagates events in the time it takes to copy 1.25 bytes of memory, context switches
in the time it takes to copy 6 bytes of memory and supports two level scheduling. The analysis lays a
groundwork for future architectural advances.
1 Introduction
As the post-PC era emerges, several new niches of computer system design are taking shape with charac-
teristics that are quite different from traditional desktop and server regimes. One of the most interesting of
these new design regimes is networked sensors. The networked sensor is enabled, in part, by “Moore’s Law”
pushing a given level of computing and storage into a smaller, cheaper, lower-power unit. However, three
other trends are equally important: complete systems on a chip, integrated low-power communication, and
integrated low-power devices that interact with the physical world. The basic microcontroller building block
includes not just memory and processing, but non-volatile memory and interface resources, such as DAC,
ADCs, UARTs, interrupt controllers, and counters. Communication may take the form of wired, short-range
RF, infrared, optical, or various techniques [18]. Sensors interact with various fields and forces to detect
light, heat, position, movement, chemical presence, and so on. In each of these areas, the technology is
crossing a critical threshold that makes networked sensors an exciting regime to apply systematic design
methods.
Today, networked sensors can be constructed using commercial components on the scale of a square inch in
size and a fraction of a watt in power, using one or more microcontrollers connected to various sensor devices,
using I
2
C, SPI, or device specific protocols, and to small transceiver chips. One such sensor is described in
this study. It is also possible to construct the processing and storage equivalent of a 90’s PC on the order
of 10 in
2
and 5-10 watts of power. Simple extrapolation suggests that the equivalent will eventually fit in
the square inch and sub-watt space-power niche and will run a scaled down Unix [12, 42] or an embedded
microkernel [13, 26]. However, many researchers envision driving the networked sensor down into microscopic
scales, as communication becomes integrated on-chip and micro-electrical mechanical (MEMS) devices make
a rich set of sensors available on the same CMOS chip at extremely low cost [38, 5]. networked sensors will
be integrated into their physical environment, perhaps even powered by ambient energy [32], and used in
many smart space scenarios. Others see ramping up the power associated with one-inch devices dramatically.
In either scenario, it is essential that the network sensor design regime be subjected to the same rigorous,
workload-driven, quantitative analysis that allowed microprocessor performance to advance so dramatically
over the past 15 years. It should not be surprising that the unique characteristics of this regime give rise to
very different design trade-offs than current general-purpose systems.
1

This paper provides an initial exploration of system architectures for networked sensors. The investigation
is grounded in a prototype “current generation” device constructed from off-the-shelf components. Other
research projects [38, 5] are trying to compress this class of devices onto a single chip; however, the key
missing technology is the system support to manage and operate the device. To address this problem, we
have developed a tiny microthreaded OS, called TinyOS, on the prototype platform. It draws strongly on
previous architectural work on lightweight thread support and efficient network interfaces. While working
in this design regime two issues emerge strongly: these devices are concurrency intensive - several different
flows of data must be kept moving simultaneously, and the system must provide efficient modularity -
hardware specific and application specific components must snap together with little processing and storage
overhead. We address these two problems in the context of current network sensor technology and our tiny
microthreaded OS. Analysis of this solution provides valuable initial directions for architectural innovation.
Section 2 outlines the design requirements that characterize the networked sensor regime and guide our
microthreading approach. Section 3 describes our baseline, current-technology hardware design point. Sec-
tion 4 develops our TinyOS for devices of this general class. Section 5 evaluates the effectiveness of the design
against a collection of preliminary benchmarks. Section 6 contrasts our approach with that of prevailing
embedded operating systems. Finally, Section 7 draws together the study and considers its implications for
architectural directions.
2 Networked Sensor Characteristics
This section outlines the requirements that shape the design of network sensor systems; these observations
are made more concrete by later sections.
Small physical size and low power consumption: At any point in technological evolution, size and power
constrain the processing, storage, and interconnect capability of the basic device. Obviously, reducing the
size and power required for a given capability are driving factors in the hardware design. At a system level,
the key observation is that these capabilities are limited and scarce. This sets the background for the rest
of the solution, which must be austere and efficient.
Concurrency-intensive operation: The primary mode of operation for these devices is to flow information from
place to place with a modest amount of processing on-the-fly, rather than to accept a command, stop, think,
and respond. For example, information may be simultaneously captured from sensors, manipulated, and
streamed onto a network. Alternatively, data may be received from other nodes and forwarded in multihop
routing or bridging situations. There is little internal storage capacity, so buffering large amounts of data
between the inbound and the outbound flows is unattractive. Moreover, each of the flows generally involve a
large number of low-level events interleaved with higher-level processing. Some of these events have real-time
requirements, such as bounded jitter; some processing will extend over many such time-critical events.
Limited Physical Parallelism and Controller Hierarchy: The number of independent controllers, the capabil-
ities of the controllers, and the sophistication of the processor-memory-switch level interconnect are much
lower than in conventional systems. Typically, the sensor or actuator provides a primitive interface direct-
ly to a single-chip microcontroller. In contrast, conventional systems distribute the concurrent processing
associated with the collection of devices over multiple levels of controllers interconnected by an elaborate
bus structure. Although future architectural developments may recreate a low duty-cycle analog of the
conventional federation of controllers and interconnect, space and power constraints and limited physical
configurability on-chip are likely to retain the need to support concurrency-intensive management of flows
through the embedded microprocessor.
Diversity in Design and Usage: Networked sensor devices will tend to be application specific, rather than
general purpose, and carry only the available hardware support actually needed for the application. As
there is a wide range of potential applications, the variation in physical devices is likely to be large. On
any particular device, it is important to easily assemble just the software components required to synthesize
the application from the hardware components. Thus, these devices require an unusual degree of software
2

modularity that must also be very efficient. A generic development environment is needed which allows spe-
cialized applications to be constructed from a spectrum of devices without heavyweight interfaces. Moreover,
it should be natural to migrate components across the hardware/software boundary as technology evolves.
Robust Operation: These devices will be numerous, largely unattended, and expected to be operational a large
fraction of the time. The application of traditional redundancy techniques is constrained by space and power
limitations. Although redundancy across devices is more attractive than within devices, the communication
cost for cross device redundancy is prohibitive. Thus, enhancing the reliability of individual devices is
essential. This reinforces the need for efficient modularity: the components should be as independent as
possible and connected with narrow interfaces.
3 Example Design Point
To ground our system design study, we have developed a small, flexible networked sensor platform that
expresses many of the key characteristics of the general class and represents the various internal interfaces
using currently available components [34]. A photograph and schematic for the hardware configuration of
this device appear in Figure 1. It consists of a microcontroller with internal flash program memory, data
SRAM and data EEPROM, connected to a set of actuator and sensor devices, including LEDs, a low-power
radio transceiver, an analog photo-sensor, a digital temperature sensor, a serial port, and a small coprocessor
unit. While not a breakthrough in its own right, this prototype has been invaluable in developing a feel for
the salient issues in this design regime.
3.1 Hardware Organization
The processor within the MCU (ATMEL 90LS8535) [2], which conventionally receives so much attention, is
not particularly noteworthy. It is an 8-bit Harvard architecture with 16-bit addresses. It provides 32 8-bit
general registers and runs at 4 MHz and 3.0 V. The system is very memory constrained: it has 8 KB of flash
as the program memory, and 512 bytes of SRAM as the data memory. The MCU is designed such that a
processor cannot write to instruction memory; our prototype uses a coprocessor to perform that function.
Additionally, the processor integrates a set of timers and counters which can be configured to generate
interrupts at regular time intervals. More noteworthy are the three sleep modes: idle, which just shuts off
the processor, power down, which shuts off everything but the watchdog and asynchronous interrupt logic
necessary for wake up, and power save, which is similar to the power down mode, but leaves an asynchronous
timer running.
Three LEDs represent analog outputs connected through a general I/O port; they may be used to display
digital values or status. The photo-sensor represents an analog input device with simple control lines. In
this case, the control lines eliminate power drain through the photo resistor when not in use. The input
signal can be directed to an internal ADC in continuous or sampled modes.
The radio is the most important component. It represents an asynchronous input/output device with hard
real time constraints. It consists of an RF Monolithics 916.50 MHz transceiver (TR1000) [10], antenna, and
collection of discrete components to configure the physical layer characteristics such as signal strength and
sensitivity. It operates in an ON-OFF key mode at speeds up to 19.2 Kbps. Control signals configure the
radio to operate in either transmit, receive, or power-off mode. The radio contains no buffering so each bit
must be serviced by the controller on time. Additionally, the transmitted value is not latched by the radio,
so jitter at the radio input is propagated into the transmission signal.
The temperature sensor (Analog Devices AD7418) represents a large class of digital sensors which have
internal A/D converters and interface over a standard chip-to-chip protocol. In this case, the synchronous,
two-wire I
2
C [40] protocol is used with software on the microcontroller synthesizing the I
2
C master over
general I/O pins. In general, up to eight different I
2
C devices can be attached to this serial bus, each with
a unique ID. The protocol is rather different from conventional bus protocols, as there is no explicit arbiter.
3

Component Active (mA) Idle (mA) Inactive (µ A)
MCU core (AT90S8535) 5 2 1
MCU pins 1.5 - -
LED 4.6 each - -
Photocell .3 - -
Radio (RFM TR1000) 12 tx, 4.5 rcv - 5
Temp (AD7416) 1 0.6 1.5
Co-proc (AT90LS2343) 2.4 .5 1
EEPROM (24LC256) 3 - 1
Table 1: Current per hardware component of baseline networked sensor platform. Our prototype is powered by an
Energizer CR2450 lithium battery rated at 575 mAh [30]. At peak load, the system consumes 19.5 mA of current,
or can run about 30 hours on a single battery. In the idle mode, the system can run for 200 hours. When switched
into inactive mode, the system draws only 10 µA of current, and a single battery can run for over a year.
Bus negotiations must be carried out by software on the microcontroller.
The serial port represents an important asynchronous bit-level device with byte-level controller support. It
uses I/O pins that are connected to an internal UART controller. In transmit mode, the UART takes a
byte of data and shifts it out serially at a specified interval. In receive mode, it samples the input pin for a
transition and shifts in bits at a specified interval from the edge. Interrupts are triggered in the processor
to signal completion events.
The coprocessor represents a synchronous bit-level device with byte-level support. In this case, it is a very
limited MCU (AT90LS2343 [2], with 2 KB flash instruction memory, 128 bytes of SRAM and EEPROM)
that uses I/O pins connected to an SPI controller. SPI is a synchronous serial data link, providing high speed
full-duplex connections (up to 1 Mbit) between various peripherals. The coprocessor is connected in a way
that allows it to reprogram the main microcontroller. The sensor can be reprogrammed by transferring data
from the network into the coprocessor’s 256 KB EEPROM (24LC256). Alternatively the main processor can
use the coprocessor as a gateway to extra storage.
Future extensions to the design will include the addition of battery strength monitoring via voltage and
temperature measurements, radio signal strength sensor, radio transmission strength actuator, and a general
I
2
C sensor extension bus.
3.2 Power Characteristics
Table 1 shows the current drawn by each hardware component under three scenarios: peak load when active,
load in “idle” mode, and inactive. When active, the power consumption of the LED and radio reception are
about equal to the processor. The processor, radio, and sensors running at peak load consume 19.5 mA at 3
volts, or about 60 mW. (If all the LEDs are on, this increases to 100 mW.) This figure should be contrasted
with the 10 µA current draw in the inactive mode. Clearly, the biggest savings are obtained by making
unused components inactive whenever possible. The system must embrace the philosophy of getting the
work done as quickly as possible and going to sleep.
The minimum pulse width for the RFM radio is 52 µs. Thus, it takes 1.9 µJ of energy to transmit a single bit
of one. Transmitting a zero is free, so at equal DC balance (which is roughly what the transmitter requires
for proper operation), it costs about a 1 µJ to transmit a bit and 0.5 µJ to receive a bit. During this time,
the processor can execute 208 cycles (roughly 100 instructions) and can consume up to .8 µJ. A fraction of
this instruction count is devoted to bit level processing. The remainder can go to higher level processing
(byte-level, packet level, application level) amortized over several bit times. Unused time can be spent in
idle or power-down mode.
To broaden the coverage of our study, we deploy these networked sensors in two configurations. One is a
4

Coprocessor
AT90L2313
EEPROM
SPI
Serial
Port
UART
ADC
Light Sensor
Pwr
data
IO pins
Temp
AD7418
IO pins
I2C
RFM TR100
916 MHz transceiver
IO pins
Ctrl
TX
RX
LEDs
IO pins
Inst.
Register
Pgm. mem.
(flash)
Inst.
Decoder
PC
SRAM
Regs
SR
ALU
SP
EEPROM
Int
unit
Timer
Unit
Reference
Voltage
4 MHz
clock
TX
RX
I2C
SPI
AT 90LS8535
32.768 MHz
clock
8bit data bus
Ctrl lines
Figure 1: Photograph and schematic for representative network sensor platform
5

Frequently asked questions

Q1. What contributions have the authors mentioned in the paper "System architecture directions for networked sensors" ?

To this end, the authors identify key requirements, develop a small device that is representative of the class, design a tiny event-driven operating system, and show that it provides support for efficient modularity and concurrency-intensive operation. 

Q2. What is the basic microcontroller building block?

The basic microcontroller building block includes not just memory and processing, but non-volatile memory and interface resources, such as DAC, ADCs, UARTs, interrupt controllers, and counters. 

Q3. What is the function of the radio byte?

If the byte transmission is complete, then the Radio Byte will propagate the TX bit evt signal to the packet-level controller through the TX byte done event. 

Q4. What is the role of the packet component?

The Packet component internally acts as a data drain, handing bytes down to the Radio Byte component whenever the previous byte transmission is complete. 

Q5. How many times per second can the authors multi-task between these execution contexts?

the authors need to be able to multi-task between these execution contexts at a rate of 40,000 switches per second, or twice every 50 µs - once to service the radio and once to perform all other work. 

Q6. How many bytes does their scheduler require?

In particular, their scheduler only occupies 178 bytes and their complete network sensor application requires only about 3KB of instruction memory. 

Q7. What is the purpose of thread scheduling?

The run-to-completion semantics of threads make it possible to allocate a single stack that is assigned to the currently executing thread. 

Q8. What is the message handler doing when the receiver is an intermediate hop?

If the receiver is an intermediate hop on the way to the base station, the message handler initiates the retransmission of the message to the next recipient. 

Q9. What is the function of the radio byte component?

Radio Byte prepares for transmission by putting the RFM component into the transmission state (if appropriate) and scheduling the encode thread to prepare the byte for transmission. 

Q10. What is the need for a generic development environment?

A generic development environment is needed which allows specialized applications to be constructed from a spectrum of devices without heavyweight interfaces. 

Q11. What is the purpose of the thread scheduler?

Once the queue is empty, another thread can be scheduled only as a result of an event, thus there is no need for the scheduler to wake up until a hardware event triggers activity. 

Q12. What are some examples of applications that exploit the modular structure of their system?

These include source based multi-hop routing applications, active-badge-like [44] location detection applications and sensor network monitoring applications. 

Q13. What are the main issues that emerge strongly in the design regime?

While working in this design regime two issues emerge strongly: these devices are concurrency intensive - several different flows of data must be kept moving simultaneously, and the system must provide efficient modularity - hardware specific and application specific components must snap together with little processing and storage overhead. 

Q14. What is the description of pOSEK?

for example, provides a task-based execution model that is statically configured to meet the requirements of a specific application. 

Q15. How much CPU time would be saved by hardware?

Table 4 shows that hardware support for the byte level collection of data from the radio would save us a total of about 690 µJ per bit in processor overhead. 

Q16. What is the expensive operation for interrupt handling?

Though the hardware operations for handling interrupts are fast, the software operations that save and restore registers in memory impose a significant overhead. 

Q17. What is the typical component for a message handling component?

A typical component including a frame, event handlers, commands and threads for a message handling component is pictured in Figure 2. 

Q18. What is the purpose of a command and event?

Both commands and events are intended to perform a small, fixed amount of work, which occurs within the context of an executing thread.