Applications where you are likely to find open-source RTOSes, in particular stuff like FreeRTOS, are IoT devices.
You hit the nail, too
.
Typical to IoT devices is,
* They are developed quickly, by inexperienced enthusiastic folks (nothing wrong with that)
* They use a lot of reused, copypasted, code
* Said reused code is developed as multithreaded, blocking code often originally on desktop/server
* Code is not developed by folks experienced working with microcontrollers, or even know what "interrupt" means. No, they come from a general purpose computing background.
* The results tend to be buggy, but of course have to Just Do The Job somehow in order to sell.
* Total lack of thinking about proving anything, including safety, functionality, or timing
Contrast the IoT gadget with, say, a 3-phase industrial VFD inverter. Latter has to prove safety, functionality, and timing, and does not run an RTOS. IoT gadget does not have to, and it will likely run some kind of OS. "RT" here actually means just
lightweight more than realtime.
These projects just
need an OS because of how they are developed. And if it's a small cheap microcontroller, it practically can't be linux. It doesn't need to be fully POSIX, but it has to have enough of the familiar interfaces so that porting code is not too big of a task. So it's one of the popular free RTOSes.
There is absolutely nothing wrong with all that. Products are made in quick cycles, they are fun to buy and use, and they make money.
But the contrast is just hilarious because said developers then get on the high horse on the internet and start spewing "oh, we use this thing called RTOS which is what aviation uses and our development patterns make our products super high reliability and good for safety critical applications because that's what RTOS is all about" BS.
And then the story always evolves into how difficult it is to blink LEDs or communicate through UART without RTOS because you have to write a scheduler from scratch and implement mutexes and semaphores and whatnot.
What I personally do (in addition to spewing critique on forums)? Well, I tend to separate the
computing part and the
real-time embedded part in two physical parts, and use a general purpose computer (such as Raspberry Pi, or one of the more professionally packaged Teltonika products) to do the computer stuff, on linux, and then do the low level control stuff on the MCU, of course bare metal. This way the "computer" side exposes all the fancy interfaces, not just a limited subset, with minimum effort. I can SSH in immediately, or plug in a monitor and keyboard. I have Ethernet, Wifi and so on with minimum development effort. And then I spend most of the effort to make the microcontoller side work well. Depending on the project, it's even possible to disconnect the computer part during normal operation, then, and let it do the control.
The fact people struggle with giving any actual example but instead give the typical marketing speech is very revealing, though.
I especially love rstofer's arguments how simple it is react to an external event because you don't have to consume "computing cycles" waiting for it and can just configure an interrupt, where you post a semaphore, which the scheduler then dispatches to your task, which is written to wait for the semaphore. If it is already this complex on RTOS, it
must be total pain in the ass without one!