Tasks

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 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.