Tiny OS Dhanshree Nimje Smita Khartad Tiny OS

Tiny. OS Dhanshree Nimje Smita Khartad

Tiny. OS - Design

What is Tiny. OS? Tiny. OS 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

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

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

Hardware Kits n n n 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

Hardware Abstraction: q q q 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)

Communication stack q q q building up from the RFM 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

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

Tiny. OS component model n Component interface: q q n commands accepts (implemented) commands uses events accepts (implemented) events uses Component implementation q q q functions that implement interface frame: internal state tasks: concurrency control

Programming Model comp 3 comp 1: C code comp 2: . desc Components. comp: specification. C: behaviour. desc: select and wire specification: accepts commands uses commands signals events handles events comp 4 application: . desc

n Scheduler : q q n Tasks: q q n 2 -level scheduling (events and tasks) single shared stack, used by events and function calls are preemptable by events may call commands may signal events not preempted by tasks Events – q q q 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

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

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

Receiving a message

What are tasks n n n 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? q Implementing it as a task and scheduling it for later execution. Tiny. OS has simple FIFO scheduler using which tasks are scheduled. On occurrence of an event a task that is executing is preempted.

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

Application n n 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 Hardware Interrupts Calls ISR Interrupt Handler

A Complete Application

Example : Inter-Node Communication n Sender: n Receiver :

Message Buffer Ownership • Transmission: AM gains ownership of the buffer until send. Done(…) is signaled • Reception: Application’s event handler gains ownership of the buffer, but it must return a free buffer for the next message

Potentially Nasty Bug 1 What’s wrong with the code? Symptom: data saved in global. Data is lost Reason: Race condition between two tasks Solution: Use a queue, or never rely on inter-task communication n uint 8_t global. Data; task void process. Data() { call Send. Data. send(global. Data); } command result_t Foo. bar(uint 8_t data) { global. Data = data; post process. Data(); }

Potentially Nasty Bug 2 What’s 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 component’s frame. command result_t Foo. bar(uint 8_t data) { TOS_Msg msg; Foo. Data* foo = (Foo. Data*)msg. data; foo. data = data; call Send. Msg. send(0 x 01, sizeof(Foo. Data), &msg); }

Potentially Nasty Bugcommand 3 result_t Foo. bar(uint 8_t What’s 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 data) { Foo. Data* foo = (Foo. Data*)msg. data; foo. data = data; call Send. Msg. send(0 x 01, sizeof(Foo. Data), &msg); } Component 2: * command result_t Goo. bar(uint 8_t data) { Goo. Data* goo = (Goo. Data*)msg. data; goo. data = data; call Send. Msg. send(0 x 02, sizeof(Goo. Data), &msg); }

THANK YOU