TinyOS

1
TinyOS

• Dhanshree Nimje
• Smita Khartad

2
TinyOS - Design Design
3
What is TinyOS?

• TinyOS is a highly modular software
• environment tailored to the requirements of
• Network Sensors, stressing efficiency,
• modularity and concurrency.

• Capable of fine grained concurrency
• (event-driven architecture)
• ??Small physical size
• Fewer context switches
• (FIFO/non-preemptable scheduling)
• ??Efficient Resource Utilization
• (Get done quickly and sleep)
• ??Highly Modular

4
TinyOS - Features

• Event-driven architecture
• Lower layer sends events to higher layer
• Low overhead No busy -wait cycles
• Interrupt driven.Two kinds of interrupt
• ???? Clock
• ???? Radio
• Component driven programming model
• ???? Size - 400 bytes
• ???? Extremely flexible component graph
• Single Single-shared stack shared stack

5
Features Contd.

• Network management - Active Messaging
• No kernel, process management, virtual memory
• File management - Matchbox
• 2-level FIFO scheduler events and tasks
• Complete integration with hardware

6
Hardware Kits

• Two Board Sandwich
• Main CPU board with Radio Communication
• ?? Secondary Sensor Board
• ?? Allows for expansion and
• customization
• ?? Current sensors include
• Acceleration, Magnetic Field,
• Temperature, Pressure,
• Humidity, Light, and RF Signal Strength
• ?? Can control RF transmission strength Sense
  Reception
• Strength

7
Hardware Abstraction

• LED (pin numbering/HW wiring)
• CLOCK (counter interrupt)
• UART (baud rate control, transfer)
• ADC (ADC interrupt handling)
• RFM (abstracts bit level timing, RFM specific
  control logic)

8
Communication stack

• building up from the RFM bit level
• bit level abstracts away radio specifics
• byte level radio component collects individual
  bits into bytes
• packet level constructs packets from bytes
• messaging layer interprets packets as messages

9
Sensor stack

• photo, and temperature sensing components
• sits on top of ADC component
• typical request data, wait for data event

10
TinyOS component model

• Component interface
• commands accepts (implemented)
• commands uses
• events accepts (implemented)
• events uses
• Component implementation
• functions that implement interface
• frame internal state
• tasks concurrency control

11
Programming Model
Components .comp specification .C
behaviour .desc select and wire specification ac
cepts commands uses commands signals
events handles events
comp2 .desc
application .desc
12

• Scheduler
• 2-level scheduling (events and tasks)
• single shared stack, used by events and function
  calls
• Tasks
• are preemptable by events
• may call commands
• may signal events
• not preempted by tasks
• Events
• Time critical
• Shorter duration (hand off to task if need be)
• Interrupts task
• Last-in first-out semantics (no priority among
  events)
• lowest level events support by hardware interrupt

13
TinyOS Two-level Scheduling

• Tasks do intensive computations
• Unpreemptable FIFO scheduling
• Bounded number of pending tasks
• Events handle interrupts
• Interrupts trigger lowest level events
• Events can signal events, call commands, or post
  tasks
• Two priorities
• Event/command
• Tasks

14
How to handle multiple data flows?

• Data/interrupt are handled by interrupt/event
• Respond to it quickly A sequence of non-blocking
• event/command (function calls) through the
  component
• graph
• e.g., get bit out of radio hw before it gets
  lost
• Post tasks for long computations
• e.g., encoding
• Assumption long computation are not urgent
• New events preempt tasks to handle new
• data

15
Receiving a message
16
What are tasks

• Requirement of realtime OS bounded delays
  between events.
• Event handler should run to completion within a
  short duration.
• If a lot of computation is involved in an event
  handler we defer execution. How?
• Implementing it as a task and scheduling it for
  later execution.
• TinyOS has simple FIFO scheduler using which
  tasks are scheduled.
• On occurrence of an event a task that is
  executing is preempted.

17
Data Memory Model

• STATIC memory allocation!
• No heap (malloc)
• No function pointers
• Global variables
• Available on a per-frame basis
• Local variables
• Saved on the stack
• Declared within a method

18
Application

• Is the OS with some specific functionality.
• Application is interrupt driven.
• List of interrupts handled depend on list of
  hardware components included in the application
  (e.g. clock and receiver).
• Waits for interrupts. On occurrence of interrupt,
  calls interrupt handler.

invokes
Calls
Hardware Interrupts
ISR
Interrupt Handler
19
A Complete Application
20
Example Inter-Node Communication

• Sender
• Receiver

21
Message Buffer Ownership

• Transmission AM gains ownership of the buffer
  until
• sendDone() is signaled
• Reception Applications event handler gains
  ownership
• of the buffer, but it must return a free buffer
  for the next
• message

22
Potentially Nasty Bug 1

• Whats wrong with the code?
• Symptom data saved
• in globalData is lost
• Reason Race
• condition between
• two tasks
• Solution Use a
• queue, or never rely
• on inter-task
• communication

uint8_t globalData task void processData()
call SendData.send(globalData) command
result_t Foo.bar(uint8_t data) globalData
data post processData()
23
Potentially Nasty Bug 2

• Whats wrong with the code?
• Symptom message
• is corrupt
• Reason TOS_Msg
• is allocated in the
• stack, lost when
• function returns
• Solution Declare
• TOS_Msg msg in
• components frame.

command result_t Foo.bar(uint8_t data) TOS_Msg
msg FooData foo (FooData)msg.data foo.data
data call SendMsg.send(0x01,
sizeof(FooData), msg)
24
Potentially Nasty Bug 3
command result_t Foo.bar(uint8_t data) FooData
foo (FooData)msg.data foo.data data call
SendMsg.send(0x01, sizeof(FooData), msg) Compo
nent

• Whats wrong with
• the code?
• Symptom some
• messages are lost
• Reason Race
• condition between
• two components
• trying to share
• network stack (which
• is split-phase)
• Solution Use a
• queue to store
• pending messages

Component 2 command result_t Goo.bar(uint8_t
data) GooData goo (GooData)msg.data goo.dat
a data call SendMsg.send(0x02,
sizeof(GooData), msg)
25

• THANK YOU