C Programming – Compiling and Deploying to an MCU with RTOS

First of all, it's really hard for any non-trivial program to 'not require any other library'. Remember that glibc and the startup code calling main() are libraries too.

But yes, even in this case you need the linker, just because the compiler/assembler typically don't handle ELF format (or any executable format). Precisely because usually you'll have to link with some libraries, so why should it bother to compile to ELF? It's better to focus on linkable-code formats and leave the executable formats to the linker.

PS: I forgot that .so is also a variant of ELF. But it still doesn't change the fact that it's a different subformat and the executable details are just not included in most compiler/assembers.

Yes, it's quite possible for a single tool to compile directly to executable, but that just means that it includes both the compiler and the linker in a single command. Why would it consider the (very) special case when you won't add any other code? It's far more logical to do it in the linker, after all you'll need it in %99.9 cases.

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.