Real Time

The most common RTOS priority mistake is assigning priorities by business importance.

For example:

control task is most important -> highest priority
communication is also important -> next priority
logging is not important -> lowest priority

This is intuitive, but not enough. RTOS priority decides which ready task runs first. It is not the same as business value, and it does not guarantee that a high-priority task finishes first.

The first model is:

When comparing an RTOS and Linux, people often start with an intuitive difference: an RTOS is small, Linux is large.

That is true, but too coarse. What affects engineering choices and debugging is not binary size alone. It is the different problems they are designed to solve by default.

An RTOS is common in resource-constrained device-side systems with clear response paths and fixed control cycles. Linux is common when resources are richer and the system needs process isolation, network stacks, filesystems, complex drivers, and application ecosystems.

Many performance problems first look like “the CPU is too slow”: a button responds late, UART handling misses data, network packets pile up, the UI stalls, or sensor data reaches the application thread late.

But CPU load is only one layer. What often decides responsiveness is when the code gets to run.

Code existing in memory does not mean it can run at any moment. It may not be ready yet. It may be waiting for a lock, queue, or I/O. It may be blocked behind a higher-priority task. It may have just been woken by an interrupt but not yet selected by the scheduler.

Device software often creates a misleading mental model: code runs in source order, and the next thing only happens after the current function returns. That model is useful inside a single function, but it breaks down as soon as timers, UART input, network packets, GPIO events, and DMA completion enter the system.

A peripheral does not wait until the main loop reaches the right line. A UART byte arrives when it arrives. A network packet arrives when it arrives. A timer expires when it expires. If the CPU had to discover every event by polling, response would either be slow or the system would waste a large amount of time checking status bits.