Politecnico di Milano Advanced Network Technologies Laboratory

Internet of Things

Contiki and Cooja

Politecnico di Milano Advanced Network Technologies Laboratory

The Contiki Operating System

Contiki o  Contiki features:

n  Open-source n  Highly portable n  Multi-tasking n  Memory-efficient

o  Typical configuration n  2 KB RAM, 40 KB ROM

o  Main key mechanisms widely adopted in the industry n  TCP/IP like communication (uIP / uIPv6) n  Low-power communication stack (Rime)

Other Features

o Other important features of Contiki: n  Dynamic loading / re – programming

(similar to MoteRunner) n  Multi-threading implemented as an

application library (linked optionally if the application explicitly requires it)

o Cons: n  Documentation is rather scarce n  Reading source code is often required to

fully understand functionalities

System overview

o A running Contiki System consists of n  Kernel (event-driven, no HAL) n  Libraries n  Program loader (loading, memory allocation,

initialization) n  Processes (services and applications)

chine is specifically designed for the needs of typical sen-sor network applications. Similarly, the MagnetOS [7] sys-tem uses a virtual Java machine to distribute applicationsacross the sensor network. The advantages of using a vir-tual machine instead of native machine code is that the vir-tual machine code can be made smaller, thus reducing theenergy consumption of transporting the code over the net-work. One of the drawbacks is the increased energy spentin interpreting the code—for long running programs the en-ergy saved during the transport of the binary code is insteadspent in the overhead of executing the code. Contiki pro-grams use native code and can therefore be used for all typesof programs, including low level device drivers without lossof execution efficiency.

SensorWare [8] provides an abstract scripting languagefor programming sensors, but their target platforms are notas resource constrained as ours. Similarly, the EmStar envi-ronment [13] is designed for less resource constrained sys-tems. Reijers and Langendoen [21] use a patch languageto modify parts of the binary image of a running system.This works well for networks where all nodes run the ex-act same binary code but soon gets complicated if sensorsrun slightly different programs or different versions of thesame software.

The Mantis system [3] uses a traditional preemptivemulti-threaded model of operation. Mantis enables repro-gramming of both the entire operating system and partsof the program memory by downloading a program im-age onto EEPROM, from where it can be burned into flashROM. Due to the multi-threaded semantics, every Mantisprogram must have stack space allocated from the systemheap, and locking mechanisms must be used to achieve mu-tual exclusion of shared variables. In contrast, Contiki usesan event based scheduler without preemption, thus avoidingallocation of multiple stacks and locking mechanisms. Pre-emptive multi-threading is provided by a library that can belinked with programs that explicitly require it.

The preemptive multi-threading in Contiki is similar tofibers [4] and the lightweight fibers approach by Welsh andMainland [23]. Unlike the lightweight fibers, Contiki doesnot limit the number of concurrent threads to two. Further-more, unlike fibers, threads in Contiki support preemption.

As Exokernel [11] and Nemesis [16], Contiki tries to re-duce the number of abstractions that the kernel provides toa minimum [10]. Abstractions are instead provided by li-braries that have nearly full access to the underlying hard-ware. While Exokernel strived for performance and Neme-sis aimed at quality of service, the purpose of the Contikidesign is to reduce size and complexity, as well as to pre-serve flexibility. Unlike Exokernel, Contiki do not supportany protection mechanisms since the hardware for whichContiki is designed do not support memory protection.

3. System overview

A running Contiki system consists of the kernel, li-braries, the program loader, and a set of processes. Aprocess may be either an application program or a ser-vice. A service implements functionality used by morethan one application process. All processes, both appli-cation programs and services, can be dynamically re-placed at run-time. Communication between processesalways goes through the kernel. The kernel does not pro-vide a hardware abstraction layer, but lets device driversand applications communicate directly with the hard-ware.

A process is defined by an event handler function andan optional poll handler function. The process state is heldin the process’ private memory and the kernel only keepsa pointer to the process state. On the ESB platform [5],the process state consists of 23 bytes. All processes sharethe same address space and do not run in different protec-tion domains. Interprocess communication is done by post-ing events.

KernelKernel

Core

RAM

ROM

Core

Loaded program

Loaded program

Communication service

Communication service

Language run−time

Program loader

Figure 1. Partitioning into core and loadedprograms.

A Contiki system is partitioned into two parts: the coreand the loaded programs as shown in Figure 1. The parti-tioning is made at compile time and is specific to the deploy-ment in which Contiki is used. Typically, the core consistsof the Contiki kernel, the program loader, the most com-monly used parts of the language run-time and support li-braries, and a communication stack with device drivers forthe communication hardware. The core is compiled into asingle binary image that is stored in the devices prior to de-ployment. The core is generally not modifed after deploy-ment, even though it should be noted that it is possible touse a special boot loader to overwrite or patch the core.

Programs are loaded into the system by the programloader. The program loader may obtain the program bina-

Proceedings of the 29th Annual IEEE International Conference on Local Computer Networks (LCN’04) 0742-1303/04 $ 20.00 IEEE

Contiki services

o A service is a process that can be used by other processes (shared library) n  Communication protocol stack n  Sensor device drivers n  Data handling algorithms

o Services can be replaced!

Contiki libraries

o  The kernel provides only the most basic features.

o The rest of the system is implemented as system libraries (static or dynamic)

o Often used libraries are placed in the Contiki core (e.g., memcpy)

o Rarely-used libraries must be included manually (e.g., atoi)

Multi-threading and protothreads

o  Contiki is an event-driven kernel, but provides support for multi-threading and a thread-like construct called protothread

o  Differently from threads, protothreads do not require a

separate stack (memory saving!).

o  Contiki processes: a single protothread n  Declaration: #define PROCESS (name, strname) n  Start of a process: #define PROCESS_BEGIN() n  End of a process: #define PROCESS_END() n  Body of a process: #define PROCESS_THREAD(name, ev, data)

o  A process always starts with PROCESS_BEGIN() and ends with PROCESS_END()

Useful macros

o AUTOSTART_PROCESS(&process) o  PROCESS_WAIT_EVENT()

n  Blocks the current process until an event is received

o  PROCESS_WAIT_EVENT_UNTIL( c ) n  Similar to the previous one, but an extra

condition must be true to continue

Code example PROCESS(hello_world_process,”Hello World”); AUTOSTART_PROCESS(&hello_world_process); PROCESS_THREAD(hello_world_process,ev,data){

PROCESS_BEGIN(); printf(“Hello world!\n”); while(1){ PROCESS_WAIT_EVENT(); } PROCESS_END();

}

Example: Blink application

o  Two processes: n  hello_world_process: starts a timer and

prints “Hello world” each time n  blink_process: starts a timer, increments

a counter and toggles leds accordingly o  Let’s simulate it with Cooja!

Cooja

o Cooja is a network simulator for Contiki

o Nice features: n  Allows to simulate an heterogeneous

network n  Different type of sensor nodes n  Different applications at the same time n  Nice graphical interface n  Save / load simulation

Why Protothreads?

o  Easier than managing a state-machine

o Code is generally shorter and uses structured programming

o  Logic mechanisms are evident from the code

Programming example

o  TinyOS

Programming Example TinyOS

35/40

Source: T. Voigt, Contiki – a Dynamic Operating System for Networked Embedded Systems

Programming example

o Contiki

Programming Example Contiki

36/40

Source: T. Voigt, Contiki – a Dynamic Operating System for Networked Embedded Systems

Contiki communication: Rime

o Rime: custom lightweight networking stack

o Used when IP overhead is too prohibitive

o  Provided primitives: n  Single-hop broadcast / unicast n  Multi-hop unicast n  Network-flooding n  Data collection

Rime example: broadcast

o  Broadcast connection: n  static struct broadcast_conn broadcast;

o  Open the connection: n  broadcast_open(&broadcast, 129, &broadcast_call); n  First parameter is the connection name n  Second parameter is the channel on which the connection will

operate (different from wireless channel) n  Third parameter is a function pointer to a function that will be called

when a packet has been received

o  Set up the callback n  static const struct broadcast_callbacks broadcast_call =

{broadcast_recv} n  static void broadcast_recv(struct broadcast_conn *c, const

rimeaddr_t *from){do something when a msg is received}

Rime example: broadcast

o Main process PROCESS_THREAD{example_broadcast_process,ev,data) static struct etimer et; PROCESS_BEGIN(); //open the broadcast connection broadcast_open(…); while(1){ etimer_set(&et,CLOCK_SECOND*4); PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et)); packetbuf_copyfrom(“HELLO”,5) //copy into packet broadcast_send(&broadcast); } PROCESS_END();

Other examples

o Rime provides also unicast, reliable unicast and multi hop (mesh) communication

o  For more complex applications, other communication stacks may be directly used! n  uIP (TCP/IP)

Contiki and NodeRED

o Cooja can be attached to NodeRED using the serial monitor

o Data coming from a WSN can be thus used as starting point for high-level, web-based applications

o  Let’s see an example…