Fork me on GitHub

Mailing List

Contiki is developed by a world-wide community of developers and thrives from code contributions from individuals. The center of the community is the contiki-developers mailing list.

Join the contiki-developers list here »

List archives »

Follow the Contiki Development

Contiki development is handled with the git version control software. The Contiki git repository is at github:

Contribute to Contiki

Contiki is made up of code contributions from individuals and organizations. Contributions are handled through the github pull request mechanism. Read more about it here.

The History of Contiki

Contiki was born out of Adam Dunkels' desire to connect unexpected things to the Internet. In 2001, the open source uIP stack was developed as a smaller cousin to lwIP and quickly spread across the embedded world. But uIP wasn't just used in numerous deeply embedded systems, it also Internet-enabled some unexpected things. In 2003, Contiki followed suit.

In 2004, the concept of protothreads, which now forms the basis of Contiki's processes, was introduced in Contiki. Early versions of Cooja and the Rime stack were added with Contiki 2.0 in 2007. Power profiling was developed in 2007. Instant Contiki and the Coffee file system were introduced early 2008. Later in 2008, Cisco contributed the fully certified IPv6 stack to Contiki.

In 2009 and 2010, many new platforms were added to Contiki and new low-power mechanisms were developed. 2011 saw the addition of two important mechanisms: ContikiRPL, for IPv6 routing, and ContikiMAC for sleepy routers.

In 2012, Thingsquare was founded, to bring Contiki to the cloud.

Contiki Developers

Contiki has been developed by a large group of developers. This list aims to mention them and their contributions (in some sort of semi-random order), but with such a long list we may very well have inadvertently left people out. If so, contact us!

The basis of Contiki and most of its core functions, such as the kernel, most libraries, the uIP stack, and the Rime stack, where written by Adam Dunkels. Giovanni Pellerano did the pic32 port. Oliver Schmidt did the Microsoft Windows and Apple II port and was part of the development of protothreads. Niclas Finne worked on the Z1 and Wismot ports and wrote parts of the MSPsim emulator. Joakim Eriksson wrote MSPsim and ContikiRPL. Fredrik Österlind wrote Cooja, the Contiki network simulator, and the regression test framework. Nicolas Tsiftes developed the Coffee file system, ContikiRPL, and the Antelope database. Julien Abeillé and Mathilde Durvy wrote the IPv6 stack and the 6lowpan adaptation layer. Mariano Alvira wrote the econotag port. David Kopf did a lot of work on the Raven port. Matthias Kovatsch wrote Erbium, the Contiki CoAP client and server. Simon Duquennoy optimized ContikiMAC for stream transmission. Simon Barner did an early AVR port. Simon Berg did an AT91SAM7s port. Colin O'Flynn did the AVR Raven port and the USB stick with IPv6 bridging. Eric Gnoske, Michael Vidales, and Blake Leverett did the AVR Raven port. Ivan Delamer, AVR port stuff. Anthony Asterisk did an 8051 port. Zach Shelby did the initial work on the Sensinode port and George Oikonomou developed the CC2530 port. Salvatore Pitrulli did the STM32w port. Dogan Yazar developed an HTTP/CoAP REST layer for Contiki. Enric M. Calvo and Antonio Lignan did the Z1 port. Björn Grönvall did the initial Tmote Sky port. Kasun Hewage did the MiacZ port. Matthias Bergvall wrote a CTK-over-Telnet GUI. Groepaz did initial ports to the NES and PCEngine. Takahide Matsutsuka did a PC-6001 port. Lawrence Chitty did a Sharp Wizard port. Fabio Fumi ported Contiki to the Casio PocketViewer. Matthias Domin did an Atari Jaguar port. Christian Groessler an Atari 8-bit port. Anders Carlsson ported to the VIC-20. James Dessart ported Contiki to the CoCo Color Computer. Chris Morse did the initial work on the Apple II port. Mikael Backlund designed the icon set for the initial Contiki versions.

Automatic code style formatting

The Contiki code tree contains a GNU Indent file for automatic formatting of C files to match the Contiki source code. The script is in contiki/tools/contiki-indent and the GNU Indent specifications in contiki/tools/

The Contiki code style

The Contiki code style is available in the Contiki code tree, in the file contiki/docs/code-style.c:

 * \defgroup coding-style Coding style
 * This is how a Doxygen module is documented - start with a \defgroup
 * Doxygen keyword at the beginning of the file to define a module,
 * and use the \addtogroup Doxygen keyword in all other files that
 * belong to the same module. Typically, the \defgroup is placed in
 * the .h file and \addtogroup in the .c file.
 * @{

 * \file
 *         A brief description of what this file is.
 * \author
 *         Adam Dunkels <>
 *         Every file that is part of a documented module has to have
 *         a \file block, else it will not show up in the Doxygen
 *         "Modules" * section.

/* Single line comments look like this. */

 * Multi-line comments look like this. Comments should prefferably be
 * full sentences, filled to look like real paragraphs.

#include "contiki.h"

 * Make sure that non-global variables are all maked with the static
 * keyword. This keeps the size of the symbol table down.
static int flag;

 * All variables and functions that are visible outside of the file
 * should have the module name prepended to them. This makes it easy
 * to know where to look for function and variable definitions.
 * Put dividers (a single-line comment consisting only of dashes)
 * between functions. 
 * \brief      Use Doxygen documentation for functions.
 * \param c    Briefly describe all parameters.
 * \return     Briefly describe the return value.
 * \retval 0   Functions that return a few specified values
 * \retval 1   can use the \retval keyword instead of \return.
 *             Put a longer description of what the function does
 *             after the preamble of Doxygen keywords.
 *             This template should always be used to document
 *             functions. The text following the introduction is used
 *             as the function's documentation.
 *             Function prototypes have the return type on one line,
 *             the name and arguments on one line (with no space
 *             between the name and the first parenthesis), followed
 *             by a single curly bracket on its own line.
   * Local variables should always be declared at the start of the
   * function.
  int i;                   /* Use short variable names for loop
			      counters. */

   * There should be no space between keywords and the first
   * parenthesis. There should be spaces around binary operators, no
   * spaces between a unary operator and its operand.
   * Curly brackets following for(), if(), do, and case() statements
   * should follow the statement on the same line.
  for(i = 0; i < 10; ++i) {
     * Always use full blocks (curly brackets) after if(), for(), and
     * while() statements, even though the statement is a single line
     * of code. This makes the code easier to read and modifications
     * are less error prone.
    if(i == c) {
      return c;           /* No parentesis around return values. */
    } else {              /* The else keyword is placed inbetween
			     curly brackers, always on its own line. */
 * Static (non-global) functions do not need Doxygen comments. The
 * name should not be prepended with the module name - doing so would
 * create confusion. 
static void

/* The following stuff ends the \defgroup block at the beginning of
   the file: */

/** @} */