1 / 28

Contiki

Contiki. A Lightweight and Flexible Operating System for Tiny Networked Sensors Presented by: Jeremy Schiff. Objectives. Lightweight Event Driven Model Has Multi-Threading Support as Library Dynamic Loading and Replacement of Individual Services. Contiki Motivations.

mcclaskey
Download Presentation

Contiki

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. Contiki A Lightweight and Flexible Operating System for Tiny Networked Sensors Presented by: Jeremy Schiff

  2. Objectives • Lightweight • Event Driven Model • Has Multi-Threading Support as Library • Dynamic Loading and Replacement of Individual Services

  3. Contiki Motivations • No memory protection between apps • Kernel very minimal • CPU multiplexing • Loading Programs • All other abstractions by libraries • Custom Applications

  4. Differentiation • TinyOS • Statically linked entire applications • MagnetOS • Virtual Machine – byte code • Mantis • Pure MultiThread • Contiki • Dynamic Linking of binaries • Event/Thread Hybrid

  5. Why Loadable Applications • Smaller file to upload • Less Energy • Less Dissemination Time

  6. Why No Threads? • Thread stacks must be allocated at creation time • Stack Memory Over-Provisioned • No Virtual Memory System • No Memory Protection Mechanisms • Locking for state exclusion • Stack memory is inaccessible to other threads

  7. Events • No locking • Only one running at a time • Only one stack • Locking rare • Hard to express some things as state machine • Problem: Cryptography takes 2 seconds, everything else blocked. • Solution: Preemptive Threads

  8. System Overview • Service – Something that implements functionality for more than one application • Apps have direct access to hardware • Single Address Space • Inter-process communication via event posting • Always Through Kernel

  9. Core vs. Loaded Program • Partitioned at compile time • Core • Single Binary • Ideally never modified • Program • Easily upgraded

  10. Kernel • Execution via: Kernel Events or Polling Events • No preemption of scheduled events • Synchronous vs Asynchronous Events • Synch: Like Function Call • Asynch: Like posting new event • Asynch reduces stack space • Debugging issues

  11. Two Level Scheduling • Events • Can’t preempt one another • Interrupts • Can preempt events • Can use “underyling real-time executive” • Provides realtime guarantees • Non-hardware • Can’t post events • Use polling flag instead • Prevent race conditions

  12. Loading Programs • Relocation Information in Binary • Check for space before loading • Call Initialization Function • Replace or Starts new Program

  13. Power Save Mode • No explicit Kernel assistance • Access to event queue size

  14. Services • Application • Service Layer • Service Interface • Service Process

  15. Application • Must dynamically link • Interact via Service Stub • Compiled in • Version number • Caches Service ProcessID

  16. Service Layer • Works with Kernel • Provides lookup for specific service • Returns a Service Interface • Has pointers to all functions service provides • Contains a version Number • Interface description implemented by Service Process • Version numbers must match • Failure Support? MANTIS thinks about this better.

  17. Service Example

  18. Service Replacement • Process ID must be preserved • Kernel supported • Kernel instructs service to remove itself • Could lead to problems • Kernel provides mechanism to transfer state • Service state also versioned • Service state must be stored in a shared space during swap due to reallocations of old version’s space • Is there a better way to do this - SOS?

  19. Libraries • Application options • Static link with core • Static link with libraries • Single binary • Call a service • Memcpy() vs Atoi() • MemCpy in Core

  20. Communication • Architecture makes easy to replace Communication Stack • A service like any other • Enables multiple communication stack for comparison • Comm Services use Service Mechanism to call one another • Comm Services use Synchronous events to communicates with applications • No copying of buffers because Synch events can’t be preempted

  21. Communication Stack

  22. Multi-Threading • Optional Library linked in • Kernel interaction • Platform Independent • Stack Switching / Preemption primitives • Platform Dependent

  23. Multi-Thread API

  24. Over the air Programming • 1 node took 30 seconds • 40 nodes took 30 minutes • 1 component for 40 nodes took 2 minutes • Used naïve protocol

  25. Code Size • Bigger than TinyOS, Smaller than Mantis • Polling Handlers and Increase Flexibility • Less compiler optimization possible

  26. Preemption Demo • Start 8 second process at 5 Seconds and continually ping • ~.1 ms latency increase • Poll handler caused spikes • Mainly Radio Packet driver

  27. Portability • Custom Code in a port • Boot up code • Device Drivers • Architecture specific parts of program loader • Stack switching code of the multithreading library • Kernel and Service layer need no changes

  28. Questions?

More Related