Tiny OS

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 13

TinyOS

TinyOS is an open source operation system


designed for wireless embedded sensor network. It
is not a operation for general purpose.
Official website: http://www.tinyos.net/
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.
Programming TinyOs
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
TinyOs Components (1)

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 (2)
Component interface:
commands accepts (implemented)
commands uses
events accepts (implemented)
Messaging Component
events uses
Internal State
Component implementation
Internal Tasks

functions that implement interface


frame: internal state
tasks: concurrency control Commands Events
TinyOs Components (3)
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
provides
StdControl Timer
provides
interfaceStdControl;
Timer Component
interfaceTimer:
uses
interfaceClock Clock
uses
TinyOs Concurrency Model
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 doesnt 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 Application
TinyOS (TOS) = application/binary image, executable on an
ATmega processor
event-driven architecture
single-shared stack
no kernel, no process management, no memory management,
no virtual memory
2-level scheduling
simple FIFO scheduler, part of the main

5/5/2003 MobiSys Tutorial, San Francisco 7


Application = Graph of Components
application

Route map router sensor appln

Active Messages
packet

Radio Packet Serial Packet Temp photo


SW
Example: ad hoc, multi-hop
routing of photo sensor
UART HW readings
byte

Radio byte ADC

3450 B code
clocks
226 B data
bit

RFM

Graph of cooperating
state machines
on shared stack
Application = Graph of
Components+Scheduler
TOS application = graph of components +
scheduler
main {
// component initialization
while(1) { Main (includes Scheduler)
while(more_tasks)
schedule_task; Application (User Components)
sleep;
} // while
Actuating Sensing Communication
} // main Communication

Hardware Abstractions
TOS Execution Model
commands request action
application comp data processing
ack/nack at every boundary
call cmd or post task message-event driven
events notify occurrence active message

HW intrpt at lowest level event-driven packet-pump

may signal events

packet
Radio Packet crc
call cmds
event-driven byte-pump
post tasks
Radio byte

byte
Tasks provide logical concurrency encode/decode

preempted by events event-driven bit-pump


RFM
bit
TinyOS Commands and Events
{
...
status = call CmdName(args)
...
}

command CmdName(args) {
...
event EvtName)(args) { return status;
... }
return status;
}

{
...
status = signal EvtName(args)
...
}
TinyOS Execution Contexts
Tasks
events

commands

Interrupts

Hardware Events generated by interrupts preempt tasks


Tasks do not preempt tasks
Both essential process state transitions
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
{ task void TskName {
... ...
post TskName(); }
...
}

You might also like