Do you use a RTOS?

[hal9001]

I believe RTOSs are gaining popularity and I notice they're even used in fairly basic tasks. Do you use RTOS in your work?

[woofy]

Not deliberately. ESP32 uses FreeRTOS but I still treat my projects as single threaded.
In my day job I've never found the need for one. I've looked at them and considered FreeRTOS and Threadx from time to time but never used them. I've always found interrupts and co-operative multitasking more than enough and simpler.

[Tation]

Yes. In different flavours over the years. Even when not needing a scheduler, I've used RTOSes because of their drivers (with RTOSes that come with them, in my case mbed OS & Zephyr). Time ago wrote (for use in both work & home) a simplified re-incarnation of mbed OS, similar API, different internals, with some success (much smaller binaries —this was the reason to accomplish such task—, slightly faster), but now I think it does not worth the effort, abandoned it when porting to other (similar) MCUs. My current workhorse is Zephyr.

EDIT: also using Zephyr with ESP32C.
EDIT2: if Zephyr's learning curve wasn't such step...

[dietert1]

FreeRTOS is fairly easy to understand and to use. No different than any other library. Of course you will always find somebody who prefers not to use any libraries at all but implement everything starting from scratch. We should try to understand and make use of what others studied and found before. That's ancient greek philosophy.
So i used FreeRTOS for several projects as it supports some very useful constructs like queues and semaphors. The task construct helps structuring real world projects that are a bit more complex than the usual learning examples. Also some other libraries depend on tasks, e.g. for ethernet.

Regards, Dieter

[tggzzz]

I believe RTOSs are gaining popularity and I notice they're even used in fairly basic tasks. Do you use RTOS in your work?

RTOSs can add value where they have decent libraries for subsystems (e.g. comms over ethernet/USB/etc) and/or a decent HAL over the specific peripherals.

Personally I prefer systems where the intertask/interprocessor comms/synchronisation is built into the language and/or processor.

People who think it is better to "roll your own" comms/synchronisation usually end up with subtle "unreproducible" bugs, because they don't understand what isn't guaranteed by a language+compiler+processor.

At best an RTOS is merely the bottom layer of a well structured design; it has to be used well. No surprises there.

[JPortici]

Yes and no.
I have a couple of devices that force me to use freeRTOS or other RTOSs (Microchip, ESP32, Nordic), because the Radio Stacks mandates the use of a RTOS.

I dabbled with freeRTOS a bit, but reverted almost all projects to be superloops using spare interrupts as threads

[voltsandjolts]

I dabbled with freeRTOS a bit, but reverted almost all projects to be superloops using spare interrupts as threads

Could you elaborate on that a little?
Do you mean triggering them from elsewhere by setting interrupt flags manually?

[peter-h]

Yes, FreeRTOS, and it is a superb tool for building complex products. Have not had any problems with it at all.

There are things to consider when using an RTOS e.g. each task has its own stack and if you have say 30 tasks, each with 2k, that is 60k of stack space used up. Whereas if you wrote your code as a state machine, you would not need 60k (but the code would likely be a mess).

[tggzzz]

Whereas if you wrote your code as a state machine, you would not need 60k (but the code would likely be a mess).

Yes and no.

I've seen appalling FSM implementations where a single FSM was gradually mutated so that there were if-then-else statements nested 10 deep. Gobsmacking.

But there are a couple of design patterns which keep FSM implementations under control, and greatly simplify modifications, and enable simple fast logging in installed systems.

There is far too little available to formally prove that an FSM specification is complete and correct. But that is a very different problem!

[isometrik]

Yes. CMSIS-RTOS2

https://arm-software.github.io/CMSIS_6/latest/RTOS2/index.html

[iMo]

ChibiOS is finetuned for the stm32 MCUs family, for example.. Fastest context switching..
https://www.chibios.org/dokuwiki/doku.php

[5U4GB]

I believe RTOSs are gaining popularity and I notice they're even used in fairly basic tasks. Do you use RTOS in your work?

Yes.  An RTOS isn't really a operating system in the conventional sense but more a glorified HAL, and that's what I use it as.  I don't want to have to write my own software substrate for the hardware on each device I work with, so an RTOS is the sensible solution.

[5U4GB]

Yes. CMSIS-RTOS2

https://arm-software.github.io/CMSIS_6/latest/RTOS2/index.html

How much has that changed from v1, which was the last version I worked with?  Looking at cmsis_os.h vs. cmsis_os2.h the changes seem to be mostly cosmetic.  And do you have any feeling for how much v1 stuff is still around compared to v2?

[cgroen]

Same for me, I do nothing without an RTOS, even on the smallest devices I/we use. So much easier to keep things clean (at least for me/us).
Started with Keil RTOS decades ago and now naturally moved to CMSIS-RTOS (1 and now 2)

[peter-h]

So much easier to keep things clean

Could not have put it better myself

[tggzzz]

So much easier to keep things clean

Could not have put it better myself

Some people can make a mess out of anything. Other people can make beautiful items from a mess.

Covering up a mess with something clean and simple can help many people make their own beautiful items. Others will still manage to make a mess.

[uer166]

Sometimes yes, sometimes no. RTOS makes certain things harder but others easier, certain classes of bugs are RTOS-specific and cannot exist if you don't use one (or at least the particular feature).
I tend to use NVIC priority contexts as tasks (nested, mostly time-triggered interrupts as a simple hardware "RTOS" without mutexes, locks, or high priority ISR masking). But sometimes something like FreeRTOS can be put on top of that or just used as-is.

Some people will pretend that their way is the only "true" way and everyone else is literal garbage, ignore that. What's more important is knowing the limitations and using obvious/good patterns on whatever HW/SW solution you specifically chose.

There are so many details and edge cases to keep track of; an "RTOS" doesn't absolve you of responsibility of knowing the details, even though some think that somehow it's all automagic that "just works". The key overall is to keep the state-space of your program as small as possible, with an easy to understand control flow. Usually control flow complexity is inversely proportional to response time/flexibility of the program, but now always; there are some "high value" architectures that are good at both.

This is a good night-time read: https://www.safetty.net/download/pont_pttes_2001.pdf for an architecture at the extreme end of lowest possible control flow complexity (ignoring something totally simple like a superloop), but at a pretty big price for other reasons.

[tggzzz]

The RTOS itself is effectively a glorified superloop, which makes it non-trivial to draw a dividing line between a superloop based architecture and an RTOS based architecture.

IMHO useful distinctions are based around the design patterns and architectural components that enable communications between independent parts of the software implementation and the hardware implementation. Key facets of that are interrupts, FIFOs, mailboxes, and similar.

[peter-h]

certain classes of bugs are RTOS-specific and cannot exist if you don't use one (or at least the particular feature).

These are absolutely no reason to not use an RTOS. For example with a pre-emptive RTOS (which all the common ones are) your code can be interrupted at any time with a task switch, so you need to be aware of that. It is no different to being aware that an ISR can jump into your code at any time. So you need to know stuff like which variables (if shared) are atomic (we had a thread here on that).

Mutexes are also very useful, and really clean up access sharing to data or hardware.

Many years ago I wrote an RTOS for Z180 and Z280. Posted the source here, IIRC. It was non-pre-emptive but delivered nearly all the benefit of an RTOS anyway.

[SiliconWizard]

Preemptive scheduling has become "popular" in projects implementing communication and file I/O in particular, which is why many people have been exposed to RTOSs from using network or filesystem libraries, while they were not necessarily considering using a RTOS otherwise.

The reason is that it's usually much easier to write a library of this kind without having to care about yielding execution frequently enough so as not to hog the CPU for too long. Writing code for a cooperative scheduler is hard. You basically need to handle a task-specific context manually and yield at frequent enough intervals, which is far from trivial if the code is moderately complex. OTOH, preemptive scheduling gives you that for "almost" free.

Now there are some specific issues with preemptive scheduling that you won't run into with purely cooperative, such as synchronization issues and priority inversion. So it's not a picnic either, but it's a different range of difficulties.

[tggzzz]

Sometimes yes, sometimes no. RTOS makes certain things harder but others easier, certain classes of bugs are RTOS-specific and cannot exist if you don't use one (or at least the particular feature).

Could you give an example of that?

There are some deep theoretical problems (e.g. dining philosophers, byzantine generals, races, deadock/livelock, starvation) that cause problems with and without an RTOS. What else are you considering?

Fundamentally there's nothing special about an RTOS. They provide low-level facilities corresponding to proven design patterns. On top of those it is possible to build higher level applications also using design patterns proven over time. Done properly, it becomes possible to reason about how an application will behave at a level that is close to the domain specification i.e. abstracted away from many tedious/uninteresting implementation details. That's very valuable, partly because it enables application to be modelled and tested at a level that the domain specialist (who wrote the specification) can understand. Examples from one of my projects, many years ago: "patient breathing in", "patient trusted to breathe on their own", "breath volume", "pressure too high". Other examples are "network node added", "token missing", "two tokens", etc.

Such reasoning, modelling and testing should aim at assuring there are no visible deep theoretical problems in the specification and/or application implementation, and that the application logic is correct.

One of my pet dislikes is having too many priorities; "normal", "interrupt" and "panic" should be sufficient. Any more than that and reasoning/testing/modelling becomes much less tractable, and "random" problems appear in operation. If an RTOS application uses many priorities and those cause failures, it is not the fault of an RTOS - the same failures would probably be observed without an RTOS.

[tggzzz]

Preemptive scheduling has become "popular" in projects implementing communication and file I/O in particular, which is why many people have been exposed to RTOSs from using network or filesystem libraries, while they were not necessarily considering using a RTOS otherwise.

The reason is that it's usually much easier to write a library of this kind without having to care about yielding execution frequently enough so as not to hog the CPU for too long. Writing code for a cooperative scheduler is hard. You basically need to handle a task-specific context manually and yield at frequent enough intervals, which is far from trivial if the code is moderately complex. OTOH, preemptive scheduling gives you that for "almost" free.

Now there are some specific issues with preemptive scheduling that you won't run into with purely cooperative, such as synchronization issues and priority inversion. So it's not a picnic either, but it's a different range of difficulties.

Yes.

Add "jitter", and try to model it and ensure it cannot become excessive. There are techniques, but they have to be pessimistic with the consequence that resources appear underutilised.

It also adds extra routes which can cause races/deadlock/livelock/starvation etc.

[ejeffrey]

The reason is that it's usually much easier to write a library of this kind without having to care about yielding execution frequently enough so as not to hog the CPU for too long. Writing code for a cooperative scheduler is hard.

Not just hard, but often not well defined.  How long a task is allowed to run without yielding is ultimately a system level decision.  If you are making a library there is no single right answer as to how often you should yield.  This is especially true when you have multiple layers: for instance a filesystem built on top of a block device driver. 

That's why modular systems built from reusable components essentially always migrate toward preemptive schedulers. 

[peter-h]

Non pre-emptive works fine if all time-critical stuff is under interrupts and there are FIFOs (or equivalent) for the data.

One example is a multi channel protocol converter which performs conversions of serial data, and you have decent size FIFOs for the data for both RX and TX.

But it doesn't matter because AFAIK every RTOS in common use is pre-emptive.

[isometrik]

Yes. CMSIS-RTOS2

https://arm-software.github.io/CMSIS_6/latest/RTOS2/index.html

How much has that changed from v1, which was the last version I worked with?  Looking at cmsis_os.h vs. cmsis_os2.h the changes seem to be mostly cosmetic.  And do you have any feeling for how much v1 stuff is still around compared to v2?

To be honest, I cannot yet provide a meaningful answer, as we recently redesigned / improved the electronics of a previous design, and I only very recently started to migrate the firmware from CMSIS-RTOS1 to CMSIS-RTOS2. I am therefore still wrapping my head about the subtleties of the changes.

I would however point you to the following references that might provide the answers you are looking for.

• RTX Migration Guide: https://arm-software.github.io/CMSIS_5/RTOS2/html//os2MigrationGuide.html
• Detailed API Function Differences: https://arm-software.github.io/CMSIS_5/RTOS2/html//os2MigrationFunctions.html
• CMSIS-RTOS2 Revision History: https://arm-software.github.io/CMSIS_6/latest/RTOS2/rtos_revisionHistory.html

I hope these will help.