Portability Anchor
4.6 Evaluation
4.6.4 Controlling Abstraction Costs
mostly stateless, because it normally just wires the interfaces between the different chips on the platform, without any significant intermediate buffering that would require significant data memory allocation.
Summary
The presented evaluation confirms the successful implementation of the horizontal decoupling principles of the portability anchor in the TinyOS codebase. The selected test applications cover the major hardware subsystems on a typicalWSNnode. For all of them, and across the three evaluated metrics, the results show high levels of portability, with the platform-independent chip components clearly dominating the platform-specific binding and configuration components.
Given the significant degree of hardware component reuse on the typicalWSN
platforms (Section2.2), these facts support our claim that the horizontal decompo-sition establishes a useful architectural base for a more efficient platform porting process.
20 ms
1 ms
-90◦
20 ms
1.5 ms
0◦
20 ms
2 ms
90◦
Figure 4.17:PWMsignal waveforms for servo motor control.
angle of the motor is controlled via the width of the control pulse at the beginning of the control period. A pulse with a duration of 1.5 ms keeps the servo lined-up (0◦).
Any shorter/longer pulse than 1.5 ms makes the servo motor turn left/right. The lower and the upper limits are 1 ms and 2 ms, respectively: a pulse with a duration of 1 ms makes the servo turn full left (-90◦), and a pulse with a duration of 2 ms turns the servo full right (90◦).
The millisecond-resolution of the platform-independent Timer interface (Fig-ure4.9) is insufficient to support the needs of a realistic servo motor control ap-plication, where the control pulse duration can dynamical vary between 1 ms and 2 ms. Our goal is to compare the fidelity of the timer abstractions at theHILand the
HALlevel, thus, we have constrained the requirements of the test application to the generation of a fixed control waveform that keeps the servo motor turning full right.
In other words, the objective is to generate as precisely as possible, a control signal waveform with a pulse width of 2 ms and a period of 20 ms, under moderately high dynamic loadin the system.
We have based the implementation on the standardRadioCountToLedsapplication (Section4.6.1), using the telosb platform as a target. To emulate higher dynamic load in the system, we have modified the message sending frequency from the default one message every 250 ms, to sending one message per uniform random interval with maximal duration of 50 ms.
In parallel to the message sending, the application generates the requiredPWM
control signal on a GPIO pin of theMCU. The application is implemented in two variants described in more detail below: a platform-independent variant using only
HILinterfaces, and a platform-specific variant that uses aHALlevel timer abstraction.
Platform-Independent The platform-independent implementation uses two Timers for timing the period and pulse duration of thePWMsignal:
module RadioCountToLedsC @safe ( ) { uses {
. . .
i n t e r f a c e GeneralIO as ControlPin ; i n t e r f a c e Timer<TMilli > as TimerPeriod ; i n t e r f a c e Timer<TMilli > as TimerPulse ; }
}
On system boot, after initializing the control pin, a periodicTimerPeriodis started with a 20 ms period:
event void Boot . booted ( ) { . . .
c a l l ControlPin . makeOutput ( ) ; c a l l TimerPeriod . s t a r t P e r i o d i c ( 2 0 ) ; }
When TimerPeriod fires, the control pin is set high, and a 2 ms one-shotTimerPulse is scheduled:
event void TimerPeriod . f i r e d ( ) { c a l l ControlPin . s e t ( ) ;
c a l l TimerPulse . startOneShot ( 2 ) ; }
When TimerPulse fires, the control pin is driven low, which concludes the gener-ation of the pulse:
event void TimerPulse . f i r e d ( ) { c a l l ControlPin . c l r ( ) ;
}
The whole process is repeated on the next TimerPeriod firing, thus generating the required control waveform on theGPIOControlPin.
Platform-Specific In contrast to the portable implementation, the platform-specific variant uses streamlinedHALlevel access to the timing system abstraction for the performance sensitive parts. Instead of two Timers, this implementation uses two Alarms(Figure4.8):
module RadioCountToLedsC @safe ( ) { uses {
. . .
i n t e r f a c e GeneralIO as ControlPin ;
i n t e r f a c e Alarm<TMilli , uint16_t > as AlarmPeriod ; i n t e r f a c e Alarm<TMilli , uint16_t > as AlarmPulse ; }
}
For easier comparison between the independent and the platform-specific implementation, theAlarmPeriodandAlarmPulsealso have a millisecond-precision like theHILTimer interfaces. While this is sufficient for generating the fixed 2 ms pulses required by the test application, a real servo motor control code would leverage Alarms with microsecond or 32 kHz (jiffy) precision.
Since the Alarm interface does not support periodic Alarms, on system boot only a single-shot 20 ms AlarmPeriod is started:
event void Boot . booted ( ) { . . .
c a l l ControlPin . makeOutput ( ) ; c a l l AlarmPeriod . s t a r t ( 2 0 ) ; }
When AlarmPeriod fires, in addition to setting the ControlPin, the Alarm is manually rescheduled, anchored at the last firing time, and a new 2 ms AlarmPulse is started, for timing the duration of the control pulse:
async event void AlarmPeriod . f i r e d ( ) { c a l l ControlPin . makeOutput ( )
c a l l AlarmPeriod . s t a r t A t (c a l l AlarmPeriod . getAlarm ( ) , 20) ; c a l l AlarmPulse . s t a r t ( 2 ) ;
}
Finally, when AlarmPulse fires, the ControlPin is cleared:
async event void AlarmPulse . f i r e d ( ) { c a l l ControlPin . c l r ( ) ;
}
The whole process is repeated on the next AlarmPeriod firing. As a result, the requiredPWMsignal waveform is reflected on the selectedGPIOpin of theMCU. 4.6.5 Portability/Fidelity Trade-offs
The above code snippets illustrate how the portability anchor provides convenient domain-specific abstractions for controlling the underlying hardware timers, both at
HILandHALlevel. Although their interfaces are very similar, however, the Timers and Alarms encapsulate two very different levels of abstraction, acting as lever for controlling the trade-offs between portability and fidelity in the hardware abstraction code.
As discussed in Section4.5.3, the portability of the Timer abstraction comes at the cost of higher sensibility to other synchronous code, because its implementation includes deferred processing using tasks which run to completion and can not be preempted by other tasks. The Alarm abstraction, on the other hand, offers a stream-lined access to the hardware timers in interrupt context, but at the cost of reduced portability.
To demonstrate the portability/fidelity trade-offs resulting from the use of the
HILand theHALinterfaces, we experimentally evaluated the two implementation
variants, focusing on the jitter in the generated control signal, because this ultimately bounds the quality of control over the actuator.
In each experiment, the platform-independent and the platform-specific variants have been evaluated for the duration of 1024 generated control cycles. The experi-ments have been repeated using five different seeds for the random number generator that controls the message sending frequency and thus the dynamic background load.
During the experiment runs, the signal produced on theGPIOpin was captured using a high-speed digitizer and the waveform was post-processed to extract the durations of each period and pulse.
To analyze the jitter in the generated waveform, we have calculated the median and the outer 0.025 and 0.975 quantiles for the extracted pulse and period durations.
Figure4.18and Figure4.19show the results from the analysis of the pulse and the period jitter, respectively. Each point on the graph represents the duration of the pulse/period for a single control cycle. The rectangle depicts the area between the outer quantiles containing 95 % of the readings, while the thick horizontal line is the median duration. The vertical time axis is expressed in binary milliseconds.
Figure 4.18: Differences inPWMcontrol fidelity: jitter in the pulse duration.
Although majority of the pulse and period durations are clustered closely around the median, in the platform-independentHILimplementation, significant jitter is evident, making precise control of the servo motor almost impossible. We can observe high level of clustering in the durations, indicating that the observed jitter is predominantly caused through the interference between the message sending task and the task in the HILimplementation of the Timers. As the Timer task can not
Figure 4.19: Differences inPWMcontrol fidelity: jitter in the period duration.
be run before the other task finishes, this results in delayed TimerPeriod and/or TimerPulse fire events. This in turn, introduces jitter in the duration of the generated pulses and periods.
In contrast, the two Alarms at theHALlevel enable much more stable timing, re-sulting in very good fidelity of the control signal. In this case, the timing is performed in interrupt context. Even if the Alarm expires while message sending tasks are being run, their execution can be interrupted and the time-sensitive alarm rescheduling and
GPIOcontrol can be executed without significant delay. The small remaining jitter in the signal is due to atomic blocks in the task implementation during which interrupt servicing is disabled, and the fact that the current msp430 chip implementation prevents interrupt nesting.
The difference in the service fidelity between the two implementations vari-ants demonstrates the need for streamlined access to the underlying hardware in performance-sensitive parts ofWSNapplications. It shows that changing only a small part of a portable implementation to use the more efficientHALinterfaces can result in significant gains in performance. Switching thePWMsignal timing fromHILto
HALlevel services in the test application required changing only 12SLOC(most of them substring changes from “Timer” to “Alarm”), representing less than 10 % of the code in the application level components, and a negligible fraction of the total RadioCountToLeds implementation that has more than 10000SLOC.
CHAPTER
5
Interoperability Anchor
In this chapter we present the design, implementation and evaluation of the interoper-ability anchorofDASAthat exports an interoperableCBPSservice, while allowing the application designer to adapt the service by making orthogonal choices about the communication components for subscription and notification delivery, the supported data attributes, and a set of service extension components. The framework uses an extended attribute-based naming scheme which is augmented with metadata containing soft requirements for the publishers and run-time control information for the service extension components. It supports different addressing schemes and interaction patterns.