Message Queues for Inter-Task Communication

1. The "Why" and "What" of Message Queues

Before diving into the RTOS specifics, let's understand the general concept. At a high level, queues are a fundamental mechanism in computing for managing asynchronous communication and workflows. They act as a buffer between a producer of information and a consumer, decoupling them so they don't have to interact at the same time.

In the context of an RTOS like FreeRTOS, a message queue is a kernel object specifically designed for passing data between tasks, or from an ISR to a task, in a thread-safe manner. It's essentially a FIFO (First-In, First-Out) buffer.

A key characteristic of FreeRTOS queues is that they operate by copying data by value. When a task sends an item to a queue, the RTOS copies the bytes of that item into the queue's internal storage buffer. When a task receives an item, the RTOS copies the bytes from its buffer into a variable provided by the receiving task.

This "queue-by-copy" approach has several advantages:

• Simplicity and Safety: It completely decouples the sender and receiver. The sender can immediately modify or discard its local copy of the data after sending it, without affecting the message in the queue.
• No Shared Ownership: You don't need to worry about which task "owns" the data or is responsible for freeing its memory. The RTOS handles the memory management for the queue's storage.

2. The Core FreeRTOS Queue API

To work with queues, you'll primarily use three functions. The official FreeRTOS documentation provides the definitive reference for these.

Let's summarize the key functions:

1. xQueueCreate(uxQueueLength, uxItemSize)

   • Creates a new queue and returns a handle to it.
   • uxQueueLength: The maximum number of items the queue can hold.
   • uxItemSize: The size, in bytes, of a single item.
   • Returns NULL if the queue cannot be created (usually due to insufficient heap memory).

2. xQueueSend(xQueue, pvItemToQueue, xTicksToWait)

   • Sends (copies) an item to the back of the queue. xQueueSendToBack is an identical alias.
   • xQueue: The handle of the queue.
   • pvItemToQueue: A pointer to the item that will be copied into the queue.
   • xTicksToWait: The maximum time the task should block if the queue is full. Setting this to portMAX_DELAY will block indefinitely.

3. xQueueReceive(xQueue, pvBuffer, xTicksToWait)

   • Receives (copies) an item from the front of the queue, removing it.
   • xQueue: The handle of the queue.
   • pvBuffer: A pointer to a buffer where the received item will be copied. This buffer must be at least uxItemSize bytes long.
   • xTicksToWait: The maximum time the task should block if the queue is empty.

The xTicksToWait parameter is fundamental to how RTOS tasks are designed. A task waiting to receive data from a queue will enter the Blocked state, consuming no CPU time. It is automatically moved back to the Ready state by the scheduler as soon as an item becomes available in the queue.

3. A Practical Example: Passing Structures

While you can pass simple types like integers, the real power of queues becomes apparent when you pass structs. This allows you to create a versatile communication system where one task can process various types of messages from multiple sources.

This pattern is highly relevant to your background. In AUTOSAR, you work with PDUs and signals that are essentially structured data packets. Using structs in FreeRTOS achieves a similar goal at the task level.

Consider a design where a central "controller" task needs to react to different system events:

• A CAN task decodes a message and needs to send a motor speed value.
• An HMI task detects a button press and needs to send a new setpoint.

Instead of creating separate communication channels for each, you can use a single queue that transfers a structure.

/* Define an enumerated type to identify the source/type of data. */
typedef enum
{
    eMotorSpeedUpdate,
    eNewHmiSetpoint
} DataSource_t;

/* Define the structure type that will be passed on the queue. */
typedef struct
{
    DataSource_t eDataSource; // What type of message is this?
    int32_t lDataValue;       // The actual data payload.
} Data_t;

// Queue handle, created with xQueueCreate(10, sizeof(Data_t))
QueueHandle_t xControllerQueue;

With this setup:

• The CAN task can populate a Data_t struct with eDataSource = eMotorSpeedUpdate and send it.
• The HMI task can populate a Data_t struct with eDataSource = eNewHmiSetpoint and send it.
• The controller task receives Data_t structs and uses a switch statement on the eDataSource member to determine how to interpret lDataValue.

4. Handling Large Data: The Pointer-Passing Pattern

Copying data is simple, but it can be inefficient if the items are large. Imagine processing frames from an ADAS camera or large data packets from Automotive Ethernet. Copying hundreds or thousands of bytes into and out of a queue on every transfer would be a significant performance bottleneck.

The solution is to revert to passing data "by reference," but in a controlled way. Instead of copying the entire data block, you copy a pointer to the data block.

The queue is created to hold pointers. For example, to pass pointers to a large buffer structure:
xPointerQueue = xQueueCreate(5, sizeof(LargeBuffer_t *));
Note the *—the item size is the size of a pointer, not the size of the structure itself.

Crucial Memory Management Consideration:
When you pass pointers, you lose the automatic memory management of the queue-by-copy method. You must establish a clear protocol for memory ownership. This is a classic interview question for a senior role.

• Who allocates the memory? The sending task typically allocates a buffer (either dynamically from the heap or from a pre-allocated static pool).
• Who frees the memory? The receiving task becomes the new owner of the buffer and is responsible for freeing it or returning it to the pool after it has finished processing the data.

Failure to manage this correctly leads to memory leaks (if no one frees the buffer) or dangling pointers and data corruption (if the sender frees it too early or both tasks try to use it simultaneously).

5. Interview Preparation: Key Questions

Be prepared to discuss the trade-offs and design patterns related to queues.

• Question: "What's the difference between passing data by value vs. by reference in a FreeRTOS queue? What are the pros and cons of each?"

  • Your Answer: "Passing by value, the default in FreeRTOS, copies the data into the queue. The pro is safety and simplicity—it decouples the tasks and the RTOS manages the data's lifetime. The con is inefficiency for large data items. Passing by reference involves copying only a pointer to the data. The pro is high performance and low memory overhead for large data. The con is increased complexity; the application programmer must manage the memory manually, defining a clear ownership protocol to prevent leaks or data corruption."

• Question: "You have a central processing task that needs to receive commands of different types from multiple other tasks. What's a robust and scalable way to design this using a single queue?"

  • Your Answer: "The best approach is to define a struct that acts as a message envelope. This struct would contain at least two members: an enum or integer ID to identify the message type, and a union or void* pointer for the data payload. All sender tasks create and populate this struct and send it to the single queue. The receiver task reads the struct, checks the message ID, and then processes the payload accordingly. This is scalable because adding new message types only requires updating the enum and the receiver's processing logic, not changing the entire communication infrastructure."

• Question: "If you pass pointers through a queue, what are the critical memory management considerations you need to address?"

  • Your Answer: "The most critical consideration is establishing a clear ownership model. Typically, the sender allocates a memory buffer, populates it, and sends the pointer, relinquishing ownership. The receiver takes ownership upon receiving the pointer and becomes responsible for freeing that memory after use. This prevents memory leaks. It's also vital to ensure the sender doesn't access the buffer after sending the pointer and that the receiver doesn't use the pointer after freeing it. Using a memory pool instead of dynamic heap allocation can make this process more deterministic and prevent fragmentation."

Conclusion

You've now covered a fundamental building block of any non-trivial RTOS application. Message queues provide a clean, thread-safe, and flexible way to orchestrate the flow of data between different parts of your system.

Key Takeaways:

• Queues decouple tasks, allowing them to communicate asynchronously.
• FreeRTOS queues default to "pass-by-value," which is safe but can be slow for large data.
• Passing structs is a powerful pattern for sending varied messages to a single task.
• Passing pointers is efficient for large data but requires careful manual memory management to avoid leaks and corruption.

Next Lesson Preview:
So far, our examples have focused on task-to-task communication. However, a major source of data in embedded systems is hardware interrupts. In our next lesson, we will complete the picture by exploring how to use queues to safely and efficiently pass data from an ISR to a waiting task. We will look at the special ...FromISR API variants and revisit the "deferred interrupt processing" pattern in the context of queues.