Title: Contiki a Lightweight and Flexible Operating System for Tiny Networked Sensors
1Contiki - a
Lightweight and Flexible
Operating System for Tiny Networked Sensors
Adam Dunkels, Björn Grönvall, and Thiemo Voigt
Swedish Institute of Computer Science
In Proceedings of the First IEEE Workshop on
Embedded Networked Sensors, Tampa, Florida, USA,
November 2004
2- Target
- Challenges
- Goals
- Main Contributions
- The Contiki Internals
- Dynamic Loading
- Multitasking Management
- Conclusion
3Target
- Mote-class devices
- 10-100 kilobytes of code ROM
- lt 20 kilobytes of RAM
- Communication (radio)
- 8-bit µ-controller
- ESB from FU Berlin
- MSP430, 2k RAM, 60k ROM
4Challenges
- Constrained resources
- Memory (less than 64 kilobytes)
- CPU (less than 16 MHz)
- Efficient multitasking
- Threads? Pre-emption?
- Locking?
- Flexibility
5- Most systems statically linked at compile-time
- Entire system is a monolithic binary
- Compile-time optimizations, analysis possible
- But hard to change
- Must download entire system image
6Goals
- Portability
- Flexibility
- Loadable application programs, device drivers
- Multitasking
- Networking (TCP/IP)
- Event-driven interfaces
- Size
7Main Contributions
- Dynamic loading of programs
- Selective reprogramming
- Multitasking management mechanisms
- Events vs threads
- Trade-offs preemption, size
- Inter-process communication
8The Contiki Internals
- Kernel
- Comprises the main loop of the Contiki system
- Calls services whenever events occur
- Calls services whenever no events occur (polling)
- Services are loaded on top of kernel (core)
- All communication is made through µIP
9- Core always present in memory
- kernel
- communication drivers
- parts of language runtime (C library)
- Libraries
- Programs, loaded at runtime
- Applications
- May replace drivers, services in core
- E.g. Web server
10Control flow
A
B
C
11Constituents of a Contiki Program/Service
- Init function, called by program loader
- LOADER_INIT_FUNC(function_name, arg)
- Eventhandler, called by kernel
- EK_EVENTHANDLER(eventhandler, ev, data)
- Pollhandler, called repeatedly by kernel
- EK_POLLHANDLER(pollhandler)
12Kernel
LOADER_INIT_FUNC()
EK_EVENTHANDLER()
EK_POLLHANDLER()
13Example
14/ Declaration of pollhandler function
/ EK_POLLHANDLER(pollhandler)
15/ Declaration of process / EK_PROCESS(p,
Beeper, EK_PRIO_NORMAL,
eventhandler, pollhandler, NULL)
Name of pollhandler
Optional process state
16/ Implementation of init function.
/ LOADER_INIT_FUNC(init, arg)
arg_free(arg) timer_set(timer,
CLOCK_SECOND) ek_start(p)
17/ Implementation of eventhandler.
/ EK_EVENTHANDLER(eventhandler,
ev, data) if(ev EK_EVENT_REQUEST_EXIT)
ek_exit() LOADER_UNLOAD()
18/ Implementation of pollhandler.
/ EK_POLLHANDLER(pollhandler)
if(timer_expired(timer)) beep()
timer_reset(timer)
19Dynamic Loading
- Static vs Dynamic Complete vs Partial Image
- Software development for sensor nets
- Need to reprogram many nodes quite often
- Utilize radio for reprogramming
- Radio inherently broadcast
- Reprogram many nodes at once
- Much faster than firmware download via cable or
programming adapter - Reprogram deployed networks
20- A running Contiki system is partitioned into two
parts - Core
- Programs
- Core always present in memory (ROM)
- Services loaded at
- runtime
ROM
Programs
RAM
Core
Programs
Core
21- Programs/services can be loaded from anywhere
- Radio (multi-hop, single-hop), EEPROM, etc
- During software development, usually change only
one module - Programs/services typically much smaller than
entire system image (1-10)
22Multitasking Management
- Event-driven vs multi-threaded
- Event-driven (TinyOS)
- Compact, low context switching overhead, fits
well for reactive systems - Not suitable for e.g. long running computations
- Public/private key cryptography
- Multi-threading
- Suitable for long running computations
- Requires more resources
23Event-driven
Handler
- Event-driven (TinyOS)
- Processes do not run without events
- Event occurs kernel invokes event handler
- Event handler runs to completion (explicit
return)
Handler
Kernel
Handler
Handler
24Multi-threaded
Thread
Thread
Thread
- Threads blocked, waiting for events
- Kernel unblocks threads when event occurs
- Thread runs until next blocking statement
Kernel
25Event-driven vs multi-threaded
- Event-driven
- - No wait() statements
- - No pre-emption
- - State machines - problematic
- Compact code
- Locking less of a problem
- Memory efficient
Multi-threaded wait() statements
Pre-emption possible Sequential code flow -
Larger code overhead stacks !! - Locking
problematic shared - Larger memory requirements
26Contiki event-based kernel with Threads
Protothreads
- Contiki kernel is event-based
- Most programs run directly on top of the kernel
- Multi-threading implemented as a library
- Threads only used if explicitly needed
- Long running computations, ...
- Pre-emption possible
- Responsive system with running computations
27Threads
- Implemented as application library
- Applied on a per-application basis
- Scheduling on application level
- Event handler schedules thread
- May be preempted
- Drawbacks
- Requires stack to be allocated
- Locking
28Protothreads stackless threads
- Extremely lightweight threads
- Can only run within a single C function
- Does not require any stack!
- Supports blocked waiting
- Scheduled within event handler, poll handler,
TCP/IP handler, etc
29Current Status
- Ported to 20 platforms
- MSP430, 6502, x86, AVR, Z80, PowerPC, ...
- Full TCP/IP support, provided by µIP
- Ongoing port to the TelosMoteIV platform
30Conclusions
- Contiki OS for mote-class sensor nodes
- Contiki explores trade-offs in
- event-driven vs multi-threaded
- Loadable programs, works well
- Threads on an event-driven kernel
- Multi-threading suitable for certain applications
- Potential for OpenCOM wrap-up of Contiki the
services abstraction