7/29/2019 p83-beck

1/5

Shaping TinyOS to Deal with

Evolving Device Architectures:Experiences Porting TinyOS-2.0 to the Chipcon CC2430

Nicholas Beck

Faculty of CEMSUniversity of the West of England, Bristol

nbeck@nixtems.co.uk

Ian Johnson

Faculty of CEMSUniversity of the West of England, Bristol

irj@acm.org

ABSTRACTThis paper outlines the issues involved and difficulties

encountered porting TinyOS to the CC2430 System-on-Chipplatform. Core issues that limit the portability of TinyOS-2.x

are identified, and suggestions made as to how these might beaddressed. Specifically, TinyOSs reliance on the GNUCompiler Collection being available for the wireless sensor

network device, the use of connection-dependent abstractionsand their impact on system-on-chip devices, and the reuse ofcomponents within chip families. The issues are associatedwith both TinyOS-2.0 andthe nesC language that it is written

in.

Categories and Subject DescriptorsD.2.7 [Software Engineering]: Distribution, Maintenance,

and Enhancement Portability.

D.2.11 [Software Engineering]: Software Architectures TinyOSarchitecture, component reuse.

General TermsManagement, Design, Standardization, Languages.

Keywords

Sensor networks, TinyOS-2.x, nesC, CC2430, System-on-Chip, unsupported toolchain.

1. INTRODUCTIONThe wireless sensor network (WSN) literature covers

extensively unintegrated hardware, such as the Telos [1]family of motes developed by UC Berkley. Whilst such

platforms are of interest for research into operating system,application level, or routing issues, they offer limited potentialfor real world deployment due to their unintegrated electronicdesign, large physical size, and relatively high powerconsumption. In addition, the relatively high cost of such

motes makes research into wireless sensor networks consistingof say, over one thousand nodes prohibitively expensive.

Fully integrated system-on-chip (SoC) devices are now

available which offer much better performance.

Much research in this field involves the development ofapplications using the TinyOS [2] operating system. TinyOSenjoys a symbiotic relationship with the application beingdeveloped, nesC, and the GNU Compiler Collection (gcc).

As a precursor to further work, the authors determined to port

TinyOS to a second generation platform, namely the ChipconCC2430. Hardware such as this device offers a number of

advantages over existing platforms. Such devices are capableof being deployed in extremely small footprint devices, have a

reduced complexity for their circuit design, and potentially anultra-low power consumption. (Wake on interrupt or real-time

clock draws 500 A @ 3.0V.)

2. THE CC2430 DEVICEThe CC2430 [3] is a single chip solution for developingwireless sensor networks. The device has two keycomponents: an enhanced 8051 microcontroller together with

a CC2420 802.15.4 radio transceiver core. It was chosensince the CC2420 has been amongst the most popularcomponents reported in TinyOS platforms. The significantnegative for TinyOS development on this platform is the lack

of a gcc compiler. The 8051 is probably the most commonlydeployed microcontroller core; however gcc cannot be easilyor efficiently ported to it.

3. ACHEIVEMENTS TO DATEDevelopment has been undertaken using the Chipcon

CC2430DK development kit, consisting primarily of CC2430evaluation modules and SmartRF04EB evaluation/sensor

boards.

At the time of writing the following work has been completed:

Integration of the IAR 8051 compiler into the buildprocess.

GPIO & GPIO Interrupts.

Timers

Analogue-to-Digital Converter

UART

Software I2C

LEDs

LCD panel

Buttons

Potentiometers

Analogue joystick

It is the authors intention to port the integrated CC2420 radio

shortly; a discussion of some of the issues discovered withSoC devices is presented later in this document.

Additionally, a custom sensor board for the CC2430 has beendesigned and fabricated to allow experimentation in a number

Permission to make digital or hard copies of part or all of this workfor personal or classroom use is granted without fee provided thatcopies are not made or distributed for profit or commercial advantageand that copies bear this notice and the full citation on the firstpage. To copy otherwise, to republish, to post on servers or toredistribute to lists, requires prior specific permission and/or a fee.

EmNets'07, June 25-26, 2007, Cork, IrelandCopyright 2007 ACM ISBN 978-1-59593-694-3/07/06...{5}.00

83

7/29/2019 p83-beck

2/5

of application classes and research areas on completion of the

port.

4. DIFFICULTIES ENCOUNTEREDA number of difficulties have been encountered during the

course of this work, some of which have affected otherresearch groups in their attempt to port TinyOS-1.x to an8051-based architecture [4][5]. TinyOS-2.0, commonlyreferred to as T2, addresses some of the issues faced by these

groups, and presents some new ones.

The lack of flexibility the TinyOS 8051 Working Group [4]experienced with the clock interface in the TinyOS-1.x core isnot an issue in T2. The rigid standardized interfaces combined

with the single-level Hardware Abstraction Layer (HAL)meant that core interfaces and components had to be modified

specifically for the Nordic Semiconductor nRF24E1 that wasused. Generic interfaces allow instances of interfaces that have

the same methods but different parameter types to be used,this effectively creates a standardized interface that allowsmultiple precisions. This eliminates the need to modify the

core timer interfaces and components which [4] foundnecessary in TinyOS-1.x. The three-level Hardware

Abstraction Architecture [17] enables platforms to provideinterfaces that are chip or platform specific, these take full

advantage of the hardware and standardized platformindependent interfaces for use by higher level components. T2

provides chip dependent alarms and platform independentvirtualized timers [6].

4.1 The TinyOS Build ProcessWhilst specific reference to the 8051 has been made, theissues discussed in this section are applicable to virtually allarchitectures without a gcc variant.

The following issues will further manifest themselves infuture mote architectures. A number of research institutionsare developing SoC motes with architectures designed and

targeted specifically for WSNs [7] [8], due to the power, size,

and cost advantages this yields. [9] and [10] identify thepower-aware CoolRisc, eCog1, HCS08, and 8051 processorcores as potential candidates for SoC WSN devices, of whichonly CoolRisc has a gcc variant, whilst others are developingcustom processor cores [7]. Some of these new architecturesare likely to have instruction set architectures (ISAs), register

sets, or memory layouts that gcc does not suit.

It is important to consider that future device architectures areunknown, which implicitly means TinyOS must support theuse of arbitrary target compilers if it is to be adopted on such

platforms.

The lack of gcc for the 8051 prevents straight forwardcompilation of TinyOS applications. Currently the nesC

compiler only supports gcc-specific C extensions, where all

8051 C compilers each have their own specific extensions.Additionally, there is an assumption that certain C99

compliant features exist, such as inline and uint64_t. A C99compliant C compiler does not exist for the 8051.Furthermore, the C99 standard [11] states that some data

types, including unit64_t, are not mandatory. Although a fewC99 extensions are provided by some compilers, adding

support for a compilers specific extensions does notcircumvent the need to modify the build process; a syntax

translation script is required to workaround C99 assumptionsin core components.

The above factors necessitate modifications to the build

process. The inclusion of an additional step in the compilationprocess is required to translate the syntax, of the C file

generated by the nesC compiler, between that of gcc and thetarget compiler. In addition to this a number ofhacks must beperformed, so that meta-data can be passed through the pre-processor and nesC compiler, in order to fulfill the syntaxrequirements of the target compiler; this problem is

exacerbated by generic components in T2.

The need for syntax translation has been encountered by allgroups working with TinyOS for the 8051 and has been

addressed in much the same way; an additional stage in thecompilation process, shown in Figure 1. However, theapproaches taken to integrate the script and target compiler

into the build process differ. This script, which acts as a nesCpost-processor, performs the required syntax translation.

Figure 1: Modified TinyOS Build System for the CC2430

A number of syntax modifications required for the Keil 8051compiler are identified by [4], some of these are no longerrequired thanks to modifications to the nesC compiler. The$ identifier can be substituted for a user-specified one, andthere is the facility to turn off inlining with another nescc

option, however currently this prefixes the inline keywordwith __ rather than physically removing it.

The issues caused by the relationship between the nesC and

gcc compilers have similarly affected groups porting TinyOSto other architectures without gcc [12].

Every 8051 C compiler has a compiler-specific extension for

declaring the MCUs special function registers (SFRs), as canbe seen in Table 1, this is required so that the correct memorysegment and addressing mode are used. The syntax for

declaring SFRs with gcc for the AVR family of MCUs is alsoincluded for comparison. Due to the special declaration of

SFRs for the 8051 there is a requirement for both the nameand address of the register to be passed through the nesC

compiler, so that the syntax translation script can create thecorrect output for the target compiler. The SFR declarationtechnique used for AVRs is not suitable, pre-processing willremove the SFRs name, resulting in the translation script

84

7/29/2019 p83-beck

3/5

having insufficient information to create the required syntax

for the target compiler.

Table 1: Comparison of Register Declarations

8051 SFR declaration in IAR compiler:__sfr __no_init volatile uint8_t P0 @ 0x80;

8051 SFR declaration in SDCC compiler:sfr at 0x80 P0;

8051 SFR declaration in KEIL compiler:sfr P0 = 0x80;

SFR declaration for AVR MCUs with GCC compiler:#define PORTA _SFR_IO8(0x1B)

Which is effectively pre-processed to:(*(volatile uint8_t *)(0x1B + OFFSET))

This issue is further complicated by generic components, theparameters of which must be constant strings or numeric

values. As it is not possible to declare SFRs with #definesthey must be declared as variables, in order to convey both thename and address to the translation script. This prevents SFRsdeclared in this way from being used in generic components,

therefore a hack is required to allow SFRs to be used asarguments to generic components.

This is not a problem isolated to platforms with an 8051processor core, it can even be seen in supported TinyOS

platforms. For example a hack is required to enable the use ofSFRs as arguments to generic components in the atmega128

GPIO components, as shown in Table 2.

Table 2: Atmega128 GPIO Generic Component

Instantiation [13]

Components newHplAtm128GeneralIOPortP((uint8_t)&PORTA,

(uint8_t)&DDRA,(uint8_t)&PINA)as PortA;

The hack used to cast the generic components constant

parameters into AVR formatted SFRs is shown in Table 3.Note that the generic module below is instantiated by a

generic configuration for the motes ports. Also, note that this#define hack is not possible for the 8051, for the reasons

described above.

Table 3: Atmega128 GPIO Generic Component Hack [14]

generic module HplAtm128GeneralIOPinP (uint8_t port_addr,uint8_t ddr_addr,uint8_t pin_addr,uint8_t bit)

{provides interface GeneralIO as IO;

}implementation

{#define pin (*(volatile uint8_t *)pin_addr)#define port (*(volatile uint8_t *)port_addr)#define ddr (*(volatile uint8_t *)ddr_addr)

. . .}

4.2 Hardware Implementation Differencesof SoC DevicesTwo of the SoC devices available on the market are the

Chipcon CC2430 and Nordic Semiconductor nRF24E1. Theradios integrated into these devices are also available as

discrete components; however the integration approach taken

by these manufacturers is very different.

The nRF24E1 has an integrated nRF2401 radio, which isimplemented as an internal SPI bus, the pins of the discrete

nRF2401 are exposed through a single register and the devicefunctions identically. The CC2430s integrated radio, aCC2420, has a number of differences to the CC2420 radio

chip.

The CC2420 chip implementation in TinyOS is decoupledfrom any MCU, allowing it to be used by numerous mote

platforms, however it is dependent on it being connected to anSPI bus. The functionality of the integrated and the standaloneCC2420 radios are very similar (the SoC version actuallyprovides an additional strobe instruction mechanism, but thedevice is capable of behaving identically) but the connection

of the chip and therefore the access methods are completelydifferent; all access to the virtual radio chip on the SoC

device is performed through memory-mapped registers ratherthan SPI. A number of the interfaces used by the CC2420

implementation are platform agnostic, however theconfigurations and module implementations are tied to SPIinterfaces. Also, there are a number of interfaces that are

specific to the standalone CC2420 chip, such as GPIOinterrupts, that are not applicable to the SoC version of the

radio. In its current incarnation the integrated CC2420requires a full variant port to deal with the alternative

connection, as the radios data access methods, strobeinstruction values, and data addresses are different. Becauseof the way that the CC2420 radio abstraction is auto-wired to

SPI interfaces (components in the abstraction are wired withinthe the abstractions configurations, leaving the user of the

abstraction to wire only the external interfaces; the radioeffectively becomes a single component), every configuration

in the current abstraction is unsuitable.

5. PROPOSED SOLUTIONSThrough a number of modifications to nesC and TinyOS the

portability limitations that currently exist can be eliminated.

5.1 NesC ModificationsAs discussed in the previous sections, processor cores withoutgcc require a syntax translation script to modify the syntax ofthe generated C file to that of the target compiler. We propose

that the same method is used, but is formalized so thatarbitrary compilers can be invoked by the TinyOS build

process in a uniform manner.

NesC currently supports attributes, the intended purpose ofwhich is to allow user-specified annotations which areaccessible to external tools, whilst avoiding burdening thesyntax through reservation of lots of keywords [15]; onlydeclarations and definitions, either C or nesC, can be

annotated with attributes. All attributes are stripped from theapplication by the nesC compiler and are accessible through

an XML-formatted dump.

Through the addition of an option to nescc that allowsattributes to be passed through the compiler (attributes would

be included in the generated C file) the syntax translationscript, described above, has all of the information that itrequires to generate a syntactically correct C file for the targetcompiler. The translation script would be responsible forremoving the attributes before the target compiler is invoked

to build the executable.

85

7/29/2019 p83-beck

4/5

It is suggested that a new nesC attribute is predefined for

registers, see Table 4, this allows compilers other than gcc tobe used cleanly. Additionally, implementation differences

between different compilers for the same processor core, towork around the syntax variations, will be eliminated; forexample, to date SDCC, Keil, and IAR compilers have beenused in efforts to port TinyOS to an 8051 based platform.Also, the hacks used for passing registers as arguments to

generic components can be avoided, whilst retaining full staticanalysis capabilities. This can be achieved by modifying the

rules to allow SFRs annotated with the @register attribute tobe arguments to generic components, further, this could berestricted to the Hardware Presentation Layer (HPL) toprevent misuse.

Table 4: Proposed nesC Attribute for Registers

Struct @register

{

const char *name;

uint32_t address;

};

//Example usage:

#define PORTA 0x1B @register(PORTA, 0x1B);

Taking register annotation as an example there are twomethods in which this could be accomplished. The use of

attributes can be extended such that they can be arbitrarilyplaced in the code; this allows attributes to be added to AVR-style SFR declarations (see Table 1) making this style suitablefor other cores, including the 8051. The alternative is todeclare SFRs as variables within TinyOS, an example of

which can be seen in Table 5, note that compatibility ismaintained with existing code. However this technique

requires additional data memory that is not actually necessary(approximately the equivalent number of bytes consumed bythe SFRs); with specialized nodes potentially havingextremely limited data memory [16] this is not a suitablesolution.

Table 5: Declaring SFRs as Annotated Variablesuint8_t * const SFR_PORTA @register(PORTA, 0x1B) =

(uint8_t *)0x1B;

//PortA access function:compatible with existing code

#define PORTA (*SFR_PORTA)

The benefits of arbitrary attribute placement are not limited to

register definitions. It allows compiler-specific extensioninformation to be inserted more naturally and elegantly than

currently possible through gccs attribute extension. Thiscurrently requires false variables or functions to be declared inorder to attach the meta-data, so it can be passed through thenesC compiler, before being translated by the script into thedesired syntax. Furthermore, when the same meta-data is

required multiple times it is currently necessary to declare adifferent variable for each instance.

5.2 TinyOS ModificationsT2 addresses the three basic limitations of TinyOS-1.x: newplatform support, application support, and reliable operation[17]. T2 enables new platforms to be ported easily, throughthe separation of chip and platform code, what the current

structure fails to attend to is the reuse of components requiredas SoC devices become more prevalent. The authors propose arestructuring of the chips directory and the use of connectionindependent interfaces, which will remove code duplication.

The example structure shown in Figure 2 allows reuse of code

components across chip families and SoC devices. Thestructure provides the flexibility for core-, family-, and

device-specific functional block implementations, and theability to effectively overload the implementation levelthrough configurations that wire the appropriate componentsfrom the various levels together. For instance, the CC2431 iseffectively a CC2430 with device location functionality,

where the vast majority of software components can beshared.

Chipcon ADC

Components

80518051

Chips

80518051

80518051

ARM 7

80518051

ARM 9

80518051

AVR

PowerManagement

UART

80518051

Chipcon /

TI

CC2430.hHplMcs51AdcC.nc

Configuration

80518051

Nordic

Semiconductor

Chipcon SPI

Components

80518051

CC2430

80518051

CC1100

MCUCore

TOS

Chips

Directory

Standard 8051Components &

Silicon Vendor8051 Cores

Silicon VendorSpecific

Components &

Part Specific

Directories

Part Specific

Configurations& Header Files

MCS51

HplMcs51GpioC.nc

Configuration

HplMcs51UartC.nc

Configuration

HplMcs51PowerC.nc

Configuration

Chipcon Power

Management

Components

Legend

80518051

DirectoryComponent(s)

Figure 2: Example Restructured TinyOS-2.x Chip

Directory

Figure 3: Connection Independent CC2420 Chip

Abstraction

As stated above, the current CC2420 radio implementation

uses some connection specific interfaces, we propose that all

interfaces used in the chip components should be connectionagnostic, thereby making the radio abstraction reusable by agreater number of platforms; both traditional mote platforms

that use a discrete CC2420 radio and SoC motes that have anintegrated CC2420 can share the same abstraction, andbecause differences in the components used are minimal,

maintenance remains straightforward.

The low-level implementation varies depending on theconnection method, and the configurations used reflect this;

the aim is to share as many components, in the sameconfiguration as possible. We will take the CC2420 radio as

86

7/29/2019 p83-beck

5/5

an example; a graphical representation can be seen in Figure

3. The standalone form is connected via SPI, the formation ofpackets is specific to this version of the chip and the chip

implementation should handle this, but the implementation forconnecting the chip abstraction to the SPI bus is platformspecific and should be dealt with in the platforms chipdirectory. In its integrated form, access to the CC2420sRAM, registers and strobe commands is platform specific and

in the case of the CC2430 is performed through SFRs. Thelow-level implementation for the integrated form is in the

platforms chip directory. Through the use of a platformspecific configuration the vast majority of configurations andmodule implementations are common to both the standaloneand integrated radio, as can be seen in Figure 3. Thistechnique offers increased generalization through an

additional level of abstraction. However, on platforms wherethis compromises efficiency too greatly a chip directory

structure similar to that shown in Figure 2 can be employed.

6. CONCLUSIONThe three-layer Hardware Abstraction Architecture andseparation of chip specific code, adopted by T2, addresses thedifficulty of porting to new platforms, and prevents a lot of

the code duplication that existed in TinyOS prior to T2. It isappreciated that these are not intended to abstract the featuresof different MCU cores, and that this may be explicitlyaddressed in the future [17], however, the proposals discussedin this document address a number of the core issues limitingthe portability of TinyOS, and provide solutions that enablethe use of TinyOS on present and future mote platforms.

The tightly coupled relationship that currently exists between

nesC and gcc, combined with the necessity of using compilerspecific extensions for developing embedded software leads

the authors to conclude that, in its present condition, TinyOSis not sufficiently portable for the next-generation of WSNdevices. However, this can be rectified through modificationsto nesC and the compilation process, described in thisdocument, which allow the invocation of an arbitrary target

compiler.

Hardware descriptions can mislead easily in the portingprocess. Due to the component based nature of TinyOS, oftenthe communication interface (for example the SPI bus) is

integrated into the module that supports a particularcomponent (for example the CC2420 802.15.4 radio). In such

cases changing the access method (for example device specificregisters) can lead to the necessity of a full variant port of thatcomponent. By only using connection agnostic interfaces theimpact of SoC devices, with respect to changes to

configurations and module implementations, is minimized.

Without some substantial changes porting TinyOS to a non-gcc supported platform is likely to remain extremelychallenging.

7. REFERENCES

[1] J. Polastre, R. Szewczyk, D. Culler Telos: EnablingUltra-Low Power Wireless Research, IPSN 2005: 364-369,April 25-27, Los Angeles 2005.

[2] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, KPister, System architecture directions for network

sensors, ASPLOS 2000, Cambridge, November 2000.

[3] Chipcon Data Sheet available from:http://www.chipcon.com/files/CC2430_Data_Sheet_rev2p01.pdf

[4] A. Egeskov Petersen, S. Jensen, M. Leopold, TowardsTinyOS for 8051, TEP121, TinyOS 8051 WorkingGroup, March 2006.

[5] D. Patnode, J. Dunne, A. Malinowski, D. Schertz,

WISENET-TinyOS based wireless network of sensors,Industrial Electronics Society, The 29th AnnualConference of the IEEE, IECON'03. 2003.

[6] C. Sharp, M. Turon, D. Gay, Timers, TEP102, TinyOSCore Working Group, October 2006.

[7] J. Hill, System Architecture for Wireless SensorNetworks, PhD thesis, UC Berkeley, May 2003.

[8] M. Hempstead, N. Tripathi, P. Mauro, G.-Y. Wei, and D.Brooks. An ultra low power system architecture forsensor network applications. In The 32nd Annual

International Symposium on Computer Architecture

(ISCA), June 2005.[9] S. Mahlknecht, J. Glaser, T. Herndl, PAWiS: Towards a

power aware system architecture for a SoC/SiP wirelesssensor and actor node implementation.

[10] A.V. Lorentzen, Low-power processors for the Hogthrobproject, Masters Thesis, Danmarks Tekniske Universitet,December 2004.

[11] ISO/IEC 9899:1999 Standard, WG14N1124, May 2005,available from: http://www.open-

std.org/JTC1/SC22/WG14/www/docs/n1124.pdf[12] C. Lynch, F. OReilly, PIC-based TinyOS

Implementation, presented at the 2004 IT&T AnnualConference, 2004.

[13] Atmega128 GPIO configuration available from:http://tinyos.cvs.sourceforge.net/tinyos/tinyos-2.x/tos/chips/atm128/pins/HplAtm128GeneralIOC.nc

[14] Generic Atmega128 GPIO pins module available from:http://tinyos.cvs.sourceforge.net/tinyos/tinyos-2.x/tos/chips/atm128/pins/HplAtm128GeneralIOPinP.nc

[15] D. Gay, P. Levis, D. Culler, E. Brewer, nesC 1.2Language Reference Manual, August 2005.

[16] J. Hill, M. Horton, R. Kling, L. Krishnamurthy, ThePlatforms Enabling Wireless Sensor Networks,

Communications of the ACM Vol. 47 No. 6, June 2004.[17] P. Levis, D. Gay, V. Handziski, J. Hauer, B. Greenstein,

M. Turon, J. Hui, K. Klues, C. Sharp, R. Szewczyk, J.Polastre, P. Buonadonna, L. Nachman, G. Tolle, D.

Culler, A. Wolisz, T2: A Second Generation OS ForEmbedded Sensor Networks, Technical report,University of California, Berkeley, November 2005.

[18] V. Handziski, J. Polastre, J. Hauer, C. Sharp, A. Wolisz,D. Culler, Flexible Hardware Abstraction for Wireless

Sensor Networks, In Proceedings of the SecondEuropean Workshop on Wireless Sensor Networks (EWSN

2005), Istanbul, Turkey, February 2005.

87