contiki l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Contiki PowerPoint Presentation
Download Presentation
Contiki

Loading in 2 Seconds...

play fullscreen
1 / 28

Contiki - PowerPoint PPT Presentation


  • 450 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Contiki' - scarlett


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
contiki

Contiki

A Lightweight and Flexible Operating System for Tiny Networked Sensors

Presented by: Jeremy Schiff

objectives
Objectives
  • Lightweight
  • Event Driven Model
    • Has Multi-Threading Support as Library
  • Dynamic Loading and Replacement of Individual Services
contiki motivations
Contiki Motivations
  • No memory protection between apps
  • Kernel very minimal
    • CPU multiplexing
    • Loading Programs
  • All other abstractions by libraries
    • Custom Applications
differentiation
Differentiation
  • TinyOS
    • Statically linked entire applications
  • MagnetOS
    • Virtual Machine – byte code
  • Mantis
    • Pure MultiThread
  • Contiki
    • Dynamic Linking of binaries
    • Event/Thread Hybrid
why loadable applications
Why Loadable Applications
  • Smaller file to upload
  • Less Energy
  • Less Dissemination Time
why no threads
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
events
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
system overview
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
core vs loaded program
Core vs. Loaded Program
  • Partitioned at compile time
  • Core
    • Single Binary
    • Ideally never modified
  • Program
    • Easily upgraded
kernel
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
two level scheduling
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
loading programs
Loading Programs
  • Relocation Information in Binary
  • Check for space before loading
  • Call Initialization Function
    • Replace or Starts new Program
power save mode
Power Save Mode
  • No explicit Kernel assistance
  • Access to event queue size
services
Services
  • Application
  • Service Layer
  • Service Interface
  • Service Process
application
Application
  • Must dynamically link
  • Interact via Service Stub
    • Compiled in
    • Version number
    • Caches Service ProcessID
service layer
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.
service replacement
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?
libraries
Libraries
  • Application options
    • Static link with core
    • Static link with libraries
      • Single binary
    • Call a service
  • Memcpy() vs Atoi()
    • MemCpy in Core
communication
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
multi threading
Multi-Threading
  • Optional Library linked in
  • Kernel interaction
    • Platform Independent
  • Stack Switching / Preemption primitives
    • Platform Dependent
over the air programming
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
code size
Code Size
  • Bigger than TinyOS, Smaller than Mantis
  • Polling Handlers and Increase Flexibility
  • Less compiler optimization possible
preemption demo
Preemption Demo
  • Start 8 second process at 5 Seconds and continually ping
  • ~.1 ms latency increase
  • Poll handler caused spikes
    • Mainly Radio Packet driver
portability
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