TinyOS 2 xTinyOS 2.x

WCNG PresentationTuesday October 16th, 2007Chris MerlinChris Merlin

Wh Ti OS 2 ?[1]Why TinyOS 2.x?[1]

TinyOS 1.x widely used for programming sensor network platformsF i l t i k b d CFairly easy to pick up: based on nes-CSatisfactory for resource constrained platformsR li bl i tReliable in most cases

Has grown to a huge codebase: changing keyHas grown to a huge codebase: changing key aspects of TinyOS a big undertaking

So why do it?So why do it?

[1] The TinyOS 2.x Working Group, “Demo Abstract: TinyOS 2.0”, Sensys’05, 2005

P bl i Ti OS 1 [2]Problems in TinyOS 1.x[2]

Multiplying platforms: CPU + Radio combinationsEvolving platforms: avrmote mica mica2 micaZmicaZLimitations on tasks: low reliability, can post only 8 tasks, no priority, no parameterExperience has shown current interfaces are insufficientNeed for higher level of abstraction for sharedNeed for higher level of abstraction for shared hardware resources

[2] D Culler, D Gay, B Greenstein, V Handziski, J Hui, P Levis, J Polastre, L Nachman, C Sharp, etc. “TinyOS 2.0”, available online

P t ti O tl kPresentation Outlook

TinyOS 2.x OverviewWhat’s new?What s new?How does it compare to TinyOS 1.x?

Migrating from TinyOS 1 x to TinyOS 2 xMigrating from TinyOS 1.x to TinyOS 2.xTinyOS 2.x Installation GuidelinesPorting TinyOS 1 x Code to TinyOS 2 xPorting TinyOS 1.x Code to TinyOS 2.xHow to code new features?

Ti OS 2 O i [1]TinyOS 2.x Overview[1]

Still component-based OS in nesCClean-slate rewrite of the OSClean slate rewrite of the OSWork done in 3 areas:

G t l tf fl ibilit (i t bilit )Greater platform flexibility (interoperability)Improved robustness and reliabilityS i di t ib ti ( li ti d l t)Service distributions (application development)

Pl tf / H d Ab t ti [3]Platform / Hardware Abstraction[3]

As for Boomerang, platforms located in tos/platforms

platform = chips + glueincludes .platform file that contains info to pass to nesC compiler: tells what chips to look forcompiler: tells what chips to look for

Chip code in tos/chipsHardware abstraction: 3 level hierarchy called theHardware abstraction: 3 level hierarchy called the HAA (Hardware Abstraction Architecture)

[3] Philip Levis, “TinyOS 2.0 Overview”, at www.tinyos.net/tinyos-2.x/doc/html/overview/htm

Pl tf / H d Ab t ti [3]‡… Platform / Hardware Abstraction[3]‡

Example: Send packet

HIL: Hardware Independent LayerProvides abstractions that are hardware

independent HIL does not provide all

GenericComm.c:• Provides Send and Receive interfaces

HAL: Hardware Abstraction LayerHigher-level of abstraction easier to use but

CC2420RadioM.c:• Write to TXFIFO

independent. HIL does not provide all functionality that HAL can

HPL: Hardware Presentation LayerPresents IO pins, registers etc. interfaces

still provide full functionality of hardware • Flush FIFOs

HPLCC2420M.c:• Provides the cmd function that sets pins

Hardware

p g • Provides the cmd function that sets pins and registers to write to TXFIFO

‡ Familiar to Boomerang / moteiv directory users

S h d l [3]Scheduler[3]

In TOS 1.x:shared task queue of limited sizecomponent can post task several timesproblem: if split-phase operation fails to post task, component may freezecomponent may freeze

In TOS 2.x:every task has own reserved slot in queueevery task has own reserved slot in queuecan post task only once: post fails if task already in queue and not executingq gtask scheduler’s policy can be modified

B ti / I iti li ti [3]Booting / Initialization[3]

In TOS 1.x: StdControl interface powers up and starts at bootIn TOS 2 x:In TOS 2.x:

StdControl broken into Init and StdControlboot sequence now only initializes componentBoot booted event signals end of scheduler HW and SWBoot.booted event signals end of scheduler, HW, and SW initializationComponents can be started as needed (saves energy)

configuration AppC{

}

implementation{

Initializes the radio

module AppM{

uses interface Boot;

}

implementation{components MainC, AppM;

AppM.Boot -> MainC;

Initializes the radio and other components

implementation{

event void Boot.booted(){

call …

}

Vi t li ti [3]‡Virtualization[3]‡

Many TinyOS 2.x services are now virtualized: no more parameterized interfacepInstead: program instantiates service componentcomponentSee new Timers

Ti [3]‡Timers[3]‡

TOS 2.x introduces timers with 32kHz and 1kHz granularityA couple of high-precision async timers may be usedNew functions provided by the timerinterface:

how much time before it firesstart timer in the futureno more “unique” for timer instantiation

Ti [3]… Timers[3]

configuration AppC{configuration AppC{}

implementation{

components AppM, new TimerMilliC();

AppM.Timer -> TimerMilliC;…

module AppM{

uses interface Timer<TMilli>;

}

implementation{implementation{

…

C i ti [3]Communication[3]

message_t now replaces TOS_Msg:it is now completely opaqueAMPacket.destination(msg); will return the destination of msg

Component --- provides --- interface:AMReceiverC Receive, PacketAMSenderC AMSend, Packet

Packet provides a function that returns a ppointer to the payload

E C d [3]Error Codes[3]

TinyOS 1.x had simple SUCCESS / FAIL error codesBut doesn’t distinguish between errors!!TinyOS 2.x replaces this by

SUCCESS (packet was transmitted successfully)FAIL (packet failed transmission)EBUSY (the instantiation of AMSenderC.AMSend has a packet to send)ECANCEL (packet has been canceled)ECANCEL (packet has been canceled)

A bit ti [3]‡Arbitration[3]‡

mac

Many hardware systems may be used by various protocols (running the radio, sensors,

implementation{call flushRXFIFO.request(rh);

async event void flushRXFIFO.granted(uint8_t rh){…1

p ( g , ,etc.)Need resource arbitration: Resource

flushRXFIFO.release();

radioControlimplementation{

1

2

5Need resource arbitration: Resource interfaceComponents request and release shared

arbiter

implementation{call flushRXFIFO.request(rh);

async event void flushRXFIFO.granted(uint8_t rh){…

3

6Components request and release shared resources

RXFIFO

flushRXFIFO.release();4

RXFIFO

C i ith Ti OS 1 [4]Comparison with TinyOS 1.x[4]

A S & S d A li tiA Sense & Send Application:Sense and Send requires up to 32% more ROM on mica platforms but 13% less on Telosmica platforms, but 13% less on TelosRAM usage reduced by up to 42%Reduced CPU utilization (5-10%)( )

350

400

450

)12000

14000

16000

s)

50

100

150

200

250

300

350

RA

M (b

ytes

)TinyOST2

2000

4000

6000

8000

10000

12000

RO

M (b

ytes

TinyOST2

[4] D Gay et al. “TinyOS 2.0”, at www.eecs.berkeley.edu/~culler/tinyos/ttx/slides/workinggroups/wg-tinyos2.ppt

0

50

mica2 micaZ Telos

0

mica2 micaZ Telos

P t ti O tl kPresentation Outlook

TinyOS 2.x OverviewWhat’s new?What s new?How does it compare to TinyOS 1.x?

Migrating from TinyOS 1 x to TinyOS 2 xMigrating from TinyOS 1.x to TinyOS 2.xTinyOS 2.x Installation GuidelinesPorting TinyOS 1 x Code to TinyOS 2 xPorting TinyOS 1.x Code to TinyOS 2.xHow to code new features?

I t lli Ti OS 2 [5]Installing TinyOS 2.x[5]

From a clean drive: use CD or install manuallyUsual steps in 2nd case: install…p

JavaCygwin (Windows only)Native compilers (msp430tools*.rpm for telos motes)nesC compilerTi OS tTinyOS source treeGraphviz visualization tool

[5] “Installing TinyOS 2.0.2”, at www.tinyos.net/tinyos-2.x/doc/html/install-tinyos.htm

U di f Ti OS 1 [6]Upgrading from TinyOS 1.x[6]

Upgrade external tools (compilers): msp430tools*.rpmUpgrade TinyOS specific toolsUpgrade TinyOS specific tools

Use rpm -ivh to keep TinyOS 1.x treeInstall nesC compiler BEFORE the TinyOS tools

I t ll Ti OS 2 tInstall TinyOS 2.x treeUse -i rpm argument to install, not -U (removes TinyOS 1.x tree))Configure the environment

Switching back to TinyOS 1.x requires only to change 4 env varchange 4 env. var.

[6] “Upgrading from TinyOS 1.x to TinyOS 2.0.2”, at www.tinyos.net/tinyos-2.x/doc/html/upgrade-tinyos.htm

P ti Ti OS 1 C d [7]Porting TinyOS 1.x Code[7]

SUCCESS no longer has a non-zero valueif (call Packet.function()) if (call Packet.function() == SUCCESS)

E d l i l ti d

{// SUCCESS!: do…

{// SUCCESS!: do this…

Every module implementing StdControl and calling init() must now implement the i t finterface Init.

Main.StdControl -> AppM;

MainC.SoftwareInit-> AppM;

command error_t SoftwareInit.init(){// initialize component

[7] T. Azim and P. Levis “Porting TinyOS 1.x Code to TinyOS 2.0”, at www.tinyos.net/tinyos-2.x/doc/html/porting.htm

command result_t StdControl.init(){// initialize component

}command error_t StdControl.start(){// start component

P ti Ti OS 1 C d [7]…(2) Porting TinyOS 1.x Code[7]

Radio needs to be started manually using:AppM.AMControl -> ActiveMessageC;

module AppM{

uses interface SplitControl as AMControl;

}

implementation{

(after boot sequence completed)

Use of the nx_ prefix: means that an element is external type: its representation is chip

call AMControl.start();

external type: its representation is chip-independent (storing LSB or MSB first)

P ti Ti OS 1 C d [7]…(3) Porting TinyOS 1.x Code[7]

Replace bool data types by nx_uint8_t Packets are now abstract

msg->addr = nodeId; AMPacket.setDestination(msg, nodeId);

Replace SendMsg and ReceiveMsg interfaces by AMSend and Receive, which at the lower layer are wired to AMSenderC and AMReceiverCAMReceiverC

TOS_LOCAL_ADDRESS no longer exists: distinction between:Node ID: TOS_NODE_ID, set at compile-timeActive message address: AMPacket localAddress() and canActive message address: AMPacket.localAddress() and can be changed during runtime

P ti Ti OS 1 C d [7]…(4) Porting TinyOS 1.x Code[7]

There are no red, green, yellow leds any longer. Instead call Leds.led1Toggle(); Leds.led2On();

C l iConclusion

More involved than I thought it would beSome aspects of TinyOS 2 x alreadySome aspects of TinyOS 2.x already familiar to Boomerang users

Questions?