---

RTOS IPC (Inter-Task Communication) is a fundamental aspect of Real-Time Operating Systems (RTOS), enabling efficient and reliable coordination between tasks. Proper use of RTOS IPC techniques—such as queues, mutexes, and event groups—can significantly enhance system performance and stability by preventing data races, ensuring resource protection, and facilitating smooth task collaboration.

In this article, we’ll walk you through the fundamental principles and design patterns of RTOS IPC. Using a FreeRTOS implementation example, we’ll demonstrate how to integrate Queue, Mutex, and Event Group mechanisms to help you build a robust and efficient multitasking system architecture.

What is RTOS IPC?

IPC (Inter-Process Communication) refers to the mechanisms used for exchanging data or synchronizing execution between different processes or tasks. In embedded systems—where resources are limited and multitasking is common—IPC mechanisms play a particularly vital role.

The main purposes of IPC include:

• Task synchronization: Coordinating the execution order of multiple tasks
• Resource management: Safely sharing limited system resources
• Data sharing: Allowing different tasks to exchange information

Here is the English translation of your section:

What is FreeRTOS IPC?

FreeRTOS, as a real-time operating system, provides various IPC (Inter-Process Communication) mechanisms to enable communication and synchronization between tasks. Since FreeRTOS is designed for resource-constrained embedded systems, its IPC mechanisms are lightweight and highly efficient.

The main IPC mechanisms provided by FreeRTOS include:

• Queues
  • The most basic communication method, allowing tasks to send fixed-size data
  • Supports multiple senders and receivers
  • Queue length is configurable
  • Offers both blocking and non-blocking options
• Binary Semaphores
  • Used for task synchronization
  • Has only two states: 0 and 1
  • Commonly used to synchronize between Interrupt Service Routines (ISR) and tasks
• Counting Semaphores
  • Similar to binary semaphores, but the count can exceed 1
  • Ideal for managing access to limited resources
• Mutexes
  • A special type of binary semaphore with priority inheritance
  • Protects shared resources from concurrent access
  • Helps prevent priority inversion
• Recursive Mutexes
  • Allows the same task to acquire the mutex multiple times without causing a deadlock
  • Must be released the same number of times to be fully released
• Event Groups
  • Allow tasks to wait for a combination of multiple events
  • Each event is represented by a bit
  • Efficient for implementing complex synchronization patterns

Development Environment

Before starting your programming, make sure to complete the following preparations:

• Install ESP-IDF (version 5.x or higher): ESP-IDF is the official development framework for programming the ESP32, and it supports multiple operating systems such as Windows, macOS, and Linux.
• ESP32 Development Board: An ESP32 board is required.

Project Structure

This is one of the default project structures used in ESP-IDF. When you create a new project using the idf.py create-project command or through the official ESP-IDF extension in VS Code, you’ll typically see the following layout:

esp32-fir-filter/
├── CMakeLists.txt
├── main/
│   ├── CMakeLists.txt
│   └── fir_filter_example.c
└── sdkconfig

• CMakeLists.txt: The main build configuration file for the project, defining the overall build structure and dependencies.
• main/: Contains the application’s main source code.
• ipc_example.c: The core source file in this example, implementing the RTOS IPC logic (such as Queue, Semaphore, and Event Group).
• sdkconfig: Automatically generated by the menuconfig tool, this file stores the current configuration of the project.

This structure follows ESP-IDF’s recommended development style, offering good modularity and maintainability—making it easy to expand and manage the project in the future.

Code

In this example, we demonstrate the practical use of three common inter-task communication mechanisms in FreeRTOS, showing how they can be effectively integrated and coordinated in a real-world scenario:

• Queue: Transfers data between tasks.
• Mutex: Protects shared resources to prevent race conditions.
• Event Group: Synchronizes task execution and monitors task status.

Three independent tasks—a Producer, a Consumer, and a Monitor—are used to illustrate how these IPC mechanisms work together to build a responsive and reliable multitasking system architecture.

#include <stdio.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "freertos/queue.h"
#include "freertos/semphr.h"
#include "freertos/event_groups.h"
#include "esp_log.h"

// Define logging tag
static const char* TAG = "IPC_DEMO";

// Event group bit flags definition
#define TASK_1_BIT (1 << 0)
#define TASK_2_BIT (1 << 1)
#define ALL_SYNC_BITS (TASK_1_BIT | TASK_2_BIT)

// Global IPC objects
QueueHandle_t xQueue;
SemaphoreHandle_t xMutex;
EventGroupHandle_t xEventGroup;

// Producer task implementation
void vProducerTask(void *pvParameters) {
    int32_t lValue = 0;
    
    while(1) {
        // Increment value to be sent
        lValue++;
        
        // Protect shared resource with mutex
        if(xSemaphoreTake(xMutex, pdMS_TO_TICKS(100))) {
            ESP_LOGI(TAG, "Producer: Sending value %d", lValue);
            
            // Send data through queue
            if(xQueueSend(xQueue, &lValue, pdMS_TO_TICKS(10))) {
                ESP_LOGD(TAG, "Producer: Value %d sent to queue", lValue);
            }
            
            xSemaphoreGive(xMutex);
        }
        
        // Signal completion to event group
        xEventGroupSetBits(xEventGroup, TASK_1_BIT);
        
        // Wait for all tasks to synchronize
        xEventGroupWaitBits(xEventGroup, ALL_SYNC_BITS, pdTRUE, pdTRUE, portMAX_DELAY);
        
        vTaskDelay(pdMS_TO_TICKS(500));
    }
}

// Consumer task implementation
void vConsumerTask(void *pvParameters) {
    int32_t lReceivedValue;
    
    while(1) {
        // Receive data from queue
        if(xQueueReceive(xQueue, &lReceivedValue, pdMS_TO_TICKS(100))) {
            ESP_LOGI(TAG, "Consumer: Received value %d", lReceivedValue);
        }
        
        // Signal completion to event group
        xEventGroupSetBits(xEventGroup, TASK_2_BIT);
        
        vTaskDelay(pdMS_TO_TICKS(300));
    }
}

// System monitoring task
void vMonitorTask(void *pvParameters) {
    while(1) {
        // Log queue status
        ESP_LOGI(TAG, "Monitor: Queue spaces left %d", uxQueueSpacesAvailable(xQueue));
        
        // Log mutex status
        ESP_LOGI(TAG, "Monitor: Mutex holder %s", 
               xSemaphoreGetMutexHolder(xMutex) == NULL ? "None" : "Held");
        
        // Log event group status
        EventBits_t uxBits = xEventGroupGetBits(xEventGroup);
        ESP_LOGI(TAG, "Monitor: Event bits - Task1: %d, Task2: %d", 
               (uxBits & TASK_1_BIT) ? 1 : 0,
               (uxBits & TASK_2_BIT) ? 1 : 0);
        
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

// Main application entry point
void app_main(void) {
    // Set default log level
    esp_log_level_set(TAG, ESP_LOG_INFO);
    
    // Initialize IPC objects
    xQueue = xQueueCreate(5, sizeof(int32_t));
    xMutex = xSemaphoreCreateMutex();
    xEventGroup = xEventGroupCreate();
    
    // Verify object creation
    if(xQueue == NULL || xMutex == NULL || xEventGroup == NULL) {
        ESP_LOGE(TAG, "IPC object creation failed");
        return;
    }
    
    // Create all tasks
    if(xTaskCreate(vProducerTask, "Producer", 2048, NULL, 2, NULL) != pdPASS ||
       xTaskCreate(vConsumerTask, "Consumer", 2048, NULL, 1, NULL) != pdPASS ||
       xTaskCreate(vMonitorTask, "Monitor", 2048, NULL, 1, NULL) != pdPASS) {
        ESP_LOGE(TAG, "Task creation failed");
        return;
    }
    
    ESP_LOGI(TAG, "FreeRTOS IPC Demo Started");
}

Program Description

Producer Task
Generates integer data and sends it to the Consumer using xQueueSend(). It uses xSemaphoreTake() / xSemaphoreGive() to protect critical sections with a mutex and signals task completion with xEventGroupSetBits(). Synchronization with other tasks is handled using xEventGroupWaitBits().

Consumer Task
Receives data from the queue using xQueueReceive() and processes it. Once the task is completed, it sets an event flag using xEventGroupSetBits() to assist with synchronization.

Monitor Task
Checks system status every second. It uses uxQueueSpacesAvailable() to monitor remaining queue space, xSemaphoreGetMutexHolder() to display the mutex holder status, and xEventGroupGetBits() to read task synchronization flags.

Compile and Flash

After writing the code, you can use the ESP-IDF tools to build, flash, and monitor:

In the VS Code lower-left ESP-IDF toolbar:

• Click Build project
• Click Flash device
• Click Monitor device

Output and Test Results

After the system starts, you will see output similar to the following in the serial monitor:

I (123) IPC_DEMO: FreeRTOS IPC Demo Started
I (623) IPC_DEMO: Producer: Sending value 1
D (623) IPC_DEMO: Producer: Value 1 sent to queue
I (723) IPC_DEMO: Consumer: Received value 1
I (1623) IPC_DEMO: Monitor: Queue spaces left 4
I (1623) IPC_DEMO: Monitor: Mutex holder None
I (1623) IPC_DEMO: Monitor: Event bits - Task1: 1, Task2: 1
I (2123) IPC_DEMO: Producer: Sending value 2
D (2123) IPC_DEMO: Producer: Value 2 sent to queue
I (2223) IPC_DEMO: Consumer: Received value 2
I (2623) IPC_DEMO: Monitor: Queue spaces left 4
I (2623) IPC_DEMO: Monitor: Mutex holder None
I (2623) IPC_DEMO: Monitor: Event bits - Task1: 1, Task2: 1
I (3123) IPC_DEMO: Producer: Sending value 3
D (3123) IPC_DEMO: Producer: Value 3 sent to queue
I (3223) IPC_DEMO: Consumer: Received value 3
...

Each line shows a real-time filtered output, clearly demonstrating the smoothing effect of a low-pass filter.

Conclusion

This example integrates the three most essential FreeRTOS IPC mechanisms—Queue, Mutex, and Event Group—to clearly demonstrate their real-world use in RTOS IPC scenarios, including task communication, resource protection, and synchronization.

Such a design not only improves system readability and stability but also establishes a solid RTOS IPC framework for building clean and reliable multitasking systems. Whether you’re a beginner exploring RTOS IPC fundamentals or an experienced developer optimizing task interactions, this example offers practical insight and implementation patterns.

By mastering these RTOS IPC techniques, you’ll be better equipped to design robust, efficient, and maintainable real-time systems across a wide range of embedded applications.

---