IoT OS

High: have conventional OS

• RaspberryPi

• Smartphone

Low:

• Constrained devices

Class 0: « 10 kb RAM and « 100 kB Flash

Class 1: approx. 10 kB RAM and approx. 100 kB Flash

Class 2: offer more ressources, but still constrained in comparison to High-End IoT-Devices.

highly specialized application (e.g. temperature sensor)

low-level programming, bare-metal

operating system (OS) often not required

not meant for highly specialized applications

offer more options, e.g. routing

future of IoT devices

interoperability with the Internet

compability to IP protocols

compability to programming languages and tools ofthe hosts

Small Memory Footprint

Network Connectivity

Power Efficiency

Real-Time Capability

Security

The OS is of extreme importance for embedded systems, because it controls the constrained resources of the device.

Regarding security and safety the OS is facing huge challenges.

Memory Protection

Virtual Memory, e.g. Location Obfuscation

Fault Recovery

Guaranteed Ressources

Virtual Device Drivers

Secure Scheduling

Access Control

Contiki

TinyOS

FreeRTOS

RIOT-OS

nuttX

eCos

uClinux

mbedOS

>2002, OS for WSN, 8-bit MCU

>now: 16-bit, 32-bit MCU

>provides various network stacks:

>e.g. uIP (microIP) with support for IPv6, 6LoWPAN, CoAP;

>Rime communication stack

>2000, OS for WSN, 8-bit & 16-bit MCU

>programming language: nesC

>network stack: BLIP (implements 6LoWPAN)

>2002, used on various MCUs

>no own network stack, but third-party alternatives may be used

>2007, 8-32-bit MCUs

>compability with POSIX and ANSI

>integrated network stack, which supports IPv4 and IPv6

>embedded configurable operating system

>2002, 16-,32- & 64-bit devices

>no own network stack, but supports third-party stacks like 1wIP or FreeBSD network stack

2009, by ARM, mainly for 32-bit ARM

architectures

mbedTLS

ThreadX (Express Logic Inc),

Wind River Rocket (Wind River),

PikeOS (SYSGO AG),

>mbOS (Segger Microcontroller Systems),

LiteOS Huawei, etc.

• Event Driven

• Multi-Threading

• Pure RTOS

Real-Time Internet-of-Things Operating System

developed since 2013

originally focused on WSN and real-time requirements

currently focus on

• IoT

• hardware support expansion

• development & maintainance of various network stacks

optimized for multi-threading

provides very efficient context switching & IPC

(interprocess communication)

offers various stacks for network connectivity

e.g. gnrc network stack supporting IPv6,

6LoWPAN, RPL, UDP, and CoAP.

programming languages for applications: C & C++

RIOT-OS itself is written in ANSI C

drivers do not run in the core

support for JSON, ASN.1 und CBOR

security support

crypto libs

>Modules are internal packages of RIOT-OS

>Packages are external (but represent a

module)

Boards: e.g. PIN config, MCU clock, driver

config,. . .

CPU: CPU-specific implementations

Drivers: all external drivers

Kernel: e.g. scheduling, multi-threading,. . .

Networking: networking libraries

Packages: external libraries/applications

System: tools & utilities for OS, crypto-library

>core → scheduler, IPC, threading, thread

synchronzation, data-structures, type

definitons

>CPU, boards → platform specific code

>drivers → device drivers

>sys, pkg → libraries and network code

>examples, tests → applications to test

various features

>contains the actual kernel

>consists of

• scheduler,

• inter-process-communication (messaging),

• threading, and

• thread synchronization, as well as

• supporting data-structures and

• type definitions

split into two logic elements: CPU and board

>a board has exactly one CPU

>a CPU can be part of n boards

>CPU contains all generic, CPU specific code

>boards contains the specific configuration for

the CPU it contains

mainly includes

>the peripheral configuration and pin-mapping,

>the configuration of on-board devices, and

>the CPU's clock configuration

>contains all CPU specific configurations, such as

>implementations of power management (LPM),

>interrupt handling and vectors,

>startup code,

>clock initialization code and

>thread handling (e.g. context switching) code.

>In the periph sub-directory of each CPU you can

find the implementations of the CPU's peripheral

drivers like SPI, UART, GPIO, etc.

drivers for external devices, e.g.

>network interfaces,

>Sensors, and

>actuators.

>All of RIOT's device drivers are based on the

peripheral driver API (e.g. SPI, GPIO, etc.) and

other RIOT modules like the xtimer. This way

the drivers are completely platform agnostic

and they don't have any dependencies into the

CPU and board code.

>data structures,

>crypto libraries (e.g. hashes, AES),

>high-level APIs,

>memory management (e.g. malloc),

>the RIOT shell,

>and many more.

>RIOT follows the micro-kernel design paradigm

where everything is supposed to be a module. All of

these modules that are not part of the hardware

abstraction nor device drivers can be found in this

directory.

All of RIOT‘s networking code resides here.

>network stack implementations

>network stack agnostic code (header

definitions, network types, etc.)

external libraries (e.g. ccn-lite, microcoap).

>custom Makefile for each supported library

example applications demonstrating certain

features of RIOT.

>check out the README.md files of the

examples

In contrary to the examples these tests are

mostly focusing on a single aspect than on a set

of features.

doc contains the doxygen configuration

>dist contains tools to help you with RIOT

>Pyterm – a serial terminal application,

>generic scripts for flashing, debugging,

resetting, as well as code enabling easy

integration to open testbeds such as the IoT-

LAB.

>scripts for code and style checks.