Contiki

Contiki is a low-overhead operating system for embedded devices that supports per-process optional preemptive multi-threading. It is not a Real Time Operating System.

Radio and Network

Contiki uses a layered network stack with clear boundaries between the functionality of each layer.

Networking should be initialised with the netstack_init() function from core/net/netstack.c. This will initialise the radio driver, RDC, MAC and NETWORK layers by calling their respective init() functions. Optionally, if NETSTACK_ENCRYPTION_INIT is defined NETSTACK_ENCRYPTION_INIT() will also be called.

Radio Driver

The radio driver is the interface between Contiki and the underlying radio hardware. The driver to use is specified in the platform configuration with the NETSTACK_CONF_RADIO define. The driver is accessed by higher layers through the NETSTACK_RADIO define. All Contiki Radio Drivers must provide certain functions to work correctly.

On reception of a packet, the radio driver needs to call NETSTACK_RDC.input() once it has loaded a packet into the packet buffer.

RDC Layer

This layer is responsible for the Radio Duty Cycling. The driver to use is specified in the platform configuration with the NETSTACK_CONF_RDC define and is accessed through the NETSTACK_RDC define.

sicslowmac_driver contikimac_driver nullrdc_driver border_router_rdc_driver stub_rdc_driver cxmac_driver

MAC Layer

The driver to use is specified in the platform configuration with the NETSTACK_CONF_MAC define and is accessed through the NETSTACK_MAC define.

csma_driver nullmac_driver

Framer

The driver to use is specified in the platform configuration with the NETSTACK_CONF_FRAMER define and is accessed through the NETSTACK_FRAMER define.

framer_802154 no_framer framer_nullmac

Network

The driver to use is specified in the platform configuration with the NETSTACK_CONF_NETWORK define and is accessed through the NETSTACK_NETWORK define.

sicslowpan_driver (6LoWPAN) rime_driver (IPv4) slipnet_driver

Gotchas

802.15.4 Frame Control Field

The bit-order of the Frame-Control Field is not as intuitive as it could be. 802.15.4 requires that bit 0 of the first octet is transmitted first. This means that the FCF, when represented in hex, is generally represented as Bits 7-0 as the first character and Bits 15-8 as the second character.

For example, the Frame Control Field 0xC841 is depicted in the following table. This is represented during TX and RX (at least by a CC1120) as 0x41C8. The 802.15.4 standard requires that the PHY transmits bit 0 (Frame Type) first.

Frame Type	Security Enabled	Frame Pending	Ack Request	PAN ID Compression	Reserved	Dest Addr Mode	Frame Version	Source Addr Mode
0-2	3	4	5	6	7-9	10-11	12-13	14-15
100	0	0	0	1	000	01	00	11
Data	-	-	-	Enabled	-	16-bit Short	2003	64-bit Extended

802.15.4 Address Order

The byte-order of addresses is transmitted/received in the reverse of how the address is stored as in a rimeaddr_t. e.g. rimeaddr.u8[7] = rxaddr[0]

Received buffer size

This is of a limited size and can cause problems with nodes getting backlogged if data is sent to the node at too high a rate.

Websense wepage over high-latency links

Firefox, Chrome, etc. may timeout and refuse to load the webpage on high-latency links. The workaround is to use Telnet to connect to the target node on port 80 and then issue a "GET / HTTP1.0"

rtimer

This cannot be used for a period of longer than a second

Bugs

Contiki 2.7 Bugs

Platforms

• Sky motes