Please note: This question specifically mentions two RTOSes but is more generic and can probably be answered by anybody who has written C code for embedded RTOSes before, and had their software run directly on MCUs.
I am interested in learning more about embedded RTOSes and writing applications for them. I am currently looking at Embox and RIOT because they're open source, modern, active and seem to have excellent documentation. My goal has two phases: Phase 1 is to figure out how to compile and flash these OSes to an MCU (probably AVR or ARM). Phase 2 is to then write a simple C program (basically a headless daemon), that would evolve over time as a "hobby app". I would then flash/deploy this program to the same MCU, thereby successfully deploying an appstack consisting of Embox/RIOT and my app residing on top of it.
Before I go down any roads that ultimately lead to dead ends, I stumbled across this article that does a pretty good job of explaining why real-time apps, written in C/assembler and flashed to MCUs, don't really need RTOSes underneath them.
So now I'm really confused, and am questioning some of my fundamental understanding of computing theory. I guess I'm trying to make the decision of whether or not to even use Embox/RIOT in the first place, either:
- Stay the course and go with an "app stack" on the MCU of both OS + app; or
- Heed the article's warning and just go with an MCU running my app "bare metal"
Obviously, the former is more work, and so there had better be a good reason/payoff for going that route. So I ask: what are the real benefits these (and similar) embedded RTOSes offer to MCU/C app developers? What specific features could my C app benefit from (perhaps by not reinventing the wheel?) by using an RTOS? What is lost by ditching the RTOS and going bare metal?
I'm asking for concrete examples here, not the media hype you get when you go to the wikipedia entry for RTOSes ;-)