The Contiki Operating System

sanatoriumdrumΗλεκτρονική - Συσκευές

25 Νοε 2013 (πριν από 3 χρόνια και 9 μήνες)

87 εμφανίσεις





















The Contiki Operating System













Jack Nosek

CMSC/CMPE 491E

2/23/06


The Contiki Operating System
is an open source, network
-
able, and multi
-
tasking
real time operating system developed for portable and memory
-
constrained embedde
d
systems. It was
released

o
n
March 10,
2003 by
Adam Dunkels
, a researcher at
the
Swedish Institute of Computer Science
.
The operating system
is

named after
Thor
Heyerdahl's famous Kon
-
Tiki raft
. Heyerdahl
built

the balsa wood raft and sailed it with
hi
s crew
of six
from South America to Polynesia in 101 days to prove that the Polynesian
islands where within the reach of ancient South American
s
. The comparison is that the
Contiki Operating System can implement the same basic functions of today’s compute
rs
on outdat
ed or smaller systems, just as Kon
-
Tiki sailed a route
many modern ships have,
but was
not thought possible with ancient

ships.


The operating
system
has a
very versatile
base system that provides multitasking
and TCP/IP networking along with a
dditional
libraries

for extra functionality
,

causing it
to be adopted for many different uses.

With its ability to reprogram and update over a
network, the operating system is
a
common choice
for networks of
embedded sensors
. It
is also frequently used b
y hobbyists who port the operating system over to outdated
microprocessors and systems.
Contiki currently has about 20 different ports ranging
from 8
-
bit microcontrollers to outdate video game systems. Some of the

more

notable
ports are for the Apple II
Computer, various Atari systems, Gameboy and Gameboy
Advanced, Nintendo Entertainment System,
and the Commodore 64 and 128.

Outside of

networks of embedded systems and hobbyists, the features of the operating system allow
it to be extremely flexible and e
fficient for use in any application.



The main features that
Contiki
emphasizes

are
its

minimalistic event driven kernel
with optional preemptive multithreading, native TCP/IP stack support
,
dynamic program
loading and
unloading,

and small memory requirem
ents
.

Contiki’s kernel is event
-
based,
making it completely responsive to real time events

and
classif
ies
it as a real time
operating system. It
provides only the basic functions
of

CPU multiplexing and message
passing

to programs
. It is
very similar to

the operation of the TinyOS kernel

in that a
process will only execute when a

corresponding
event triggers it.
If a
n event occurs,

it
will
trigger

an event handler which runs
a

process till completion, and finally returns
control back to the kernel. Thi
s design has the benefits

of resulting in more compact
code and requiring

less memory than a thread driven kernel, which must store and keep
track of a stack for each thread
.



There are many downsides to this design though. First, the code for event dri
ven
kernels is designed like a state machine, which is
written
very different
ly

fro
m the more
traditional

ways of writing code
. Most importantly, there are no wait() statements or
preemption of processes in event driven kernels, which becomes a major issu
e for long
running computations. For example, if the system where to compute private or public
key encryptions, which is a considerable computation, no other events would be able to
grab hold of the kernel

and CPU resources
, no matter how urgent, until th
e
encryption
task
has been completed.


Dunkels addresses this issue by implementing multi
-
threading as a library on top
of the kernel.
By implementing multithreading as an optional library, only programs that
wish to incorporate them pay the extra memory
and program costs. He calls
the

implementation
he created
protothreads. Protothreads

are a stackless, small memory
thread design

comprised of a single C function

that

only requiring 2 bytes of RAM per
thread

to record
its

state
.
What the library really
does is provide a context of blocking
and preemption
on top

of the event based kernel. It is an abstraction of the event based
operation of the kernel that allows sequential program flow without having to write
complex state machine code or a full
-
blown m
ultithreading program.

The real beauty of
proto
threads is that the library is pure C with no architecture specific code. They can be
implemented with or without an OS and have been widely used outside of the Contiki
operating system.


Here is an example
step
by step e
xplanation of
one
way a protothread

could
function
:

1.

An even occurs and the kernel calls the associated event handler.

2.

The event handler uses a protothread and calls it to be executed.

3.

Execution transfers to the protothread, and based on the c
ode, it blocks

and waits for a condition or yields to the event handler

(perhaps a timer
was set for preemption)
.

4.

Execution transfers back to the event handler, which based on the code,
returns execution back to the kernel.

5.

The same event occurs again, the

kernel calls the event handler, which
then calls the protothread again, and it starts execution back at the
blocking statement

if the original condition has been fulfilled
.

6.

As some point, t
he protothread finally ends and
control returns back to the
event,

which returns control back to the kernel.


There are several issues though that must be kept in mind when using
protothreads. One is that for preemption, scheduling is handled by the event handler that
calls the thread. Contiki is an event based operati
ng system, so it does not incorporate
scheduling into its design. Second, is that because no stack is used, protothreads cannot
use any local variables. If they are to be used, extreme caution is to be taken since
behavior becomes unpredictable. Finally
,
because of the C implementation of the
protothreads, certain blocking conditions cannot be contained inside a switch() statement.


Another major feature of Contiki is the native TCP/IP support incorporated into
the operating system.
Contiki uses the μIP

TCP/IP stack that Dunkels created himself. It
allows limited TCP/IP connections to the systems featuring ARP
(
for IP address to
Ethernet MAC address protocols
)
, SLIP (Serial Line IP),
IP,
ICMP echo

(ping), Unicast
UDP
, and TCP
protocols
.

The micro in th
e name of the

stack
references to the small
memory requirements of

program code
,

on the order a few kilobytes
,

and RAM,
only a
few
hundred

bytes
, needed to support a

limited number of connections.


Contiki supports dynamic program loading and unloading by
keeping the core
code separate from the program code in ROM.

The core is usually kept the same

and
untouched,
and the programs are loaded from
either program ROM or RAM

at runtime.
With the ability to connect to networks and communicate using TCP/IP, Con
tiki has the
ability to not only load and unload programs from
system memory,
but can also load and
unload programs over the network connection

into RAM or ROM (if re
-
flashing is
supported by the system)
. In the area of networks of sensors, this leads to
an interesting
application called Over the Air Reprogramming. Either by connecting networks of
sensors using ethernet or wirelessly using
any kind of
radio communication, every system
in the network can load or unload remotely with new or updated program
code at any
time.

If programmed carefully, even a new core can be loaded this way.
This allows for
easy maintenance of very large networks of sensors.


The smallest base system of Contiki provides multitasking and TCP/IP
networking in a very small memory

footprint, for which even Jack Ganssle praised it

in
his
Embedded Muse

newsletter
,

#113. The memory efficiency of Contiki is so
impressive that the base system

can be compiled into about 32 kilo
bytes of program data.
The smallest build to date has been
able to run on only 2000 bytes of RAM

and the build
featured the base system, web server, virtual network computing server (VNC)
, and

a
small virtual desktop.


Given the functionality of Contiki, many useful programs have already been
written

for it. They

include the Contiki Tool
-
Kit (CTK) GUI,
command line shell,
web
server, web browser,
telnet client, ftp client, and a VNC server. Each of these programs
expands Contiki to be used for many interesting applications.

With the web server and
telnet command

interface, Contiki becomes a very good operating system choice for use
in an embedded web server system. Also, with the CTK GUI and VNC server interface,
a user can log into a Contiki embedded system and utilize the GUI by using the VNC
interface to rela
y the images from the embedded system to the host computer while
relaying the user keyboard and mouse actions from the host computer back to the
embedded system.


Finally, when comparing Contiki to other real time operating systems, Dunkels
classif
ies

it a
s a light
-
weight multithreading operating system. It is not
completely

constrained as an
event based
operating system, like
TinyOS, yet is not a very heavy
-
weight multithreading environment like eCos, OSE, or Mantis. Contiki fits into a very
nice middle
ground
in
that
it
is suitable for developers who either prefer event based state
machine design or a simplified multithreaded environment
, and that it comes with
networking capabilities

to help support the future designed trends of networked
embedded syste
ms.

Works Cited


Dunkels
,
Adam
. (September 7, 2005).
The Contiki Operating System.

Retrieved

February 22, 2006, from

http://www.sics.se/~adam/contiki/


Dunkels
,
Adam
.
Grönvall
,
Björn
.

Voigt
,
Thiemo
.

Contiki


a Lightweight and Flexible

Operating System for Tiny

Networked Sensors
.

November 16, 2004. Presentation

Retrieved February 22, 2006, from


http://www.sics.se/~adam/slides/contiki
-
emnets.ppt


Dunkels
,
Adam
.
Contiki


an Operating System for Wireless Sensor Networks
.
October

29, 2004. Presentation Retrieved February 22, 2006, from

http://www.sics.se/~adam/slides/enea
-
contiki
-
29oct2004.ppt