1 / 25

TinyOS

TinyOS. Dhanshree Nimje Smita Khartad. TinyOS - Design Design. 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

emile
Télécharger la présentation

TinyOS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. comp3 comp1: C code comp4 Programming Model • Components • .comp: specification • .C: behaviour • .desc: select and wire • specification: • accepts 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: Application’s event handler gains ownership • of the buffer, but it must return a free buffer for the next • message

  22. Potentially Nasty Bug 1 uint8_t globalData; task void processData() { call SendData.send(globalData); } command result_t Foo.bar(uint8_t data) { globalData = data; post processData(); } • What’s 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

  23. 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(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); } Component 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 Component 2: * command result_t Goo.bar(uint8_t data) { GooData* goo = (GooData*)msg.data; goo.data = data; call SendMsg.send(0x02, sizeof(GooData), &msg); }

  25. THANK YOU

More Related