1. Contiki A Lightweight and Flexible Operating System for Tiny Networked Sensors Presented by: Jeremy Schiff

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17. Service Example

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

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

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

21. Communication Stack

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

23. Multi-Thread API

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

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

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

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

28. Questions?