For that matter why do you feel the need for an RTOS?, you're just diverting much of the micro-controllers resources to the RTOS and leaving less for the job you want to do.
A good RTOS will allow you to get the right code to run when needed with less effort on your part. The people who design them put a lot of time and effort into ensuring that it does. More than any firmware engineer can justify on a single project.
The downside, it is not a handcrafted solution, it will take more processor and memory. Like everything it is a tradoff, such resources are less expensive with time. Keep in mind that using an RTOS on a uC without enough headroom will always be bad.
We used PSOS to code at least one of our major product lines. There was support for PSOS (maybe others) in our debug toolchain which allowed customers to understand their code execution in terms of processes. That was over 15 years ago.
We all live in our little corner of the tech universe. I am thinking there is a lot of very real stuff out there that we may find hard to imagine.
I don't get it either.
Microcontrollers do just fine handing different jobs by either the interrupt mechanism or:
Code:
initializeEverything();
while(1){
if(buttonsNeedServicing)
serviceButtons();
if(uartNeedsFilling)
fillUART();
...
...
} //and just loop this way forever
There is no "portability" issue, I have my portable tasks right here. I can move fillUART() to another processor or use it in a completely different program if it's written smart. Well if you go to a part that configures the UART differently, then fillUART() may need to be different- and the exact same thing should be true for an RTOS.
It's not just a matter of overhead, but for the above example it's just so clear what's going on. I never could see the need to bring in the issues associated with an RTOS.