RIOT

In a nutshell

RIOT powers the Internet of Things like Linux powers the Internet. RIOT is a free, open source operating system developed by a grassroots community gathering companies, academia, and hobbyists, distributed all around the world.

RIOT supports most low-power IoT devices, microcontroller architectures (32-bit, 16-bit, 8-bit), and external devices. RIOT aims to implement all relevant open standards supporting an Internet of Things that is connected, secure, durable & privacy-friendly.

Out of the box usage

Features

Security
RIOT enables secure IoT applications.

RIOT supports DTLS transport layer security, IEEE 802.15.4 encryption, Secure Firmware Updates (SUIT), multiple cryptographic packages, and crypto secure elements.

Connectivity
RIOT breaks silos.

RIOT is modular to adapt to application needs. We aim to support all common network technologies and Internet standards. RIOT is open to new developments and often an early adaptor in networking.

Quality
RIOT is constantly tested.

The RIOT community cares about code quality. Therefore, we use established tools such as embUnit - Unit Testing and Continuous Integration, performing Hardware in the Loop (HIL) testing on multiple boards nightly.

License
RIOT is free and open source.

Most of the software developed by the RIOT community is available under the terms of the GNU LGPLv2.1, published by the Free Software Foundation. This ensures an open Internet and allows for building blocks under different licenses.

Developer Friendly

Program as you are used to. Save time with common environments.

  • Standard programming in C or C++
  • Standard tools: gcc, gdb, valgrind
  • Zero learning curve for embedded programming
  • Code mostly without hardware dependence
  • Code once, run on 8-bit (e.g., Arduino Mega 2560), 16-bit (e.g., MSP430), and 32-bit platforms
  • Benefit from POSIX APIs
  • Develop under Linux, Mac OS, or Windows
  • Use the native port, deploy on embedded device when running

Resource Friendly

Benefit from a microkernel and tickless scheduling on the lower end.

  • Robust runtime system
  • Modular for flexible code-footprint
  • Fosters energy-efficiency
  • Real-time capable by limiting interrupt latency (~50 clock cycles) and priority-based scheduling
  • Multi-threading with ultra-low overhead (<25 bytes per thread)

IoT Friendly

Make your applications ready for the smaller things on the Internet.

  • 6LoWPAN, IPv6, RPL, UDP, TCP, QUIC
  • MQTT-SN, CoAP, and CBOR
  • BLE, LoRaWAN, 802.15.4, WLAN, CAN
  • LwM2M client integration
  • Static and dynamic memory allocation
  • High resolution and long-term timers
  • Tools and utilities (System shell, Crypto primitives, ...)
  • Automated testing on various embedded hardware in the loop

35241

Commits

290

Contributors

227

Boards

63

Supported CPUs

Get in touch

On the shoulders of a grassroots community


Developers

You want to participate and contribute to the kernel development or integrate new MCU and platform support? You're welcome!

Read the newcomer guide and scan through our community processes. Subscribe to the RIOT Forum, which is the right place in case you have questions. For live discussions, join the IRC channel #riot-os at irc.freenode.net or our Matrix chat.

The RIOT issue tracker informs about bugs and enhancement requests. You could also subscribe to the notifications mailing list to get informed about new issues, comments, and pull requests. All commits to the source code will be posted to the commits mailing list. Take a look at our coding conventions.

Users

Whether you are looking for help with writing an application for RIOT, learn more about it, or just want to stay in the loop, you are invited to join the RIOT Forum. We are also available on Stack Overflow.

If you are looking for existing open source projects that are based on RIOT, you can check GitHub #riot-os and hackster.io.

RIOTers meet face to face at the annual RIOT Summit.

Contributors from industry, academia, and hobbyist

RIOT in the wild

Users

Continental
Locha Mesh
Sapienza University of Rome
Savoir-faire Linux
SSV Embedded Software Systems
wolfSSL

User stories

We use RIOT in our after-market product for connected car-sharing. RIOT's modular architecture helped us a lot to address the multiple challenges we faced, to design software and networking embedded on a low-power 32-bit microcontroller. Also, RIOT is fun to tinker with, and the RIOT community is very open minded!

Vincent Dupont

Vincent Dupont

IoT Software Architect, Continental

In Locha Mesh, we decided to use RIOT for a variety of reasons, including an active community surrounding it, the overall design of the Operating System that's coupled with a powerful and extensible network stack, and the support for a good variety of CPUs and boards.

Jean Pierre Dudey

Jean Pierre Dudey

Embedded Software Developer, Locha Mesh

At Sapienza University of Rome, we train our computer engineer students based on RIOT to gain practical skills and knowledge about the IoT. The wide range of tools and experimentation facilities for cross-layer debugging and profiling will be valuable for them when developing, testing, and evaluating IoT applications in future professions.

Ioannis Chatzigiannakis

Ioannis Chatzigiannakis

Professor of Computer Engineering, Sapienza University of Rome

We chose RIOT in our products because of the excellent support of microcontrollers, boards, and peripherals. Our customers benefit from the modular architecture in RIOT, which enables easy customization.

Jürgen Fitschen

Jürgen Fitschen

System Engineer, SSV Embedded Software Systems

At wolfSSL we love how easy it is to integrate all the components in the RIOT ecosystem, and the large selections of IoT targets supported. The wolfSSL TLS library and the wolfCrypt cryptography engine are available as built-in RIOT modules, distributed with a GPLv2 license.

Daniele Lacamera

Daniele Lacamera

Embedded Software Engineer, wolfSSL

F.A.Q

Frequently Asked Questions

  • The license is currently LGPLv2.1

  • Studies such as this one show that small companies and start-ups are going to determine IoT. More than bigger companies, such small structures need to spread development and maintenance costs for the kernel and all the software that is not their core business. Our analysis is that this is more compatible with LGPL than with BSD/MIT.

    We are of the opinion that, compared to BSD/MIT, LGPL will improve final user experience, security and privacy, by hindering device lock-down, favoring up-to-date, and field-upgradable code. We think this a more solid base to provide a consistent, compatible, secure-by-default standard system which developers can build upon to create trustworthy IoT applications, while not hindering business models based on closed source linked with RIOT (see the automated tools provided to help check LGPL compliance, and/or this technical guide)

    Since solutions competing with RIOT are quasi-exclusively BSD/MIT, we gauge that LGPL is a way to stand out favorably, and is a characteristic backing positive comparisons of RIOT with Linux.

    Last but not least, we think that (L)GPL is a better base than BSD/MIT to keep the community united in the mid and long run.

    For the record: we have also considered MIT/BSD (see this thread), but there was not enthusiastic majority supporting such a switch.

    Compare https://github.com/RIOT-OS/RIOT/issues/2128

  • In short there are certain Coding Conventions to follow and we are using Github’s pull requests for code review. So for new features and fixes create a fork of the RIOT repository and open a pull request with a detailed description of your changes.

    For a more in depth description check out the dedicated document on development procedures.

    Also, do check out the open community processes.

  • The Starter Guide might be just what you are looking for.

  • First of all, welcome to the RIOT community! There is a dedicated README on contributing listing opportunities to interact with fellow RIOT enthusiasts and some suggestions how to get started.

  • Log an issue in GitHub. Then post to the mailing list devel@riot-os.org and/or users@riot-os.org. For critical vulnerabilities we would appreciate you to report them with a 90 day heads-up to security@riot-os.org first, before making them publicly available. You’re also welcome to ask in the IRC channel #riot-os at freenode.net, but don’t be disappointed if everyone there is busy. It is also a very good idea to search our forum.

  • Check out this page on supported hardware. If your hardware is not listed there, you’re welcome to provide a port for your hardware!

  • This depends on the board and on the application. When you compile an application for a board, the last thing printed gives each sections memory footprint and looks like this:

        text       data     bss     dec     hex filename
        77732     296   24272  102300    18f9c applications/sixlowapp/bin/iot-lab_M3/sixlowapp.elf
    

    The required RAM is data + bss, ROM is text + data.

    Please note: Usually a big portion of RAM is consumed by the stack space for threads. Although RIOT maintainers try to optimize the default values, manual tweaking may be necessary to get the most efficient results. You can check the maximum stack usage at runtime with the shell command ps or the corresponding function thread_print_all() from the module ps.

  • See this page.

  • No. From the RIOT point of view the Raspberry PI is a supercomputer. RIOT targets mostly systems that are too constrained to run Linux (less than 1MB of RAM, no MMU). However, it is supported to run RIOT native on platforms like the Raspberry PI, and other hardware supported by Linux or BSD.

    A good rule of thumb concerning RIOT support of a particular board is: can Linux support this board? If yes, then you should ask yourself why you really want to use RIOT (other than native) on this board. If no, then RIOT support is probably desirable.

  • There is not much to be gained from 64 bit support as RIOT does not target any other platforms that offer 64 bit. That being said there are pros and cons.

    Pro:

    • improve RIOT’s code base by fixing 64 bit related errors
    • simplify toolchain setup for native

    Con:

    • effort / gain (as it’s unlikely we will support any other 64 bit platform, fixing potential 64 bit errors in RIOT is less beneficial)
    • decreased 32 bit testing (unless we make 32 the default in which case the toolchain setup argument is diminished)

    From our perspective this does not justify pulling manpower from other tasks. Nobody will stop you from adding support if you want to, though ;)

    See also: https://github.com/RIOT-OS/RIOT/issues/6603

  • Please consider the following references for citation.