By
Lotte Steenbrink

Starting a RIOT in the Internet of Plants

An operating system choice for low-power embedded devices

Battery powered embedded devices such as our plant nodes lack the hardware resources to support common operating systems such as Linux or Windows. In addition, they have very different requirements: our plant nodes do not need a snappy graphical user interface or have to be able to host hundreds of applications simultaenously. What they do need is an operating system that is energy and memory efficient and features low-power wireless connectivity based on open standards.

Operating Systems such as Contiki, TinyOS or RIOT are designed to operate in the challenging environment of interconnected embedded devices, differing mainly in kernel architecture and the programming models that are employed for application development. This article explains our motivation for choosing RIOT over its alternatives.

Why we chose RIOT.

RIOT is an actively maintained Open Source project with a growing, friendly community. It features a network stack based on open standards, namely 6LoWPAN and IEEE 802.15.4. The latter offers an energy-efficient physical and MAC layer while the former adapts conventional IPv6 to IEEE 802.15.4’s constraints in terms of packet size through fragmentation and header compression (among other techniques). And since RIOT is a microkernel OS, we can specifically include only the features we need, shaving valuable bytes off of our memory footprint.

Event-based operating systems such as Contiki or TinyOS have adopted a programming model that differs from conventional C applications and only support a subset of the C language (Contiki) or provide a C dialect (TinyOS) for application development. RIOT, in contrast, offers a “traditional” threading and scheduling scheme, POSIX-compliance as well as C and (currently partial) C++ language support. This means that if you’re familiar with standard C, you won’t have to adapt to new coding paradigms to write applications for RIOT and can dive right in. It also makes it possible to port existing code, which was originally written for “traditional”, commodity operating systems, to RIOT with just a few patches, allowing for the inclusion of existing external libraries (provided there are no license clashes).

RIOT’s “native mode” makes it possible to run RIOT applications on a POSIX-compliant operating system such as Linux or OS X for testing and debugging. It is even possible to run multiple instances of RIOT applications on the same host, with communication between them enabled through virtual network devices (i.e. tun/tap). This enables a much faster feedback loop when developing and testing applications, but can prove tricky if constraints of the target hardware are not taken into account when developing primarily in native mode.

Summing up, RIOT has so far proven to be a great foundation for the development of our plant nodes and we hope to be able to contribute to RIOT’s progress with our efforts on watr.li. Since development on RIOT is an ongoing effort, some development aspects are still a little rough around the edges. A lot of work is still ahead of us, but we are confident that the growing number of awesome contributors will continue making RIOT a successful open-source option for IoT operating systems.

Last but not least it is worth mentioning that Snappy Ubuntu Core is collaborating with RIOT, which will come in handy when delivering RIOT-based applications to more homogeneous networks which include nodes with increased computing power and energy resources, for which Snappy may prove to be a better fit.

In the interest of full disclosure: All four watr.li contributors use RIOT on a more or less regular basis, either at work and/or for university projects. We are all active RIOT contributors.