Contiki a Lightweight and Flexible Operating System for Tiny Networked Sensors - PowerPoint PPT Presentation

1 / 30
About This Presentation
Title:

Contiki a Lightweight and Flexible Operating System for Tiny Networked Sensors

Description:

'Mote'-class devices. 10-100 kilobytes of code ROM 20 kilobytes of RAM ... Contiki OS for 'mote'-class sensor nodes. Contiki explores trade-offs in ... – PowerPoint PPT presentation

Number of Views:620
Avg rating:3.0/5.0
Slides: 31
Provided by: oka7
Category:

less

Transcript and Presenter's Notes

Title: Contiki a Lightweight and Flexible Operating System for Tiny Networked Sensors


1
Contiki - 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

3
Target
  • 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

4
Challenges
  • 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

6
Goals
  • Portability
  • Flexibility
  • Loadable application programs, device drivers
  • Multitasking
  • Networking (TCP/IP)
  • Event-driven interfaces
  • Size

7
Main Contributions
  • Dynamic loading of programs
  • Selective reprogramming
  • Multitasking management mechanisms
  • Events vs threads
  • Trade-offs preemption, size
  • Inter-process communication

8
The 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

10
Control flow
A
B
C
11
Constituents 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)

12
Kernel
LOADER_INIT_FUNC()
EK_EVENTHANDLER()
EK_POLLHANDLER()
13
Example
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)
19
Dynamic 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)

22
Multitasking 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

23
Event-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
24
Multi-threaded
Thread
Thread
Thread
  • Threads blocked, waiting for events
  • Kernel unblocks threads when event occurs
  • Thread runs until next blocking statement

Kernel
25
Event-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
26
Contiki 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

27
Threads
  • 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

28
Protothreads 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

29
Current Status
  • Ported to 20 platforms
  • MSP430, 6502, x86, AVR, Z80, PowerPC, ...
  • Full TCP/IP support, provided by µIP
  • Ongoing port to the TelosMoteIV platform

30
Conclusions
  • 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
Write a Comment
User Comments (0)
About PowerShow.com