Introduction to RTOS Part 5 - Queue | Digi-Key Electronics

Summary

In this video, the challenges of using global variables in an RTOS (Real-Time Operating System) are explored, particularly with FreeRTOS. The script discusses how data corruption can occur when multiple tasks interact with shared global variables and offers queues as a safer solution for inter-task communication. The video also includes a practical Arduino example, showing how tasks can safely send and receive data via queues, preventing issues like race conditions and data corruption. The final challenge encourages viewers to implement this knowledge by creating tasks to control an LED blink rate based on user input, demonstrating the power of queues in embedded systems.

Takeaways

• 😀 Global variables in an RTOS can cause issues like race conditions and data corruption when accessed by multiple tasks concurrently.
• 😀 A 64-bit number on a 32-bit system can cause read/write issues, especially when tasks interrupt each other during the memory access process.
• 😀 Atomic operations can prevent interruptions during a write or read cycle, ensuring safe memory operations.
• 😀 Mutexes and semaphores are kernel objects that help prevent data corruption by controlling access to shared resources, though these will be covered in future lessons.
• 😀 Queues provide a better alternative for task communication, allowing for atomic writes and safe data transfer.
• 😀 A queue operates on a FIFO (First In, First Out) system, ensuring orderly data transfer between tasks.
• 😀 Data placed in a queue is copied by value, not reference, ensuring that task B receives a complete copy of the data without scope issues.
• 😀 FreeRTOS queues are not bound by type, meaning you can store different types of data as long as enough memory is allocated for each item.
• 😀 Queues allow for asynchronous communication, with tasks waiting for data to be available or timeout if no data is received.
• 😀 Special functions should be used within an interrupt service routine (ISR) for queues, as regular queue functions are not ISR-safe.
• 😀 In the provided Arduino sketch, two tasks (A and B) communicate using a queue, where task A sends data to task B for controlling an LED's blink rate based on user input.

Q & A

What is the main issue when using global variables between tasks in an RTOS?

The main issue is data corruption. When multiple tasks access the same global variable concurrently, one task may update it while another is reading it, leading to inconsistent or invalid data.

How can atomic operations help prevent data corruption in an RTOS?

Atomic operations ensure that certain memory operations are completed in a single instruction cycle without being interrupted by other tasks, guaranteeing data integrity during critical memory access.

What are the potential risks when dealing with 64-bit data on a 32-bit machine like the ESP32?

On a 32-bit machine, writing 64-bit data can lead to partial writes where the first half of the 64-bit value is written first, and if another task interrupts, it may read incomplete or corrupted data, leading to errors.

What is the role of a mutex or semaphore in FreeRTOS?

A mutex or semaphore is used to prevent race conditions by ensuring that only one task can access a shared resource at a time. This helps avoid conflicts when multiple tasks interact with the same data.

Why is a queue considered a good solution for passing data between tasks in FreeRTOS?

A queue ensures thread-safe communication between tasks. It operates on a first-in, first-out (FIFO) basis, with atomic operations for writing and reading, preventing data corruption during concurrent task execution.

What is the difference between sending data by value versus by reference in a FreeRTOS queue?

When sending data by value, the entire contents of the data (e.g., a variable, struct, or buffer) are copied into the queue, ensuring that no references to the original data are left hanging. Sending by reference could lead to issues if the original data goes out of scope.

How does FreeRTOS handle a full or empty queue?

If the queue is full, the sending task can be set to wait for a specified number of ticks before it times out and reports a failure. If the queue is empty, the receiving task waits for data, and it can also timeout and return a false status code if no data is received.

What is the importance of using the 'special from ISR' functions when working with queues in interrupt service routines (ISRs)?

Interrupt service routines do not rely on the tick timer and cannot afford to block or wait. Using the 'special from ISR' functions ensures that queue operations inside ISRs do not block or introduce delays that would interfere with the interrupt handling process.

What is the significance of the challenge at the end of the episode involving two tasks and two queues?

The challenge demonstrates how to use FreeRTOS queues to manage inter-task communication. Task A reads user input, sends it to Task B to control the LED blink rate, and Task B sends feedback to Task A after every 100 blinks, simulating a real-time command-line interface.

Why might you need to adjust the queue's size or delay times in the example program?

You may need to adjust the queue size if it becomes full faster than it can be emptied, and adjusting delay times helps control how quickly data is added to or removed from the queue, ensuring that tasks don't block or drop items unnecessarily.