
RIOT: Operating System for the Internet of Things - lainon
http://riot-os.org/
======
x3ro
One of the (admittedly less active these days) contributors here. Happy to
answer questions to the best of my ability :)

As far as I'm aware, the focus of RIOT is to make embedded development as
similar as possible to the way you'd write an application on Linux, including
most of the relevant POSIX APIs. This is what, as far as I know, sets it apart
from other systems such as Contiki or FreeRTOS, which have non-POSIX APIs for
interaction with the OS.

Someone on this thread asked why RIOT vs FreeRTOS is not something being
compared. FreeRTOS doesn't really come with all the drivers, network stack etc
that you need in order to write an embedded IoT application. That is not to
say that it's not possible to do so, but it requires more work of picking the
right drivers and libraries, whereas RIOT tries to work out of the box for
supported devices.

Finally, RIOT was born as a university project, and many of the people working
on it are either university students or former students. In that sense, there
are many, often conflicting interests and no single governing body. Depending
on your point of view, this might either be good or bad.

~~~
TickleSteve
POSIX APIs are typically not appropriate for embedded systems.

For example filesystems. Filesystems are not generally applicable for single-
purpose embedded systems. You're never going to need textual filenames,
opening and closing file handles, etc. All that is just a waste, typically you
just want to store your data to a log. This is much more appropriately stored
in a simple circular buffer on FLASH without the overhead and non-determinacy
of a filesytem.

Also, processes. These should be static. You typically never ever exit a
task/thread on an embedded system.

Resets are a way of life. You have to acknowledge them in your design and
error handling takes advantage of this.

I would not take POSIX compliance for a system like this as a plus point.

~~~
as-j
> POSIX APIs are typically not appropriate for embedded systems.

This is a very broad brush. My Embedded Linux system makes amazingly good use
of Linux and its Posix APIs. It’s also way to big to be the target of RIOT, so
let’s talk about it’s 3 other embedded MCUs.

> Filesystems are not generally applicatble...You’re never going to need
> textual filenames

Really? Because I always enjoy talking to my cell radio doing
AT+CMOGS=257,FFFFFF^1. That’s open file 257 and write FF.

Maintenance, debugging and robuestness of embedded systems is frequently
overlooked. It allows not only a single dev, but a team to work, debug and
release a system is a big deal. Embedded systems, esepcially those logging
data, holding SSL certs, config data can very much use a filesystem. None of
this has to be complex JFFS2 FS.

For example, if it’s an IoT, how do you plan to OTA it without good storage
management?

> I would not take POSIX compliance for a system like this as a plus point

As a hirring manager anything that opens my pool of candidates is useful.
Teaching someone a whole new environment is a big deal. If there’s similar
concept and tools this ia big plus.^2

——-

1) ok, I can’t remember the right AT command or the right file number, but
serisouly how did this make it into a public API in 2019?

2) Mostly true. If it’s too close that it’s almost the same, but not due a
laundry list of weird exceptions I’ll skip it. Micropython is my example here,
it’s like really close to python, may too close but too different. There’s
lots of other embeddedable languages that aren’t too close but weird.

~~~
TickleSteve
(Quick reply)

\- RIOT is obviously targetted at microcontroller-based systems (not Linux
level).

\- AT commands... you can't use modems in general as a good example of
anything. Thes software running on those things tend to be terrible.

\- Good storage management != filesystem. you can simply allocate a rotating
circular buffer in FLASH with CRCd blocks. This is a simple mechanism that
gives you both bad-block-management and wear-levelling in one trivial
mechanism. No filenames in sight! ;o)

\- Hiring... There is a lot more to embedded systems than "Can they use the
API". All RTOSs use similar APIs, thats never been an issue.

------
travisgriggs
We played with RIOT for a couple of months.

For our current product, (and I would think a lot of IoT apps), power is king.
We run on batteries, and getting back to idle/low power states as often as
possible is crucial. I've found that a lot of the embedded RTOS often have
tickless modes as an "add on." We had problems getting RIOT to a happy point
with that for our chip (samd21).

Like some of the other commenters, I've grown a real distaste for embedded
RTOS frameworks that try to provide all kinds of layers. In order to be
generic/cross platform, they always come up short in capability. The
functionality that I'm looking for, is simply getting the basic threading/sync
primitives to work well and right. Past that, I'm fine doing the chip IO parts
myself. At the time, there was a debate on whether priority inversion was a
problem RIOT should worry about or not.

After FreeRTOS, and then RIOT, I found TNEO
([https://dmitryfrank.com/articles/how_i_ended_up_writing_my_o...](https://dmitryfrank.com/articles/how_i_ended_up_writing_my_own_kernel)).
It's been a dream and rock solid for us. It does not come with a large
make/build system. It's just C code. You tweak a couple of things, include one
or two bits, and I was off to the races. Coupling it with Unity for testing
and then writing ~200 unit tests that stressed all of its functionality was
straightforward, helped me understand it even better, and gave me a high
degree of confidence in its abilities. It's been super solid for us since. It
does the one thing I need it to: MicroKernel for dealing with processes and
related synchronization primitives.

~~~
nbzklr
There are a _lot_ of realtime operatings systems out there right now,
competing for a spot on the IoT hypetrain:

\- the mentioned RIOT OS ([https://riot-os.org/](https://riot-os.org/))

\- FreeRTOS ([https://www.freertos.org/](https://www.freertos.org/)) and
Amazon's version of it
([https://aws.amazon.com/freertos/](https://aws.amazon.com/freertos/))

\- Zephyr OS
([https://www.zephyrproject.org/](https://www.zephyrproject.org/))

\- MyNewt ([https://mynewt.apache.org/](https://mynewt.apache.org/))

\- Mbed OS ([https://os.mbed.com/](https://os.mbed.com/))

and more... Makes it really hard to choose one!

------
sufiyan
Having used both contiki and riot, I found contiki (NG) very good with
supporting more devices and peripherals and much easier to integrate and work
with. Riot is difficult in that half the times their tutorials themselves
didn't work and there was no support online (this was about a year back and
maybe it is better now).

I really prefer contiki ng

~~~
cf498
We are currently using RIOT in a 3 year research project(2 years in atm) and
they do have some issues, however not on the scale you describe. Especially
with the online support, if you ask the community, you will generally get an
answer relatively quick. With the examples, your experience will vary greatly
depending on what board you use, as not all support every test.

It is however clear, that they started as a research project and had, and
still have, some maturing to do before they can be considered for a production
environment. In my opinion, they are however on the right track for that. The
list of buried corpses tends to get shorter and over the last year, a lot of
interesting features were added. They are also currently working on fixing
their documentation and getting automated HIL tests running for their
supported boards, which should fix alot of problems people getting started
with RIOT currently have.

We are likely not going to use RIOT in the next project, however we will
continue to use it for teaching.

------
wkz
The OS comparison table leaves me somewhat puzzled.

Contiki's "C Support" is listed as "partial" without any explanation. What
does this even mean? It seems to me that this should be between you and your
compiler.

Linux is supposedly "partially modular", whereas RIOT is fully modular. That's
a bold statement.

I get that they are trying to differentiate their product. But without
motivations, statements like these sound a bit hollow to me.

~~~
rcxdude
Contiki uses protothreads, so I would class that as 'partial' C support, since
you can't really use local variables (due to the hair-raising nature of how
protothreads works).

~~~
wkz
TIL about protothreads. Thank you. That does indeed look hair-raising!

------
magicalhippo
Most examples I looked at were just a few lines. None of them showed multi-
tasking, nor using sensors or similar SPI/I2C communication or similar.

Looking at the source code it seemed very Arduino-like in the sense that
there's few knobs to turn, which is nice for simple stuff but means you'll
have to go straight to registers for anything beyond.

Overall a bit hard to get a feel for what it could do.

~~~
x3ro
Good point. Most of the examples are simply wrappers around core features of
RIOT, such as gnrc (its network stack). For a larger snippet, this is a UDP
server, for example: [https://github.com/RIOT-
OS/RIOT/blob/master/examples/posix_s...](https://github.com/RIOT-
OS/RIOT/blob/master/examples/posix_sockets/udp.c)

There's also the pkg directory ([https://github.com/RIOT-
OS/RIOT/tree/master/pkg](https://github.com/RIOT-OS/RIOT/tree/master/pkg))
which incorporates a bunch of third-party libraries and projects without a
significant amount of code changes (see the patches/ directory in each pkg).
Maybe this gives a good impression of what it takes to port things to RIOT.

------
topbanana
No IPv4 support?

[https://github.com/RIOT-
OS/RIOT/tree/master/examples/gnrc_ne...](https://github.com/RIOT-
OS/RIOT/tree/master/examples/gnrc_networking)

~~~
eecc
Well? Why would you want it, it's legacy. IPv4 is over, let it rest.

~~~
topbanana
Because most home networks are IPv4 via NAT

~~~
jschwartzi
Not to mention most business networks, the vast majority of industrial control
networks. So basically damn near anywhere you would want to deploy a networked
embedded system. Many systems have IPv6 support but you will still need to
talk to IPv4 devices, and you need an IPv4 stack to do that.

------
fermigier
Talk about RIOT given at last year's OSIS in Paris:

[https://fr.slideshare.net/PoleSystematicParisRegion/osis18io...](https://fr.slideshare.net/PoleSystematicParisRegion/osis18iot-
la-securite-des-objets-connectes-a-bas-cout-avec-los-et-riot)

------
pjmlp
I am missing the comparisasion with NuttX, RTOS, Zephir, ARM mbed, microEJ,
Tizen IoT, ....

Everyone wants a piece of the pie.

~~~
kaspar030
Technical differences aside:

RIOT is the only mentioned OS with a copyleft license (well, LGPLv2.1), trying
to create a FOSS alternative in the embedded/IoT space.

With permissive licenses for embedded software, open source usually ends at
the factory.

~~~
pjmlp
Yep, the anti-GPL crowd will miss the glory days of Linux, specially if
Fuchsia really turns into Android Next.

------
melenaos
What is the benefit of using riot os on Arduino instead pure Arduino? I mean
what is the reason to add an extra layer since I have to write the same code
with and without riot.

~~~
kaspar030
Original author of RIOT here.

Using RIOT you'll get at least multi-threading, power management, a choice of
network stacks, a bunch of community-supported libraries and drivers with an
extensive test suite, ...

Also, you'd have a clear upgrade path, as applications written for RIOT's API
will compile (almost) unchanged for all of RIOT's target hardware. Arduino
becomes to slow? Change some pin defines, re-compile for a fast Cortex-M.
Intrigued by RISC-V's openness? Recompile for the Hivife1 to find out it's
real-world performance with your application.

~~~
melenaos
Excellent! But how about existing Arduino libraries such as firebase for
Arduino? I can use them as they are or I have to port them to the Riot API?

------
fjfaase
On there site, they do not compare it with FreeRTOS, a commonly used
alternative. I wonder why.

~~~
pantalaimon
FreeRTOS doesn't come with a hardware abstraction, it doesn't include any
drivers.

~~~
SlowRobotAhead
Nor should it.

As someone in the CE field doing this work everyday, I’m getting kind of sick
of abstraction layers. Every device mfg takes a crack at it, every RTOS does,
ARM itself does, and many IDEs are as well.

I kind of just want my RTOS to do threading, preemption, and resource locking.
Middlewares line Amazon’s MQTT are good but I’d really prefer to handle the
peripherals myself or use the device mfg’s libs. I am not a believer in write
once use everywhere embedded code, it just doesn’t work, because the
peripherals are just so different.

~~~
pantalaimon
> I am not a believer in write once use everywhere embedded code, it just
> doesn’t work, because the peripherals are just so different.

Are they though?

You got SPI, I2C, UART Timers and DMA and while their flavor may differ
depending on the vendor, they should do about the same no matter what platform
you are on.

Sometimes you might have to do some exotic stuff when a chip uses non-standard
interfaces, but most of the time the behavior should be fairly generic.

~~~
SlowRobotAhead
Yes, I think they are. Nordic 832’s SPI has an 8bit for remaining count in its
hardware register meaning a transfer has a max of 255chars. Atmel’s SPI is all
event based. STM32 F3 SPI has an entirely different setup procedure than those
two and that has a difference I can’t remeber the F0 and F7 are different.

Just at a base level how you work with peripherals is going to be different.
Some are better with events, some better as ISRs, some better with polling.

There is no middleware that’s just going to abstract those and get a great
implementation of each. They were just designed so differently.

~~~
pantalaimon
> Yes, I think they are. Nordic 832’s SPI has an 8bit for remaining count in
> its hardware register meaning a transfer has a max of 255chars. Atmel’s SPI
> is all event based. STM32 F3 SPI has an entirely different setup procedure
> than those two and that has a difference I can’t remeber the F0 and F7 are
> different.

How does this prevent you from hiding all those implementation details behind
an API like spi_transfer(spi_t dev, const void* buffer_tx, void* buffer_rx,
size_t size)?

RIOT manages to get by with that - granted, most implementations there rely on
polling, it's not a conceptual problem.

[https://github.com/RIOT-
OS/RIOT/blob/master/cpu/stm32_common...](https://github.com/RIOT-
OS/RIOT/blob/master/cpu/stm32_common/periph/spi.c)

[https://github.com/RIOT-
OS/RIOT/blob/master/cpu/atmega_commo...](https://github.com/RIOT-
OS/RIOT/blob/master/cpu/atmega_common/periph/spi.c)

[https://github.com/RIOT-
OS/RIOT/blob/master/cpu/nrf5x_common...](https://github.com/RIOT-
OS/RIOT/blob/master/cpu/nrf5x_common/periph/spi.c)

~~~
jschwartzi
It's not that we don't see how you could create an abstraction that works,
it's that we're questioning the value of doing so.

In your example, if I want a DMA-based transfer it's fine to just hide it and
block the thread waiting for the DMA interrupt. But if the hardware designer
expects me to poll, now I have to find a way to put the thread to sleep and
schedule it. And there are performance and timing implications for either
scheme that your abstraction hides from me. At some point I'm going to stumble
on those implications and get screwed badly enough by your abstraction that I
need to rip it out or work around it to solve a problem. This has happened to
me too many times before.

On systems that are small enough to be considered "embedded" I would much
rather the OS gets the hell out of my way and lets me pick a sensible
abstraction myself.

I don't see much value in having an abstraction layer in these systems unless
it's for a hobby project. In an established project you would never recompile
your code for a completely different hardware platform "just to see how it
performs." You'd stick with the hardware you know, and you'd already have de-
risked the performance questions early enough in the project that you wouldn't
have written a bunch of application code yet. It's not a problem that needs to
be solved in a professional environment.

~~~
SlowRobotAhead
Nailed it.

There is just no way an abstraction is going to pick the best process for my
needs.

And yea, while it might be a nice idea to switch chips... I’d have to go
through sourcing to figure out if they make a chip in the package i would need
at a price I’m willing to pay at a lead time I’m willing to wait, a week or
two reading data sheets and reference manuals, updating the board hardware,
changing the BOM, getting with purchasing to update the next PO, changing the
assembly programming and stencils... plus documentation, plus fragmenting our
hardware variations, etc.

The abstraction to switch chips, might be nice for prototyping, but yea, it’s
not really useful for production, so I think I would rather my OS developers
focus on other things.

------
yitchelle
"RIOT powers the Internet of Things like Linux powers the Internet."

Why does it need to evangelist with statements like this? Isn't RIOT a non-
profit endeavour?

------
arendtio
\- Riot.js

\- Riot Messenger

\- Riot Games

\- RIOT OS

It's getting kinda crowded in this namespace :-/

~~~
sufiyan
You might say it is becoming riotous

------
roland35
Another thing to note is that since Amazon has acquired the FreeRTOS project,
FreeRTOS now includes built in support for a lot of IoT related things.

AWS is certainly tied in the best but you can still use the networking and
MQTT library however you want

------
andrewstuart
Another embedded OS is iTRON
[https://en.wikipedia.org/wiki/ITRON_project](https://en.wikipedia.org/wiki/ITRON_project)

------
yeahitslikethat
Does this work on the esp8266? Says it does on the homepage but it's not
listed on the supported hardware page on the github.

What exactly does RIOT do for you that isn't on the chip?

~~~
petre
Generic 8266 dev board, there are also two specific ones, Olimex and Sparkfun
Thing.

[http://doc.riot-os.org/group__boards__esp8266.html](http://doc.riot-
os.org/group__boards__esp8266.html)

~~~
cf498
I would direct you towards their git instead of their website
[https://github.com/RIOT-OS/RIOT](https://github.com/RIOT-OS/RIOT)

There simply look for merged pullrequests of the features you are looking for.
That will give a better overview of the degree of support then the
documentation.

------
wieghant
Recently needed multi-threading with Arduino. Going to give this a shot. I'm
sure people more well-versed with non-POSIX may have gripes, but I'm just
doing this for hobby purposes. I'm familiar with Linux, I need multi-threading
and maybe a network stack. Given that, this seems like the thing for me.

~~~
durub
I also recommend taking a look at Zephyr RTOS [1].

I've been using it in production for almost a year, and no major complaints so
far. There seems to have support for POSIX threads and BSD sockets, but I
don't use them, so I can't tell you if they are production-ready or not.

[1]: [https://www.zephyrproject.org/](https://www.zephyrproject.org/)

------
mtgx
> Standard programming in C or C++

As if IoT manufacturers weren't already ignoring the security of their IoT
devices and properly updating them.

I think if IoT devices are to adopt a good open source RTOS it should at least
be one written in a memory safe language.

~~~
monocasa
What language do you suggest? The GCed languages aren't real time (yes there
are hard real time GCs, but they come at the cost of overall perf and close to
an order of magnitude more memory usage which is a non starter for many
embedded boards). Rust support for AVR isn't mainlined and is frequently
broken. It's Xtensa (ie. esp8266) support is basically non-existent.

Did I miss another option?

~~~
jungler
I scrolled through [https://github.com/dbohdan/embedded-scripting-
languages](https://github.com/dbohdan/embedded-scripting-languages)

And there are some options. You could achieve barebones VM protections with
Pawn(the language enforces very little otherwise, though). You could use
something ref-counted like a TCL implementation, which would allow you to
design around linear allocation times. The vast majority are using some kind
of tracing collector of course, but I wouldn't say this is a total loss for
achieving a combination of real time and memory protection.

~~~
monocasa
There 'embedded' means 'a library included as a subsystem in a larger
application', not 'embedded systems'.

PAWN for instance is explicitly 32bit and interpreted, so would run dog slow
on something like an Arduino.

Something refcounted like TCL implies tons of heap allocations, which implies
fragmentation at the very small RAM sizes of a lot of these chips.

