Actually the question is...
To OS, RTOS, or not to OS?
Many if not most embedded products we use don't need an RTOS or and sort of OS. So, why do people get wrapped around the axial worry about OSes.
First decide what you product is supposed to do then decide if you need and OS or not. Then decide what type. Does it need to be real time or not. Does adding support for the OS or RTOS in terms of memory, file systems and supporting software (drivers and more) worth the benefit of what you get.
If I can write the code as a simple main() with a while loop and an interrupt to two why do I need and OS. I am not against OSes or RTOS. Just use what you need and don't add unnecessary complexity.
I recently helped a client of mine by added a simple scheduler instead of adding a whole OS with actually better predictability and reliability then they could have with an and all in a very small footprint.
/* simplified code fragment */
main()
{
while(1)
{
for(task_id=0;task_id<MAX_TASK;task_id++)
{
(task_list[task_id])(); /* call each task in turn let run until completion */
}
}
}
Simplicity is more reliable then complexity. An OS adds complexity. With an OS each task has its own stack if you have hundred or thousands of small task the memory impacts can be huge. If the time it takes to get around through all the tasks is less then the time need required by the system this is very stable. If this could not make it all the way through the loop in time the same would apply to an RTOS as well (something to consider and RTOS does not create time). No OS, means less memory and no task context switch overhead. This list could be 1 or 1000 task long. You can add a sight twist and compare the last time the task ran with a the prior time a task ran and decide if you can skip this run.
Consider skipping the OS on your next design.
The reason why OSes show up in more place then they are needed is marketing.
