# RIOT OS: an open-source RTOS aimed squarely at constrained devices

> A vendor-neutral microcontroller operating system written mostly in C, covering 8-bit AVR chips through 32-bit Cortex-M parts, with a native port that runs the whole thing on a laptop.

**RIOT-OS/RIOT** — RIOT -  The friendly OS for IoT

- Repository: https://github.com/RIOT-OS/RIOT
- Website: https://riot-os.org
- Stars: 5,822 · Forks: 2,112
- Language: C
- License: LGPL-2.1
- Published: 2026-10-08 · Updated: 2026-10-08 · Language: en
- Canonical page: https://hysenlabs.com/projects/riot-os-riot

## Getting the source and pinning a quarterly tag

RIOT does not ask you to install a toolchain before you read anything. The README's recommendation is a plain clone, and it is candid about the trade:

```bash
git clone https://github.com/RIOT-OS/RIOT
```

The README calls this the most convenient way to get RIOT and immediately warns that you get the newest features and bug fixes with the caveat of an ever changing work environment. If you would rather have a fixed point, the project publishes quarter annual releases and documents how to move to one inside an existing clone:

```bash
git pull --tags
git checkout <YYYY.MM>
```

The version scheme is calendar based, so the tags read like 2026.04 rather than semver. That convention matters when you are pinning a dependency in firmware: a tag such as 2026.07 is a quarterly snapshot, not a patch level you can bump independently of the other three quarters.

There is an oddity worth sitting with here. GitHub is where the clone command, the issue tracker and the release badges all point, and yet the 2026.04 release notes list as a headline change that RIOT is now synced to Codeberg. Both facts are current: the README still routes every reader to github.com/RIOT-OS/RIOT, and the project now maintains a second forge. If your organization tracks upstream contributions through mirror status or has policies about where source is fetched from, check which of the two hosts your pipeline actually pulls before you assume the GitHub URL is the only origin.

## Where the README and the release notes describe timing differently

The README states the design principles as energy-efficiency, real-time capabilities, small memory footprint, modularity, and uniform API access independent of the underlying hardware, with partial POSIX compliance. The quarterly release notes describe the same list but insert one word: soft real-time capabilities. RIOT-2026.07 and RIOT-2026.04 both use the softened phrasing in their boilerplate, and the README on the repository front page does not.

Both descriptions are presented as authoritative, so rather than guess which one the maintainers mean, take the distinction as something to verify for your own workload. Soft real-time means deadlines are met under a defined load, not that a deadline is guaranteed while an interrupt handler overruns. The system features list backs that reading in practice: a preemptive, tickless scheduler with priorities, optional periodic round robin within priorities, flexible memory management, high resolution long-term timers, an MTD abstraction layer for flash-like memory, and file system integration. That is a well-built soft real-time foundation, and the wording difference is the kind of thing worth confirming against your timing measurements rather than taking on faith from either document.

The partial POSIX claim is the other useful thread to pull. It is why ports of existing C code tend to compile against RIOT with modest changes, and it is also why the compatibility claim is partial. Threads, sockets and file system calls behave in familiar ways, and the gaps are exactly the places where you will find out what a port really needs.

## Two hundred boards, seven CPU families and a native port

The platform list is the headline number: 200+ boards based on AVR, MSP430, ESP8266, ESP32, RISC-V, ARM7 and ARM Cortex-M, which spans 8-bit, 16-bit and 32-bit parts. The repository tree backs that up structurally. `cpu/` holds the processor support, `boards/` the board definitions, `drivers/` the peripheral drivers, `core/` the kernel and system core, `sys/` higher-level subsystems, `bootloaders/` the boot paths, and `examples/` the sample applications, including `examples/basic/`, `examples/advanced/`, `examples/networking/`, `examples/wasm/` and `examples/lang_support/`.

The native port is the piece that changes how you evaluate the system. RIOT can run as-is on Linux and BSD, and the README says multiple instances on one machine can be interconnected through a simple virtual Ethernet bridge or through a simulated IEEE 802.15.4 network. ZEP, the RIOT-native implementation of that low-rate wireless personal area network protocol, is what makes a laptop-only development loop possible: your node code, its network stack and its timers all run, and only the radio is simulated.

Programming environment support is broader than the language field suggests. GitHub reports the repository as C, which is accurate about the bulk of the code, but the README also advertises native code in C, C++ or Rust, standard embedded Rust interfaces, and integration of dynamic runtimes such as MicroPython, elm and WASM. The README lists SPI, I2C, UART, USB and CAN among the drivers, along with RTC, PWM, timers, ADC and DAC, a long list of sensors and actuators, displays and touchscreens, and GNSS.

## A network stack assembled from named protocols and named libraries

The features list reads like a shopping list until you notice how specific the attributions are. IPv6 is in there, and IPv4 via lwIP. 6LoWPAN is cited with its actual RFC numbers: RFC4944, RFC6282, RFC6775 and RFC7668. UDP and TCP sit underneath, RPL appears twice with a note that it supports storing mode and point to point mode, and CoAP is the application protocol. Then MQTT, named twice: MQTT via paho-mqtt, and MQTT-SN.

The device management story is LwM2M, and the wireless options are specific about implementations rather than generic: Bluetooth LE via NimBLE, which links to Apache's Mynewt NimBLE, plus LoRaWAN, UWB and CAN. CNN-Lite, IEEE 802.15.4 and lwIP appear in the list as well, along with Ethernet including over USB, SLIP or ethos networking over a serial line, and a single pair ethernet style transport on a UART that the README calls Dose.

Security is where an embedded OS either has an answer or does not. RIOT lists OTA updates via SUIT, the PSA Cryptographic API, and both DTLS and EDHOC. SUIT is worth understanding as the mechanism behind the OTA story: it is a standardized firmware manifest format rather than a bespoke updater, so the update path is interoperable with work done elsewhere in the IETF ecosystem.

The practical reading of all this is that the protocol coverage is genuinely wide, and each entry names the implementation rather than promising the category. If your device needs a specific radio, specific low-power wireless protocol, or a specific device management model, the list tells you in advance whether you will be integrating an existing project or writing one yourself.

## A Make-driven build with feature metadata generated into docs and makefiles

The build system is GNU Make, and the top-level Makefile has a small opinionated trick: running it from the repository root deliberately fails with a message that explains itself. The welcome block in `Makefile` prints the project name, then tells you that you executed make from the base directory and that you should usually run make in your application's directory instead.

```bash
@echo "Welcome to RIOT - The friendly OS for IoT!"
@echo "You executed 'make' from the base directory."
```

Beneath that, the root Makefile is mostly an aggregator. It includes `makefiles/boards.inc.mk` and `makefiles/app_dirs.inc.mk`, pulls in `makefiles/tools/riotgen.inc.mk` and `makefiles/tests.inc.mk`, and sets clean and distclean rules that recurse into the application directories. Documentation and code generation both hang off it too, with `doc-man`, `doc-latex` and `doc-starlight` targets, and a `generate-features` rule that runs `features_yaml2mx.py` over `features.yaml` to produce `makefiles/features_existing.inc.mk`.

That `features.yaml` file is the interesting artifact. Feature declarations live in one place and are compiled into both a makefile inclusion and a documentation page, which is a neat way to keep the published feature list honest. Two other targets are worth knowing. `make print-versions` calls `dist/tools/ci/print_toolchain_versions.sh`, which is the quickest way to see which compilers and tools the project expects. And the presence of `.murdock.yml` at the root tells you that continuous integration runs on Murdock rather than GitHub Actions alone.

The surrounding files describe how seriously the project takes process. `CODING_CONVENTIONS.md` and a separate `CODING_CONVENTIONS++.md` exist, `.clang-format` and `.clang-tidy` pin the tooling, `CODEOWNERS` assigns review responsibility, `SECURITY.md` documents vulnerability handling, `CITATION.cff` gives you a citation record, and `MAINTAINING.md` plus `SUBSYSTEMS.md` describe who looks after what. There is also a `fuzzing/` directory and a `tests/` tree, which together suggest that the CI story covers more than the example applications.

## Community channels, governance and the documentation boundary

Support happens in public and the README is specific about where. The forum is described as the default place to start asking for help, because it keeps an archive of prior questions and answers. Live chat is Matrix, on the channel `#riot-os:matrix.org`. Bug reports and feature requests go to the GitHub issue tracker, which reports 912 open issues at the moment, and there is a governance document linked from the community section for anyone who wants to know how decisions get made.

The README even includes a short how-to-ask section, asking for what you are trying to achieve, the commands you already ran, and what happened instead. That is a small thing, but it tells you the maintainers expect real bug reports rather than one-line summaries.

The documentation split is the part to plan around. Everything substantive lives off the repository: a Getting Started Guide that covers installation and first applications, hands-on tutorials in the RIOT-OS/Tutorials repository, a self-paced online course in the RIOT-OS/riot-course repository, and an API reference generated at api.riot-os.org. The README page itself is a front door that lists principles, features and channels. For an evaluation, that means the repository gives you the shape of the system and the guide gives you the specifics, and the guide is where you would look up the module or peripheral you actually need.

The project also names its collaborations, including Ariel OS, an IoT operating system written in Rust, which is worth knowing if you are weighing a Rust-native alternative and want to track where the two efforts converge. On activity, GitHub reports the last push to master on 2026-09-28, and the release cadence is visible in the tag list: 2026.07 published on 2026-08-21, 2026.04 on 2026-05-06, and a 2026.04.01 bugfix on 2026-05-22 for a defect that the notes say had been present since 2025.10. Releases are quarterly, patch releases are quick, and a bug this old surviving into a stable line is normal for a codebase of this size.

## Conclusion

RIOT is at its best on a board it already supports, in a project that wants POSIX-shaped application code without giving up a tickless scheduler and an IoT protocol stack. The native port is the reason many people evaluate it, because compiling for Linux and BSD lets a team work on application logic before hardware exists. What the README leaves open is exactly what a production decision turns on: the API reference, the release cycle notes and the module documentation all live on guide.riot-os.org rather than in the repository front page, and the quarterly 2026.04.01 bugfix for a defect dating back to 2025.10 is a fair reminder that soft real-time guarantees need testing against your own timing budget. Start by cloning the tree and building one example for the native port, then read the board list and the API docs for the part you have.

## FAQ

### What is the RIOT operating system?

RIOT is an open-source operating system for microcontrollers and other embedded devices, covering 8-bit, 16-bit and 32-bit parts including AVR, MSP430, RISC-V and ARM Cortex-M. It is written mostly in C, offers partial POSIX compliance and a tickless preemptive scheduler, and ships drivers and networking for IoT work rather than a general-purpose userland.

### Can I develop RIOT applications without microcontroller hardware?

Yes. The native port runs RIOT as-is on Linux and BSD, and multiple instances on one machine can be joined by a virtual Ethernet bridge or a simulated IEEE 802.15.4 network through ZEP. That means application logic, timers and the network stack can be exercised on a laptop before you move to a board.

### Is RIOT's copyleft licence a problem for commercial firmware?

RIOT is licensed under LGPLv2.1, and the README states the reasoning explicitly: the copyleft terms are intended to permit indirect business models around the platform, and it is possible to link closed-source code against LGPL code. Anyone shipping a product still needs their own legal review of how their application links to the library.

## Sources

- [License: LGPL-2.1](https://github.com/RIOT-OS/RIOT/blob/master/LICENSE)
- [Project website](https://riot-os.org)
- [README](https://github.com/RIOT-OS/RIOT/blob/master/README.md)
- [Releases](https://github.com/RIOT-OS/RIOT/releases)
- [RIOT-OS/RIOT on GitHub](https://github.com/RIOT-OS/RIOT)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/riot-os-riot