Portability Anchor’s Implementation

Like other mandatory design specifications, the hardware abstraction architecture in TinyOS 2.x is described in TEP2, a “Best Current Practice” TinyOS Enhancement Proposal (TEP) document [79]. The application of the architecture to each hardware subsystem is codified in separateTEPs. They document the design considerations and mandatory specifications for theHILlayer interfaces for a particular hardware subsystem, and provide pointers to reference implementation of these interfaces in the TinyOS 2.x code base.

TEP Title

TEP2 Hardware Abstraction Architecture TEP101 Analog-to-Digital Converters (ADCs) TEP102 Timers

TEP103 Permanent Data Storage (Flash) TEP108 Resource Arbitration

TEP109 Sensors and Sensor Boards

TEP112 Microcontroller Power Management TEP113 Serial Communication

TEP115 Power Management of Non-Virtualized Devices TEP117 Low-Level I/O

TEP126 CC2420 Radio Stack

TEP131 Creating a New Platform for TinyOS 2.x

Table 4.1:TEPsspecifying the hardware abstraction architecture and its implementation in TinyOS 2.x

Due to their platform-specific nature, the organization of theHALlayers is not subject to specification in TEPs. Despite this, the hardware subsystemTEPs often provide useful design suggestions and examples about the organization of theHAL

components on particular platforms. Special focus is put on documenting useful hardware-independent interfaces forHALandHPLcomponents that enable writing platform-independent utility components, that can reduce the porting overhead. A typical example is the Timers TEP, which, in addition to the mandatoryHIL specifica-tion, also documents a utility library for easy development ofHILandHALabstractions on different hardware. Table4.1provides an overview of the currentTEPsthat relate to the specification and application of the hardware abstraction architecture.

Level of Portability

According to the portability anchor specification, theHILinterfaces should provide fullhardware independence. The specification, however, defines the requiredAPI

only at source code level and can effectively only mandate source code portability, like thePOSIXinterfaces.

In real-life use of theHILabstractions, the expectedbehaviorof the portable code written on top of theHILabstractions plays equally important role as the code porta-bility. To differentiate between thoseHILabstractions that guarantee both source code and behavioral portability and the ones that only guarantee source code portability, the TinyOS 2.x community uses the concepts of “StrongHIL” and “WeakHIL” with the following meaning:

StrongHILs indicates that “portable code using these abstractions can reasonably be expected to behave the same on all implementations”, which matches the origi-nal definition of theHILlevel according toDASA. Examples include theHILfor the timer (TimerMilliC, TEP102), forLEDs(LedsC), active messages (ActiveMes-sageC, TEP116), sensor wrappers (DemoSensorC, TEP109), storage (TEP103), etc. StrongHILsmay use platform-defined types if they also encapsulate their modification (i.e., they are platform-defined abstract data types), for example, the TinyOS 2.x message buffer abstraction,message_t(TEP111).

WeakHILs indicates that “portable code using these abstractions might exhibit platform-specific behavior”. For example, the existingADCabstraction requires platform-specific configuration and the returned data must be interpreted in light of this configuration. The ADC configuration is exposed on all plat-forms through theAdcConfigureinterface that takes a platform-defined type, adc_config_t, as a parameter. However, the returnedADCdata may be processed in a platform-independent way, for example, by calculating the max/min or mean of multipleADC readings. So despite this platform-specific behavior, weakHILsstill enable writing portable utility code, e.g., a repeated sampling for anADCon top of the normal single-sample interface.

Code Organization

To provide the necessary context for the examples and the evaluation in the rest of the chapter, we briefly review the organization of the TinyOS 2.x code-base (Figure4.5) and the association between its directory structure and the vertical and horizontal decoupling principles of the portability anchor.

$TOSROOT

apps doc support tools tos

types chips platforms sensorboards interfaces system lib

Figure 4.5: Directory structure of the TinyOS 2.x code-base.

• /appscontains a collection of standard independent and platform-specific applications used for demonstration and release testing.

• /toscontains the core components of theOSincluding the ones for hardware abstraction, organized as follows:

– /tos/chipscontains the platform-independent, chip-specific abstractions of all supported hardware chips in theOS, following the horizontal de-composition. Each of these chip-specific abstraction, in turn, is comprised of a collection of components resulting from the three-level decomposi-tion of the abstracdecomposi-tion funcdecomposi-tionality, following the vertical decomposidecomposi-tion principle.

– /tos/platformscontains the platform-specific, chip-independent com-ponents for all supported hardware platforms, following the horizon-tal decomposition. Each/tos/platformssubdirectory contains a special

“.platform” definition file that specifies the list of platform-independent chip abstractions and platform-specific “glue” components that comprise the platform.

– /tos/interfacescontains the systemOSinterfaces and the platform-inde-pendentHILinterfaces for all hardware subsystems, in effect specifying the top-level signature of the portability anchor as implemented in TinyOS 2.x.

– /tos/systemcontains basic system components like the scheduler and platform-independentHILwrapper components.

– /tos/libcontains component libraries for different aspects of the system, including reusable utility code for buildingHILandHALabstractions, like the already mentioned timer library, in /tos/lib/timer, or the power manager library, in/tos/lib/power.