RTOS

In embedded systems, the word “address” often sounds as if everyone means the same thing.

In bare-metal code, a pointer may be close to a real SRAM address. RTOS tasks may share one address space. An MCU with an MPU can catch some out-of-bounds accesses, but usually does not provide full address translation. A Linux user process sees virtual addresses, while a DMA device may see a different bus address.

When debugging interrupts, it is easy to call everything “the interrupt.”

A peripheral status bit was not cleared: interrupt problem. The interrupt controller was not enabled: interrupt problem. The CPU never entered exception entry: interrupt problem. The ISR ran but the task did not wake: also interrupt problem. Everyone is debugging “interrupts,” but not the same layer.

The safer first model is this: an interrupt is a cross-layer path. A peripheral creates an event, the SoC routes that event to an interrupt controller, the controller selects, masks, prioritizes, and delivers it, the CPU receives it through exception entry, and the OS maps it to an ISR, bottom half, thread, or task wakeup.

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: