Comparison of Operating Systems

TinyOS and Contiki

Tobias Reusing
Betreuer: Christoph Söllner
Seminar: Sensorknoten - Betrieb, Netze & Anwendungen SS2012
Lehrstuhl Netzarchitekturen und Netzdienste, Lehrstuhl Betriebssysteme und Systemarchitekturen
Fakultät für Informatik, Technische Universität München
Email: reusing@in.tum.de

ABSTRACT The biggest di↵erence is the hardware on which the operat-

Wireless sensor networks can be used in a lot of di↵erent ing systems are running. The wireless sensor nodes (often
application areas. Since such networks were first proposed, called motes) usually have a microcontroller as a CPU that
many di↵erent node platforms both in regard to hardware is not very powerful because the main focus of those motes
and software were introduced. In this paper we present op- lies in minimal power consumption since they are often de-
erating systems for wireless sensor nodes in general and two signed to run on battery power for very long periods of time.
of the best known operating systems, TinyOS and Contiki And even though the microcontroller and all other compo-
with their most notable di↵erences and similarities. Both nents of motes are designed as low power devices, running
have strengths and weaknesses which are important for var- them all at full power at all times would still consume way
ious requirements of wireless sensor networks. too much energy. So for that matter the main focus of those
operating systems is energy conservation optimal usage of
limited resources[1].
Keywords
TinyOS, Contiki, Operating Systems, Sensor Nodes, Wire-
Operating systems for motes are very simple compared to
less Sensor Networks
other operating systems. But they still are often required
to handle many di↵erent operations at the same time. A
1. INTRODUCTION mote could for example be required to collect data from a
Wireless sensor networks consist of a huge number of single sensor, process the data in some way and send the data to
nodes. They can be used for a wide range of applications. a gateway at the same time. Since the microcontrollers are
For all di↵erent application areas di↵erent requirements have only able to execute one program at the time, the operating
to be fulfilled. While in one application it may be most systems have to have a scheduling system that shares the
important that the nodes can operate unattended for very CPU resources between the di↵erent tasks, so that all of
long periods of time, in another application they may have to them can finish in the desired time frame.
be able to process huge amounts of data in short time frames.
Therefore it is of high importance to choose the right hard Since the requirements for the operating system vary be-
and software components for the particular application. The tween applications it is in most cases not possible to ex-
operating system is one of the most important parts on the change the client program on a mote without changing the
software side of this decision process. There are a lot of operating system. In fact in most cases the operating system
sensor node operating systems available and at first glance behaves more like a library: It gets integrated into the ap-
it is not always easy to determine which one is better suited plication and both the application and the operating system
for which applications. Therefore this paper presents two of are compiled into one single binary that is then deployed
the best known sensor node operating systems and compares onto the sensor node.
them according to di↵erent requirements.
In summary the main requirements for an operating system
Section 2 of this paper presents operating systems for wire- for sensor networks are[1]:
less sensor networks in general. Section 3 and section 4 give
an overview of the features of TinyOS and Contiki respec- • Limited resources: The hardware platforms o↵er very
tively. In section 5 both operating systems are compared limited resources so the operating system should use
according to requirements for wireless sensor nodes and sec- them efficiently.
tion 6 presents the conclusions.
• Concurrency: The operating system should be able to
handle di↵erent tasks at the same time.
2. OPERATING SYSTEMS FOR WIRELESS
• Flexibility: Since the requirements for di↵erent appli-
SENSOR NETWORKS cations vary wildly, the operating system should be
Operating systems that are designed for wireless sensor net-
able to be flexible to handle those.
works are very di↵erent from operating systems for desk-
top/laptop computers like Windows or Linux or operating • Low Power: Energy conservation should be one of the
systems for powerful embedded systems like smart phones. main goals for the operating system.

Seminar SN SS2012 7 doi: 10.2313/NET-2012-08-2_02

Network Architectures and Services, August 2012
3. TINYOS
TinyOS was developed at the University of California in Component 1 Component 2
Berkeley[2] and is now maintained as an open source project
by a community of several thousand developers and users Interface 1 Interface 2 Interface 4 Interface 3

lead by the TinyOS Alliance[12]. The current Version of

TinyOS from April 6, 2010 is 2.1.1.

TinyOS uses an event driven programming model and con-

currency is achieved with non-preemptive tasks[1]. TinyOS Configuration
programs are organized in components and are written in
the NesC language[3], a dialect of C.

3.1 Programming Model Interface 4 Interface 3 Interface 2 Interface 1

As already mentioned, TinyOS user applications and the
operating system itself are composed of components. Com-
Component 3 Component 4
ponents o↵er three types of elements: Commands, Events
and Tasks [1]. All three are basically normal C functions
but they di↵er significantly in terms of who can call them
and when they get called. Commands often are requests to Figure 2: Configurations map the exposed interfaces
a component to do something, for example to query a sensor of components onto each other
or to start a computation. Events are mostly used to signal
the completion of such a request.
TinyOS programs and the operating system itself are written
Tasks, on the other hand, are not executed immediately. in NesC[3]. NesC is a dialect of C. It incorporates all of the
When a task is posted, the currently running program will concepts of TinyOS, like components, interfaces, commands,
continue its execution and the posted task will later be ex- events, tasks, configurations etc. into a C like language. The
ecuted by the scheduler (see section 3.2 for details). biggest di↵erence between C and NesC is how the function
to be executed is selected. In C the function to be executed
Components expose which commands they can send and at a function call is selected by its name. In NesC when a
which events they can handle through interfaces. An in- command or event should be executed the programmer ex-
terface consists of a number of commands and events that plicitly selects with the wiring in configurations which com-
are specified by their function signatures. A component can ponent’s implementation of the command or event should be
either specify to use an interface or to provide it. Com- used[4, p. 13]. But ”normal” C functions can still be used
ponents that provide an interface have to implement all of in NesC and to di↵erentiate between them and commands,
the specified commands and can signal the specified events. events and tasks special keywords are used for invoking each
Components that, on the other hand, use an interface have of the non-C function types. C libraries and C preprocessor
to implement all of the specified events and can use all of directives can be used[4, p. 46-47]. NesC is also designed
the commands [4, p. 26] (cf. Figure 1). to allow whole-program analysis which allows the detection
of data-race conditions which can improve reliability and it
can help with inlining across component border which can
reduce resource consumption[3].
Command
Provider Interface Interface User
3.2 Execution Model
Event TinyOS uses a split-phase execution model[1]. This means
that the request to do an operation and the response after
completion are decoupled. This approach resembles how in-
teraction with hardware in a sensor node often works: The
micro controller sends a request to a hardware component,
Figure 1: An interface specifies which commands which then works on it independently from the controller
the user of the interface can call and which events and later signals the completion of the task through an in-
the provider can signal terrupt. In TinyOS both hardware and software modules
follow this split-phase execution model, which is represented
in the programming model: Both are components that can
The connections between components are specified in so- handle commands and at a later time signal events after the
called configurations. A configuration defines for each inter- completion of the operation.
face of a component which other component uses the pro-
vided interfaces and which component provides the used in- Concurrency in TinyOS is achieved with tasks. Tasks are
terfaces. These connections are called wirings[4, p. 31]. basically functions that can be posted by other tasks or in-
Configurations are itself components, which means that they terrupt handlers[1]. They don’t get executed immediately
can also provide and use interfaces. This makes it possible but instead will later be executed by the scheduler. The
to build TinyOS applications in a hierarchical manner where TinyOS scheduler executes one task after another and so
components on a higher level are made up of several com- tasks can never preempt each other. Each task runs un-
ponents of a lower level (cf. Figure 2). til completion and the next task is started after that. This

Seminar SN SS2012 8 doi: 10.2313/NET-2012-08-2_02

Network Architectures and Services, August 2012
// BlinkC . nc B l i n k module mote platform, a tradeo↵ between lots of short tasks and
module BlinkC { long running tasks that execute the same computation has
uses i n t e r f a c e Boot ; to be found. Since data can not be kept on the stack be-
uses i n t e r f a c e Timer ; tween the execution of tasks, all state information has to
uses i n t e r f a c e Leds ; be kept in the private memory of the tasks component[4, p.
} 74].
implementation {
event void Boot . booted ( ) {
Tasks
c a l l Timer . s t a r t P e r i o d i c ( 1 0 0 0 ) ;
} Application commands, events
Component 1
interrupt handler
event void Timer . f i r e d ( ) {
task execution
c a l l Leds . l e d 0 T o g g l e ( ) ; Application (synchronous)
} Component 2 interrupt execution
} (asynchronous)
Application
Driver Component 3

// BlinkAppC . nc
configuration BlinkAppC { }
implementation { Figure 3: The TinyOS execution model. Compo-
components MainC , LedsC , TimerC , BlinkC ; nent boundaries are crossed between all of the com-
ponents[4]
BlinkC . Boot > MainC . Boot ;
BlinkC . Leds > LedsC . Leds ; 3.3 Resource Use
BlinkC . Timer > TimerC . Timer ; TinyOS was built with the goal of minimal resource con-
} sumption since wireless sensor nodes are generally very con-
strained in regards to processing speed, program memory,
Listing 1: Minimal example of a TinyOS application RAM and power consumption.
that turns a LED on and o↵ every second. With
modifications from [4]
3.3.1 Processing Power
To preserve processing power in TinyOS boundary crossings
between di↵erent components are optimized. Since all func-
tion locations are known at compile time and there is no
makes it possible that all tasks can use the same stack, which address-space crossing basic boundary crossing has at most
saves memory because not every task needs it’s own desig- the overhead of a single procedure call. With whole-program
nated stack like in a multi-threaded approach (see section 3.3 analysis many boundary crossings can be entirely removed.
for details). Normally tasks are executed in a first-in-first- In some cases the compiler can even inline a whole compo-
out (FIFO) order, so tasks run in the same order they’re nent into it’s caller[3].
posted[4], but it is possible to implement other (more com-
plex) scheduling strategies[2]. If there is no more task in the To keep the overhead of task-switching minimal the sched-
queue after completion of the previous task, TinyOS sets the uler in TinyOS is very simple. For example tasks have no
mote into a low-power sleep state until an interrupt wakes return value and take no parameters so the scheduler does
the microcontroller[4]. not need to take care of them[4, p. 72].
Code in TinyOS can only be executed in the context of ei-
ther a task or an interrupt. Interrupts can preempt tasks 3.3.2 Program Memory
and other interrupt handlers of lower priority. Code that is Since it is known at compile time, which components and
reachable from an interrupt handler is called asynchronous which parts of those components of the application and the
code and special measures have to be taken to handle con- operating system are used, the compiled image of the ap-
currency issues that can occur because of that (see Figure 3 plication includes only the actually used procedures and as
or [4, p. 192 ↵] for further details). good as no dead code. Also the operating system itself has
a very low memory footprint: The core TinyOS operating
Since tasks in TinyOS can not be preempted, long running system uses less than 400 bytes of program memory[3].
tasks, for example tasks that handle complex computations
like cryptographic functions, will block the whole application 3.3.3 RAM
and tasks that are time critical, like tasks handling sending Keeping the RAM usage of wireless sensor nodes low is
and receiving of data over a communication medium, may very important, since the used microcontrollers are very re-
be waiting for too long before the scheduler executes them. stricted in RAM size. For example the Atmel Atmega128L
In those cases the long running computation should be split micocontrollers used in the MICA2 sensor node[15] only of-
up in shorter running tasks that post themselves after com- fers 4 Kbytes of RAM[16] which have to be shared between
pleting a part of the computation, which enables other tasks the operating system and all running user programs. There
to run in between them. Since posting and executing a task are no memory management units (MMU) or other memory
generates a overhead of about 80 clock cycles on a current protection measures available on these microcontrollers so

Seminar SN SS2012 9 doi: 10.2313/NET-2012-08-2_02

Network Architectures and Services, August 2012
the risk of stack overflows (when the stack exceeds it’s max- to be ported to TinyOS. This is not trivial and can get very
imum size) should be avoided. The execution model with complex depending on the hardware[14].
run to completion tasks is very efficient in terms of RAM
usage, since all tasks use the same stack as opposed to a To make software for TinyOS as platform independent as
classic multi-threading approached where each thread needs possible but at the same time o↵er the possibility to push the
a designated stack for itself. To further decrease stack size hardware to its limits with platform specific code, the hard-
deep call hierarchies inside tasks should be avoided. TinyOS ware abstraction architecture (HAA) was introduced. The
programmers are especially discouraged of using recursion HAA o↵ers three levels of hardware abstraction for drivers[4,
and other similar techniques[4, p. 36-38]. p. 206-207]:

3.3.4 Power Consumption

• The hardware interface layer (HIL): This is the most
Since many wireless sensor nodes run on battery power, en-
platform independent level of device drivers. It o↵ers
ergy consumption should be kept as low as possible. To
only the functionality that is common to all devices
achieve a low power consumption the microcontroller should
that use the common interfaces.
be kept in a low power sleep state for as long as possible.
For example the Atmel Atmega128L needs a supply current • The hardware adaption layer (HAL): The HAL is a
in the magnitude of a few milliamperes when active. In the tradeo↵ between platform independence and the use of
lowest sleep state a current of only a few microamperes[16] platform specific code. It should o↵er platform inde-
is sufficient, which means the di↵erence between power con- pendent interfaces when possible and platform specific
sumption in active and sleep states can be a factor of 1000 interfaces in all other cases
or more. TinyOS copes with this by using the split-phase
and event-driven execution model. As long as there are no • The hardware presentation layer (HPL): The platform
tasks in the task queue the scheduler puts the CPU in sleep specific level of the HAA. It sits directly on top of the
mode. So in combination with the split-phase operation the hardware and o↵ers all of it’s functionality in a NesC
CPU does not waste energy while waiting for other hardware friendly fashion.
components[1].
3.5 Toolchain
But the CPU is not the only power critical component in a The core of the TinyOS toolchain is the NesC compiler. Cur-
wireless sensor mode, periphery hardware can use a lot of rent implementations of the NesC compiler take all NesC
power, too. For example the radio is in most cases the most files, including the TinyOS operating system, that belong
expensive part of the node in respect to energy consump- to a program and generate a single C file. This C file can
tion[4, p. 7]. To save energy in those components TinyOS then be compiled by the native C compiler of choice for the
has a programming convention that allows subsystems to be target platform. The resulting binary can then be deployed
put in a low power idle state. Components have an inter- on the motes in a appropriate way. Many optimizations are
face, which exposes commands to tell the component to try already done by the NesC compiler, for example the exclu-
to minimize it’s power consumption, for example by power- sion of dead code. Furthermore the output C file of the
ing down hardware, and to wake up again from those power NesC compiler is constructed in a way, that makes it easy
saving states[1]. for the C compiler to further optimize it. Since it is just
one single file the C compiler can freely optimize across call
3.4 Hardware Platforms boundaries.
The current release of TinyOS supports quite a few sensor
node hardware platforms. This includes di↵erent motes by Apart from the actual build toolchain there is also a TinyOS
Crossbow Technologies like the MICA family of motes or simulator called TOSSIM[5]. It can simulate whole TinyOS
the iMote2 developed at Intel Research and many more[13]. programs and the underlying motes without the need of ac-
These hardware platforms run on a range of di↵erent micro- tually deploying it on hardware. With TOSSIM it is possible
controller including the ATMEL AVR family of 8-bit micro- to simulate sensor node networks of thousands of nodes.
controllers, the Texas Instruments MSP430 family of 16-bit
microcontrollers, di↵erent generations of ARM cores, for ex-
ample the Intel XScale PXA family, and more[13].
4. CONTIKI
Contiki is a open source operating systems for sensor nodes.
It is of course possible to use TinyOS for a custom or not It was developed at the Swedish Institute of Computer Sci-
yet supported hardware platform. The platforms in TinyOS ence by Dunkels et al. [6]. It’s main features are dynamic
are designed to be very modular. For each of the sup- loading and unloading of code at run time and the possibility
ported microcontrollers and other hardware, for example of multi-threading atop of an event driven kernel, which are
radio chips, components exist in the TinyOS installation. discussed in sec. 4.1 and sec. 4.2 respectively. It’s current
To port TinyOS to a platform it basically suffices to spec- version is 2.5 released on September 12, 2011.
ify which components to use, how they are connected to
each other (for example which pins of the microcontroller 4.1 Programming Model
are connected to the radio chip) and to configure each of the A Contiki application consists of the Contiki kernel, libraries,
components correctly[14]. the program loader and processes. Processes are either ser-
vices or an application program. The di↵erence between
If a hardware device of a platform is not supported by Tiny- services and application programs is, that the functional-
OS a driver has to be programmed or a existing driver has ity of services can be used by more than one other process,

Seminar SN SS2012 10 doi: 10.2313/NET-2012-08-2_02

Network Architectures and Services, August 2012
while application programs only use other processes and do // b l i n k . c
not o↵er functionality for di↵erent other processes[6]. PROCESS( b l i n k p r o c e s s , ” b l i n k example ” ) ;
AUTOSTARTPROCESSES(& b l i n k p r o c e s s ) ;
Each of the processes must implement an event handler func-
tion and can optionally implement a poll handler function. PROCESSTHREAD( b l i n k p r o c e s s , ev , data )
Processes can be executed only through these handlers. Ev- {
ery process has to keep its state information between calls of PROCESS BEGIN( ) ;
these functions, since the stack gets restored after the return l e d s o f f (LEDS ALL ) ;
from these functions[6]. s t a t i c struct e t i m e r e t ;
while ( 1 ) {
One of the special features of Contiki is the ability to replace e t i m e r s e t (& et , CLOCK SECOND) ;
all programs dynamically at run-time. To accomplish that
Contiki o↵ers a run-time relocating function. This function PROCESS WAIT EVENT( ) ;
can relocate a program with the help of relocation infor- l e d s t o g g l e (LEDS GREEN ) ;
mation that is present in the program’s binary. After the }
program is loaded the loader executes its initialization func- PROCESS END( ) ;
tion where one or more processes can be launched[6]. }
A running Contiki system consists of the operating system Listing 2: The example from Listing 1 implemented
core and the loaded programs. The core typically consists as a protothread for Contiki. With modifications
of the kernel, di↵erent libraries and drivers and the pro- from [17]
gram loader (See Figure. 4). The core usually is deployed
as one single binary while the loaded programs each can be
distributed independently[6].
TinyOS these handlers all can operate on the same stack
and do not need a private stack of their own[6].

Loaded programs There are two kinds of events in Contiki: Asynchronous

and synchronous events. Asynchronous events work similar
to the posting of tasks in TinyOS. When an asynchronous
event is signaled the scheduler enqueues the event and will
call the corresponding event handler after all currently en-
Drivers queued events were processed. Synchronous events on the
other hand are more like inter-process procedure calls: The
Libraries scheduler immediately calls the corresponding event handler
and returns the control to the calling process after the event
Program loader handler has finished running.

Kernel While event handler can not preempt each other, interrupts
can of course preempt the current running process. To
prevent race-conditions from happening, events can not be
Core
posted from within interrupt handlers. Instead they can re-
quest the kernel to start polling at the next possible point
in time.
Figure 4: The partitioning of the Contiki core and
the loaded programs
On top of this basic event-driven kernel other execution
models can be used. Instead of the simple event handlers
processes can use Protothreads[7]. Protothreads are simple
The Contiki kernel o↵ers no hardware abstraction. If hard-
forms of normal threads in a multi-threaded environment.
ware abstraction is desired libraries and/or drivers have to
Protothreads are stackless so they have to save their state
implement it themselves. All components of a Contiki ap-
information in the private memory of the process. Like the
plication have direct access to the underlying hardware.
event handler Protothreads can not be preempted and run
until the Protothread puts itself into a waiting state until it
4.2 Execution Model is scheduled again[7].
The Contiki kernel is event-driven. Processes can only be
executed by the scheduler when it either dispatches an event Contiki also comes with a library that o↵ers preemptive
to the event handler of the process or by calling the polling multi-threading on top of the event-driven kernel. The li-
handler. While events always have to be signaled by a pro- brary is only linked with the program if an application ex-
cess, the scheduler can be configured to call the polling han- plicitly uses it. In contrast to Protothreads this multi-thread-
dlers of all processes that implement one in periodic intervals ing approach requires every thread to have it’s own desig-
between the dispatching of events. Both the event handlers nated stack[6].
and the polling handlers are not preempted by the scheduler
and therefore always run to completion. Like the tasks in Both multi-threading approaches were introduced because

Seminar SN SS2012 11 doi: 10.2313/NET-2012-08-2_02

Network Architectures and Services, August 2012
modeling application in the event-driven approach can be While Contiki also uses an event-driven kernel it also
very complex depending on the specific requirements of the has di↵erent libraries that o↵er di↵erent levels of multi-
program. The event-driven execution model requires in most threading on top of that. But there are e↵orts to o↵er
cases the implementation of a state machine to achieve the libraries similar to those of Contiki, for example by
desired behavior, even if the programmer may not be aware Klues et al. [8] or MacCartney et al. [9].
of that. Dunkels et al. suggest in [7] that the code size
of most programs can be reduced by one third and most • Flexibility: Both operating systems are flexible to han-
of the state machines could entirely removed by using Pro- dle di↵erent types of applications. When it comes to
tothreads. While the overhead in execution time is minimal updating an application that is already deployed Con-
there is a moderate increase in the program memory required tiki can dynamically replace only the changed pro-
by this approach. grams of the application, while an application using
TinyOS has to be replaced completely, including the
operating system. But there are solutions for mak-
4.3 Resource Use ing dynamic loading op application code possible for
Since the scheduler and the kernel in general are more com-
TinyOS, for example by introducing a virtual mach-
plex in Contiki than in TinyOS and the possibility of dynam-
ine[10, 11].
ically load processes, which doesn’t allow cross boundary
optimization, the required program memory and execution • Low Power: TinyOS has out-of-the-box better energy
time for Contiki programs is higher than that of TinyOS conservation mechanisms but for Contiki similar power
programs. When using the preemptive multi-threading li- saving mechanisms can be implemented.
brary the RAM usage will be higher than using only the
event-driven kernel for scheduling[6]. 6. CONCLUSION
Both operating systems can generally fulfill all of the dis-
4.4 Energy Consumption cussed requirements. In details there are di↵erences, so
The Contiki operating system o↵ers no explicit power saving while TinyOS is better suited when resources are really scarce
functions. Instead things like putting the microcontroller or and every little bit of saved memory or computing power can
peripheral hardware in sleep modes should be handled by help, Contiki might be the better choice when flexibility is
the application. For that matter the scheduler exposes the most important, for example when the node software has to
size of the event queue so that a power saving process could be updated often for a large amount of nodes.
put the CPU in sleep mode when the event queue is empty.
This paper is not an in depth discussion of both operating
4.5 Hardware Platforms systems. When choosing the operating system for a specific
Contiki has been ported to a number of mote platforms application many things have to be considered and not all
on basis of di↵erent microcontrollers. Supported micro- could be presented here. These two operating systems are
controller include the Atmel AVR, the Texas Instruments also not the only operating systems for wireless sensor nodes
MSP430 and the Zilog Z80 microcontrollers[6]. so others may be considered.

Porting Contiki requires to write the boot up code, de- 7. REFERENCES

vice drivers and parts of the program loader. If the mul- [1] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K.
tithreading library is used, its stack switching code has to Whitehouse, A. Woo, D. Gay, J. Hill, M. Welsh, E.
be adapted. The kernel and the service layer are platform Brewer TinyOS: An operating system for sensor
independent. According to Dunkels et al. in [6] the port for networks In Ambient intelligence, p. 115-148,
the Atmel AVR was done by them in a view hours and the Springer, Berlin, 2005
Zilog Z80 port was made by a third party in one single day. [2] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. E. Culler,
K. S. J. Pister System architecture directions for
4.6 Toolchain networked sensors In SIGPLAN Not. 35 (11), p.
Contiki is written in plain C so a native C compiler for the 93–104, ACM, 2000
target platform can be used. [3] D. Gay, P. Levis, R. von Behren, M.Welsh, E. Brewer,
and D. Culler The nesC language: A holistic approach
5. DISCUSSION to networked embedded systems In Proceedings of the
As presented in sec. 2 operating systems for wireless sensor ACM SIGPLAN 2003 Conference on Programming
nodes have to fulfill a few requirements. After the look at Language Design and Implementation (PLDI), ACM,
both TinyOS and Contiki we now compare both operating 2003
systems by means of these requirements: [4] P. Levis, D. Gay TinyOS Programming Camebridge
University Press, Camebridge, 2009
[5] P. Levis, N. Lee, M. Welsh, D. Culler TOSSIM:
• Limited resources: Both operating systems can be run
Accurate and scalable simulation of entire TinyOS
on microcontrollers with very limited resources. But
applications In Proceedings of the 1st international
due to the higher complexity of the Contiki kernel
conference on Embedded networked sensor systems, p.
TinyOS can generally get by with lower resource re-
126-137, ACM, 2003
quirements.
[6] A. Dunkels, B. Grönvall, T. Voigt Contiki - a
• Concurrency: TinyOS o↵ers only the event-driven ker- Lightweight and Flexible Operating System for Tiny
nel as a way of fulfilling the concurrency requirements. Networked Sensors In Proceedings of the First IEEE

Seminar SN SS2012 12 doi: 10.2313/NET-2012-08-2_02

Network Architectures and Services, August 2012
 Workshop on Embedded Networked Sensors, Tampa,
Florida, USA, 2004
[7] A. Dunkels, O. Schmidt, T. Voigt, M. Ali
Protothreads: Simplifying Event-Driven Programming
of Memory-Constrained Embedded Systems In
Proceedings of the Forth International Conference on
Embedded Networked Sensor Systems, p. 29-42, ACM,
2006
[8] K. Klues, C.J.M. Liang, J. Paek, R. Musaloiu-E, P.
Levis, A. Terzis, R. Govindan TOSThreads:
thread-safe and non-invasive preemption in TinyOS In
Proceedings of the 7th ACM Conference on Embedded
Networked Sensor Systems, p. 127-140, ACM, 2009
[9] W. P. McCartney, N. Sridhar Stackless Preemptive
Multi-Threading for TinyOS In Proceedings of the
2011 International Conference on Distributed
Computing in Sensor Systems (DCOSS), IEEE, 2011
[10] P. Levis, D. Culler Maté: a tiny virtual machine for
sensor networks In Proceedings of the 10th
international conference on Architectural support for
programming languages and operating systems, p.
85-95, ACM, 2002
[11] A. Dunkels, N. Finne, J. Eriksson, T. Voigt Run-time
dynamic linking for reprogramming wireless sensor
networks In Proceedings of the 4th international
conference on Embedded networked sensor systems, p.
15-28, ACM, 2006
[12] TinyOS Open Technology Alliance,
http://www.cs.berkeley.edu/~culler/tinyos/
alliance/overview.pdf
[13] TinyOS Wiki - Platform Hardware,
http://docs.tinyos.net/tinywiki/index.php?
title=Platform_Hardware&oldid=5648
[14] TinyOS Wiki - Platforms, http://docs.tinyos.net/
tinywiki/index.php?title=Platforms&oldid=4712
[15] Crossbow Technology MICA2 Datasheet
http://bullseye.xbow.com:81/Products/Product_
pdf_files/Wireless_pdf/MICA2_Datasheet.pdf
[16] Atmel Corporation ATmega128/L Datasheet
http://www.atmel.com/Images/doc2467.pdf
[17] Zoleria Dokumentation Wiki,
http://zolertia.sourceforge.net/wiki/index.
php?title=Mainpage:Contiki_Lesson_1&oldid=1138

Seminar SN SS2012 13 doi: 10.2313/NET-2012-08-2_02

Network Architectures and Services, August 2012