RTOS

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:

In an RTOS project, task count can grow from two to a dozen quickly.

A common split looks natural:

• one UART task
• one sensor task
• one cloud task
• one button task
• one storage task
• one display task

This is not always wrong, but it often splits code by module name. Tasks actually affect scheduling, blocking, stacks, priorities, synchronization, and resource ownership. Bad task boundaries later look like concurrency bugs.

The first model is:

Many people first understand an RTOS as tasks, queues, semaphores, and a few driver callbacks.

NuttX does not fit that image well. It is better understood through a Unix-style model: POSIX-like APIs, VFS, device nodes, filesystems, sockets, shell, and applications form a small device system.

The first model is:

traditional MCU RTOS: application organized around tasks, queues, and driver APIs
NuttX: application organized around POSIX, VFS, device nodes, and system abstractions

That means comparing NuttX with FreeRTOS, RT-Thread, and Zephyr is not only a kernel-size comparison. It is a comparison of system abstraction.

Zephyr can feel heavy when first encountered.

Blinking an LED may involve a board definition, devicetree, overlays, Kconfig, CMake, west, and driver bindings. Compared with direct register code or a vendor HAL call, the path looks indirect.

But Zephyr is not mainly about making a tiny demo run. It is better understood as a platform engineering model for multi-board, multi-configuration, long-lived, connected embedded devices.

The first model is:

lightweight RTOS: application organized around kernel objects and SDKs
Zephyr: application organized around configuration, hardware description, driver model, and subsystems

If the project has one board, a few peripherals, and a short life, Zephyr may feel costly. If it must maintain boards, feature variants, and shared drivers, the structure starts to matter.

If RT-Thread is judged only by tasks, semaphores, and queues, its main value is easy to miss.

RT-Thread is not only an RTOS kernel. Around Chinese MCU and IoT projects, it provides an engineering environment: BSPs, a device framework, FinSH, filesystems, networking, packages, configuration tools, Chinese documentation, and community support.

The first model is:

FreeRTOS: lightweight kernel entry point
RT-Thread: RTOS kernel + device framework + IoT component ecosystem

This is not a replacement story. The default system boundary is different.

Many MCU projects do not need a full platform at the beginning. Their first problems are concrete:

• the main loop grows and response becomes slower
• UART, sensors, wireless stacks, and storage paths interfere with each other
• ISR code should stay short, but tasks do not know when to run
• one slow peripheral wait delays unrelated logic
• timers, timeouts, retries, and low power become tangled

FreeRTOS often becomes the first RTOS because it separates the concurrency paths that first become unmanageable in bare-metal firmware.

When an MCU project chooses an RTOS for the first time, the first questions are often about size, speed, and API simplicity.

Those questions help, but they are not enough. Choosing an RTOS is not only choosing a scheduler. It is choosing how device software is organized: how tasks are created, how drivers are integrated, where networking and filesystems come from, how board differences are maintained, whether existing C or POSIX-style code can be reused, and whether the team can debug field failures.

In RTOS devices, many peripheral issues are not about whether an interrupt entered. They are about whether the task handled it correctly and soon enough after the ISR.

Common symptoms include:

• ISR logs appear, but the business task receives no data
• queues fill up when interrupt rate increases
• ISR does too much work and system response gets worse
• a high-priority task is woken but runs late
• normal APIs are called from ISR and cause assertions or deadlocks
• one notification is sent while the hardware FIFO already contains many events

Do not look only at the ISR function. The full path is:

RTOS code often contains calls like:

vTaskDelay(1);
xQueueReceive(q, &msg, 10);
xTimerStart(timer, 0);

They all look like “wait for some time”. But RTOS time is usually not continuous, precise, and immediately executed. Many failures come from reading tick, delay, timeout, and software timers as precise real-time behavior.

A safer model is:

hardware clock generates tick
-> RTOS updates tick count
-> expired tasks or timers become ready/pending
-> scheduler decides when code actually runs
-> low power and interrupt masking change this path

So delay 10 ms is closer to “do not run until at least a tick boundary and then wait for scheduling” than “this code will run exactly 10 ms later”.

RTOSes provide many synchronization primitives: queues, semaphores, mutexes, event groups, and task notifications. They can all appear to mean “make one task wait for another”, so they are easy to mix up.

That may work briefly, but field failures become hard to reason about:

• events are occasionally lost
• a high-priority task is delayed by a low-priority task
• a full queue stalls the system
• ISR code calls an API that can block
• combined conditions are checked incorrectly
• data is updated, but the consumer sees stale state

The first selection model is: