For embedded applications where multi-threading and scheduling is required, using a RTOS can provide a whole range of facilities that make development easier. This is especially true where network communication (such as Ethernet or Wifi) is a requirement.
However, using a RTOS is a decision that has to be carefully considered. RAM, Flash and CPU processing time have to be taken into account, as well as the numerous pitfalls that come with multi-threading.
Therefore, the first question we’d recommend asking yourself is: do you really need an RTOS? Another way to put it would be: “Multitasking – don’t use it unless you have to”.
There are a lot of RTOS available, and the quality of the code varies greatly. A lot of them use a dual license (GPL and commercial) scheme. Free and seemingly popular options may sound attractive, but the time spent debugging intricate problems due to the lack of support can seriously impact development cost and delay.
We recently experienced problems with FreeRTOS, which despite being very popular, has no automated tests and lacks quality support. We even had to rewrite parts of the code for features that were supposed to work, such as tickles mode.
RIOT is, in our opinion, a better option, and comes with unit tests and a series of test programs. It’s also lighter, more deterministic and overall offers better performance.