TinyOS Tutorial Jianping Wang (merge several tutorials found online)

TinyOS TinyOS is an open source operation system designed for wireless embedded sensor network. It is not a operation for general purpose. Official website: It features a component-based architecture which enables rapid development while minimizing code size. Supported platforms include Linux RedHat9.0, Windows 2000/XP with Cygwin.

TinyOS versions 1.0 (Oct 2002) 1.1 (Sep 2003) (Nov 2003) add a new routing module MintRoute, a new ADC interface (Jan 2004) add B-Mac, a new MAC layer w/ CSMA with collision, etc (Feb 2004) add Tython, which is a TOSSIM (a TinyOS simulator) scripting environment (Mar 2004) make improvements and bugs fixes to Tython (May 2004) support PageEEPROM component, a new make system, for PC platform (July 2004) supports MicaZ and Telos (Oct 2004) support TinyOS network programming components: Delug, NetProg and TOSBoot.

Serial-line communication in TinyOS The protocol is based on the PPP in HDLC-like framing described in RFC Components: FramerM – provides core framing protocol FramerAcm – implements ACK processing for inbound packets UARTFramedPacket – A configuration component incorporating FrameM and FrameAckM Applications TOBase (apps/TOBase) – simple bridge between serial and wireless chanels TransparentBase (apps/TransparentBase) – bridge identical to TOBase but doesn’t check group ID GenericBase (apps/GenericBase) – legacy bridge w/o framing or flow control Host Tools net.tinyos.packet.PacketSource (Interface) Net.tinyos.packet.PhoenixSource (Class) Net.tinyos.SerialForwarder (Application)

Different platforms need different solutions Capabilities Size, Power Consumption, Cost MICA Mote MK - II StarGate Spec Software: atmel tools, java, perl Highly constrained (memory, cpu, storage, power) Solutions: TinyOS,…

Environment/Tools 2.25 in 1.25 in Microphone Accelerometer Light Sensor Temperature Sensor SounderMagnetometer

Environment/Tools download TOS distribution and Java JDK from: – directory structure, after installation: – c:\tinyos\cygwin – installation directory – \opt\tiny-1.x\contrib\xbow\apps {cnt_to_leds, cnt_to_rfm, sense, …} – \opt\tiny-1.x\docs {connector.pdf, tossim.pdf, …} – \opt\tiny-1.x\tools {toscheck, inject, verify, …} – \opt\tiny-1.x\tos {shared/system components, …}

Environment/Tools verify the software installation: –~\tools\toscheck.exe verify the hardware is working: –~\apps\mica_hardware_verify\make mica –install the mote into the board. Red LED on. –~\apps\mica_hardware_verify\make mica install.1 –~\apps\mica_hardware_verify\java hardware_check COM1

TinyOS 1.0 libraries and components are written in an extension of C, called nesC Applications are too! –just additional components composed with the OS components Provides syntax for TinyOS concurrency and storage model –commands, events, tasks –local frame variable Rich Compositional Support –separation of definition and linkage –robustness through narrow interfaces and reuse –interpositioning Programming TinyOs

A TinyOS application consists of one or more components. A component provides and uses interfaces. –A interface defines a set of functions called commands. There are two types of components in nesC: –Modules. It implements application code. –Configurations. It assemble other components together, called wiring. TinyOs Components (1)

TinyOs Components (2) Component interface: –commands accepts (implemented) –commands uses –events accepts (implemented) –events uses Component implementation –functions that implement interface –frame: internal state –tasks: concurrency control Internal Tasks Messaging Component Internal State CommandsEvents

A component specifies a set of interfaces by which it is connected to other components –provides a set of interfaces to others –uses a set of interfaces provided by others Interfaces are bi-directional –include commands and events Interface methods are the external namespace of the component Timer Component StdControl Timer Clock provides uses provides interface StdControl; interface Timer: uses interface Clock TinyOs Components (3)

TinyOS executes only one program consisting of a set of components. Two type threads: –Task –Hardware event handler Tasks are scheduled to executed and put into a single queue. A task doesn’t preempt another task. Hardware event handlers are executed in response to a hardware interrupt. They may preempt the execution of a task and other hardware handler. –The events and commands executed as part of a hardware event handler must be declared as async. TinyOs Concurrency Model

Issues/Comments System perspective: –simplistic FIFO scheduling -> no real-time guarantees –bounded number of pending tasks –no “process” management -> resource allocation problematic, e.g. shared resources –software level “bit manipulation”. HW implementation can provide speed-up and power saving

5/5/2003MobiSys Tutorial, San Francisco15 TinyOS Application TinyOS (TOS) = application/binary image, executable on an ATmega processorTinyOS (TOS) = application/binary image, executable on an ATmega processor event-driven architectureevent-driven architecture single-shared stacksingle-shared stack no kernel, no process management, no memory management, no virtual memoryno kernel, no process management, no memory management, no virtual memory 2-level scheduling2-level scheduling simple FIFO scheduler, part of the mainsimple FIFO scheduler, part of the main

Application = Graph of Components RFM Radio byte Radio Packet UART Serial Packet ADC Tempphoto Active Messages clocks bit byte packet Route map routersensor appln application HW SW Example: ad hoc, multi-hop routing of photo sensor readings 3450 B code 226 B data Graph of cooperating state machines on shared stack

Application = Graph of Components+Scheduler TOS application = graph of components + scheduler Communication ActuatingSensing Communication Application (User Components) Main (includes Scheduler) Hardware Abstractions m ain { // component initialization while(1) { while(more_tasks) schedule_task; sleep; } // while } // main

TOS Execution Model commands request action –ack/nack at every boundary –call cmd or post task events notify occurrence –HW intrpt at lowest level –may signal events –call cmds –post tasks Tasks provide logical concurrency –preempted by events RFM Radio byte Radio Packet bit byte packet event-driven bit-pump event-driven byte-pump event-driven packet-pump message-event driven active message application comp encode/decode crc data processing

Dynamics of Events and Threads bit event filtered at byte layer bit event => end of byte => end of packet => end of msg send thread posted to start send next message radio takes clock events to detect recv

Event-Driven Sensor Access Pattern clock event handler initiates data collection sensor signals data ready event data event handler calls output command device sleeps or handles other activity while waiting conservative send/ack at component boundary command result_t StdControl.start() { return call Timer.start(TIMER_REPEAT, 200); } event result_t Timer.fired() { return call sensor.getData(); } event result_t sensor.dataReady(uint16_t data) { display(data) return SUCCESS; } SENSE Timer Photo LED

TinyOS Commands and Events {... status = call CmdName(args)... } command CmdName(args) {... return status; } {... status = signal EvtName(args)... } event EvtName)(args) {... return status; }

TinyOS Execution Contexts Events generated by interrupts preempt tasks Tasks do not preempt tasks Both essential process state transitions Hardware Interrupts events commands Tasks

TASKS provide concurrency internal to a component –longer running operations are preempted by events able to perform operations beyond event context may call commands may signal events not preempted by tasks {... post TskName();... } task void TskName {... }