Queue full and empty handling in FreeRTOS - Step-by-Step Execution

Concept Flow - Queue full and empty handling

Start

↓

Check if Queue is Full?

Yes→Block or Return Error

|No↓

Add Item to Queue

↓

Check if Queue is Empty?

Yes→Block or Return Error

|No↓

Remove Item from Queue

↓

Repeat or End

This flow shows how FreeRTOS checks if a queue is full before adding items and empty before removing items, handling each case properly.

Execution Sample

FreeRTOS

if (uxQueueSpacesAvailable(queue) == 0U) {
    // Handle full queue
} else {
    xQueueSend(queue, &item, 0);
}

if (uxQueueMessagesWaiting(queue) == 0U) {
    // Handle empty queue
} else {
    xQueueReceive(queue, &item, 0);
}

This code checks if the queue is full before sending and empty before receiving, handling each case safely.

Execution Table

Step	Action	Queue State (Items)	Condition Checked	Result	Operation Outcome
1	Check if queue is full	0/3	Is queue full?	No	Proceed to send item
2	Send item 'A'	0/3	Add item	Success	Queue now has 1 item
3	Check if queue is full	1/3	Is queue full?	No	Proceed to send item
4	Send item 'B'	1/3	Add item	Success	Queue now has 2 items
5	Check if queue is full	2/3	Is queue full?	No	Proceed to send item
6	Send item 'C'	2/3	Add item	Success	Queue now has 3 items (Full)
7	Check if queue is full	3/3	Is queue full?	Yes	Block or return error, cannot add 'D'
8	Check if queue is empty	3/3	Is queue empty?	No	Proceed to receive item
9	Receive item	3/3	Remove item	Success	Queue now has 2 items
10	Check if queue is empty	2/3	Is queue empty?	No	Proceed to receive item
11	Receive item	2/3	Remove item	Success	Queue now has 1 item
12	Check if queue is empty	1/3	Is queue empty?	No	Proceed to receive item
13	Receive item	1/3	Remove item	Success	Queue now empty
14	Check if queue is empty	0/3	Is queue empty?	Yes	Block or return error, cannot receive
15	End	0/3	-	-	No more operations

💡 Execution stops because queue is full when adding or empty when receiving, handling these cases properly.

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 6	After Step 9	After Step 11	After Step 13	Final
Queue Items Count	0	1	2	3	2	1	0	0
Last Operation	None	Send 'A'	Send 'B'	Send 'C'	Receive	Receive	Receive	Blocked (empty)

Key Moments - 3 Insights

Why does the code check if the queue is full before sending an item?

Because adding an item to a full queue would fail or block. The execution_table rows 1,3,5,7 show the check and the result to prevent overflow.

What happens if we try to receive from an empty queue?

The code blocks or returns an error to avoid reading invalid data. See execution_table rows 14 and 15 where the queue is empty and receive is blocked.

Why does the queue count decrease after receiving items?

Because receiving removes items from the queue, reducing its count. This is shown in variable_tracker and execution_table rows 9,11,13.

Visual Quiz - 3 Questions

Look at the execution_table at step 7. What is the queue state and what happens when trying to add 'D'?

A Queue is empty; 'D' is added

B Queue has space; 'D' is added successfully

C Queue is full with 3 items; adding 'D' is blocked or errors

D Queue is full; 'D' replaces oldest item

💡 Hint

Check 'Queue State' and 'Operation Outcome' columns at step 7 in execution_table

At which step does the queue become empty after receiving items?

A Step 11

B Step 13

C Step 9

D Step 14

💡 Hint

Look at 'Queue Items Count' in variable_tracker after each receive operation

If we remove the check for empty queue before receiving, what could happen?

A Program might try to receive from empty queue causing error or block

B Queue will automatically add items

C Queue will never be empty

D Queue will send items twice

💡 Hint

Refer to key_moments about empty queue handling and execution_table steps 14-15

Concept Snapshot

FreeRTOS queues must be checked before sending or receiving.
Use (uxQueueSpacesAvailable(queue) == 0U) before xQueueSend() to avoid overflow.
Use (uxQueueMessagesWaiting(queue) == 0U) before xQueueReceive() to avoid underflow.
If full or empty, handle by blocking or error return.
This prevents data loss or program errors.
Always check queue state before operations.

Full Transcript

This visual execution trace shows how FreeRTOS handles queue full and empty conditions. The program first checks if the queue is full before sending an item. If full, it blocks or returns an error to prevent overflow. When sending items 'A', 'B', and 'C', the queue fills up to its capacity of 3. Trying to add 'D' fails because the queue is full. When receiving, the program checks if the queue is empty before removing items. It successfully receives three items, emptying the queue. Trying to receive from an empty queue blocks or errors. The variable tracker shows the queue item count changing after each send and receive. Key moments clarify why these checks are necessary to avoid errors. The quiz questions test understanding of queue state and handling at different steps. The snapshot summarizes the key rules for safe queue operations in FreeRTOS.

Practice

1. In FreeRTOS, what happens if you try to send an item to a queue that is already full without waiting?

easy

A. The send operation fails immediately and returns an error.

B. The queue automatically expands to fit the new item.

C. The oldest item in the queue is overwritten.

D. The task sending the item is suspended indefinitely.

Solution

1. Step 1: Understand queue full behavior

   When a queue is full, FreeRTOS does not allow new items to be added without waiting or handling the error.

2. Step 2: Check send operation without wait

   If the send function is called with zero wait time and the queue is full, it returns immediately with an error indicating failure.

3. Final Answer:

   The send operation fails immediately and returns an error. -> Option A

4. Quick Check:

   Queue full + no wait = send fails [OK]

Hint: Send with zero wait fails if queue is full [OK]

Common Mistakes:

• Assuming queue grows automatically
• Thinking oldest data is overwritten
• Believing task suspends indefinitely

2. Which of the following is the correct way to receive an item from a FreeRTOS queue with a block time of 10 ticks?

easy

A. xQueueReceive(queue, &item, 10);

B. xQueueReceive(queue, item, 10);

C. xQueueReceive(queue, &item, 0);

D. xQueueReceive(queue, &item, -1);

Solution

1. Step 1: Understand xQueueReceive parameters

   The function takes the queue handle, a pointer to the variable to store the item, and the block time in ticks.

2. Step 2: Identify correct syntax

   Passing &item as the second argument is correct to provide the address. Block time 10 means wait up to 10 ticks.

3. Final Answer:

   xQueueReceive(queue, &item, 10); -> Option A

4. Quick Check:

   Pointer + block time 10 = correct receive call [OK]

Hint: Use &item and positive ticks for blocking receive [OK]

Common Mistakes:

• Passing item instead of &item
• Using zero or negative block time incorrectly
• Confusing send and receive parameters

3. Consider the following code snippet:

QueueHandle_t queue = xQueueCreate(2, sizeof(int));
int val = 10;
xQueueSend(queue, &val, 0);
val = 20;
xQueueSend(queue, &val, 0);
val = 30;
BaseType_t result = xQueueSend(queue, &val, 0);

What is the value of result after the last send call?

medium

A. pdPASS (send succeeded)

B. errQUEUE_FULL (send failed due to full queue)

C. pdFAIL (generic failure)

D. Block indefinitely until space is available

Solution

1. Step 1: Analyze queue creation and sends

   The queue can hold 2 integers. Two sends with zero wait fill it completely.

2. Step 2: Evaluate last send with zero wait

   The third send tries to add an item when the queue is full and does not wait, so it fails returning errQUEUE_FULL.

3. Final Answer:

   errQUEUE_FULL (send failed due to full queue) -> Option B

4. Quick Check:

   Queue full + zero wait = send fails with errQUEUE_FULL [OK]

Hint: Queue size 2 + 3 sends with zero wait = last send fails [OK]

Common Mistakes:

• Assuming last send blocks
• Thinking last send overwrites data
• Confusing pdPASS and pdFAIL

4. Given this code snippet, why does xQueueReceive never return pdPASS?

QueueHandle_t queue = xQueueCreate(1, sizeof(int));
int data;

// Task A
xQueueReceive(queue, &data, 0);

// Task B
int val = 5;
xQueueSend(queue, &val, 0);

medium

A. xQueueSend is called with zero wait time, so it fails.

B. Queue size is too small to hold any data.

C. xQueueReceive is called with incorrect pointer.

D. Task A tries to receive before Task B sends, queue is empty, no wait time.

Solution

1. Step 1: Understand queue state at receive

   Task A calls receive immediately with zero wait, but queue is empty because Task B hasn't sent yet.

2. Step 2: Effect of zero wait on empty queue

   With zero wait, receive returns immediately with failure since no data is available yet.

3. Final Answer:

   Task A tries to receive before Task B sends, queue is empty, no wait time. -> Option D

4. Quick Check:

   Receive zero wait + empty queue = no pdPASS [OK]

Hint: Receive zero wait on empty queue always fails [OK]

Common Mistakes:

• Thinking queue size 1 means no data can be stored
• Assuming send fails with zero wait
• Confusing pointer usage in receive

5. You want to design a FreeRTOS task that sends sensor data to a queue but must never block if the queue is full. Which approach correctly handles the queue full condition?

hard

A. Increase the queue size dynamically when full.

B. Use xQueueSend with portMAX_DELAY to wait indefinitely until space is available.

C. Use xQueueSend with zero block time and check the return value to discard data if full.

D. Use xQueueOverwrite to replace the oldest data in the queue automatically.

Solution

1. Step 1: Understand non-blocking send requirement

   The task must never block, so waiting indefinitely or for a long time is not allowed.

2. Step 2: Choose correct send method and handling

   Using xQueueSend with zero block time returns immediately. Checking the return value lets the task discard data if the queue is full.

3. Step 3: Evaluate other options

   Use xQueueSend with portMAX_DELAY to wait indefinitely until space is available. blocks indefinitely, violating requirement. Use xQueueOverwrite to replace the oldest data in the queue automatically. overwrites data but may lose important info. Increase the queue size dynamically when full. is not supported by FreeRTOS.

4. Final Answer:

   Use xQueueSend with zero block time and check the return value to discard data if full. -> Option C

5. Quick Check:

   Non-blocking send + check return = safe discard [OK]

Hint: Send zero wait + check return to avoid blocking [OK]

Common Mistakes:

• Using blocking send when non-blocking needed
• Assuming queue size can grow dynamically
• Ignoring return value of send