Microcontroller programs consist of a number of tasks. Let’s say you wanted to make a computer-controlled telescope mount. The tasks would be:

• Retrieve a new byte of input from the USB serial buffer.
• Check if we’ve received a complete command.
• If so, execute that command.
• Read the sensors for the current telescope position.
• Set the proper output to control the next step of the motors.

This is a fairly typical set of tasks for something you would use a microcontroller for, and are pretty easy to manage with an infinite loop, like:

while(TRUE) {
  uint8_t input = readUsbBuffer();
  parseCommand(input);
  readSensors();
  setMotors();
}

If you keep adding and adding features, you eventually start coming across common problems you want to create abstractions for, like:

• Your buffer is overflowing, so you want to make sure that task can interrupt other tasks before it overflows.
• You want to save battery by sleeping when nothing is needed.
• You want to make sure all tasks get a fair shot. If readSensors takes too long, you want to be able to interrupt it and come back to it later.
• You want to be able to just reset one task without affecting others.
• You want a memory leak or other bug in one task to not take out the other tasks.
• You want to be able to give different tasks different priorities.
• You want to be able to sandbox an untrusted task.
• You want to be able to execute tasks at different rates. Perhaps your sensors can only be read 10 times per second, but you want to execute a motor step 100 times per second.

One or two of these items can be handled manually relatively easily. If you have enough of these kinds of problems frequently enough that you start generalizing them into libraries, you’ve basically reinvented an RTOS. If your program’s task management is complex enough, even if you don’t use an off-the-shelf RTOS, you will eventually end up reinventing one poorly.

However, in my experience, the line where you want an RTOS is very close to the line where you want a microprocessor instead of a microcontroller. If you anticipate your firmware getting that complex, it’s usually better to go the microprocessor route from the beginning.

I wrote my own co-operative multi-threading library for ARM Cortex-M0.

It was barely a couple pages of code, and the first version of it didn’t take longer than a day to write and debug.

The big advantage of roll-your-own is you know the code and you can port it to chips that the RTOS might not support. Also, you spend less time thinking about questions like “will it crash I try to use features A and B simultaneously?” Since you wrote the code, you know the answer.

Threading is the main thing you get from an RTOS, and it turns out to be not such a big deal to implement yourself. It’s rare that you need a lot of the features of an RTOS. But if you crunch your requirements and it turns out you do, then use an RTOS.