Queues

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.

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: