ESP32 FreeRTOS 튜토리얼 가이드 6부작 4

 

ESP32 FreeRTOS 튜토리얼 가이드 6부작 4

 

FreeRTOS를 사용하여 ESP32에서 실시간 애플리케이션을 구축하는 방법을 배워보세요. 태스크 생성, 우선순위 처리, 메모리 관리, 태스크 간 통신에 관한 실용적인 튜토리얼을 살펴보세요. 각 예제는 실제 하드웨어에서 테스트되어 멀티태스킹을 숙달하고 ESP32의 듀얼 코어 성능을 최대한 활용할 수 있도록 도와줍니다. 

 

ESP32 FreeRTOS(1부): FreeRTOS 및 작업 관리 소개

ESP32 FreeRTOS(2부): 스케줄러 및 작업 관리 이해

ESP32 FreeRTOS(3부): 작업 우선순위 및 스택 관리 설명

ESP32 FreeRTOS(4부): 작업 간 통신 설명 | 큐, 세마포어 및 이벤트 그룹

ESP32 FreeRTOS(5부): 소프트웨어 타이머 및 작업 알림 설명

ESP32 FreeRTOS(6부): ESP-IDF에서 작업을 일시 중지, 재개 및 삭제하는 방법 

 

 

ESP32 FreeRTOS 태스크 간 통신 | 큐, 세마포어, 뮤텍스 및 이벤트 그룹

 

ESP32 FreeRTOS 시리즈 4부 에 오신 것을 환영합니다 .

 

이전 튜토리얼에서는 FreeRTOS에서 작업 생성 , 작업 스케줄링 , 우선순위 및 스택 관리 의 기본 원리를 살펴보았습니다 . ESP32에서 여러 작업을 독립적으로 실행하는 방법과 스케줄러가 작업을 효율적으로 관리하는 방법을 살펴보았습니다.

 

하지만 프로젝트가 커짐에 따라 여러 작업이 데이터를 공유하거나 작업을 조정 해야 하는 경우가 많습니다 . 예를 들어, 한 작업이 센서 데이터를 읽는 동안 다른 작업은 OLED에 데이터를 표시하거나 SD 카드에 기록할 수 있습니다. 이러한 작업이 적절한 제어 없이 공유 데이터에 접근하면 데이터 손상, 경쟁 조건 또는 예기치 않은 충돌과 같은 심각한 문제가 발생할 수 있습니다.

 

여기서 ITC( Inter-Task Communication)가 등장합니다.

 

이 튜토리얼에서는 FreeRTOS에서 다음을 사용하여 작업이 안전하고 효율적으로 통신 하는 방법을 살펴보겠습니다 .

• 작업 간 데이터 전송을 위한 큐 Queue
• 동기화를 위한 세마포어 Semaphore
• 공유 리소스를 보호하기 위한 뮤텍스 Mutex
• 여러 작업을 조정하기 위한 이벤트 그룹 Event Group

 

센서 판독 및 데이터 공유 작업 과 같은 간단한 예를 통해 각 개념을 명확하게 이해해보겠습니다.

 

 

ESP32 FreeRTOS 태스크 간 통신 | 큐, 세마포어, 뮤텍스 및 이벤트 그룹

 

목차

• FreeRTOS에서의 태스크 간 통신 소개
• ESP32의 FreeRTOS 대기열
• FreeRTOS에서 세마포어 사용
• ESP32 FreeRTOS의 뮤텍스
• 다중 작업 조정을 위한 이벤트 그룹
• 결론

 

FreeRTOS에서의 태스크 간 통신 소개

 

ESP32에서 FreeRTOS를 사용할 때 애플리케이션의 다양한 부분을 처리하기 위해 여러 작업을 만드는 경우가 많습니다. 예를 들어, 한 작업은 센서 값을 읽고, 다른 작업은 이를 처리하고, 세 번째 작업은 Wi-Fi를 통해 데이터를 전송하거나 화면에 표시합니다.

 

하지만 이러한 업무들은 고립되어 존재하지 않습니다. 업무들은 서로 정보를 교환 하거나 업무를 조율 해야 하는 경우가 잦습니다. 바로 이 부분에서 업무 간 소통(ITC) 이 필수적입니다.

 

작업이 통신해야 하는 이유

 

FreeRTOS와 같은 멀티태스킹 시스템에서는 각 작업이 독립적으로 실행됩니다. 그러나 실제 애플리케이션에서는 작업이 서로의 출력에 의존하는 경우가 많습니다.

 

예를 들어:

• 센서 작업은 온도 데이터를 수집합니다.
• 디스플레이 작업은 최신 판독값을 보여줍니다.
• 로거 작업은 SD 카드에 데이터를 저장합니다.

 

이 작업을 수행하려면 센서 작업이 다른 작업에 안정적으로 데이터를 전송 해야 합니다. 각 작업이 통신 없이 단독으로 작동하면 시스템이 예측할 수 없게 작동하거나, 더 나쁜 경우 잘못된 결과를 생성할 수 있습니다.

 

따라서 작업에는 데이터를 공유하고, 신호를 보내고, 동기화를 유지할 수 있는 안전한 방법 이 필요합니다 .

 

동기화가 없는 경우 발생하는 일반적인 문제

 

두 개 이상의 작업이 동시에 동일한 리소스나 변수에 액세스하려고 하면 심각한 문제가 발생할 수 있습니다.

• 데이터 손상 – 한 작업에서 데이터를 쓰는 동안 다른 작업에서 동시에 데이터를 읽는 경우입니다.
• 경쟁 조건 – 작업 실행 순서가 결과에 영향을 미쳐 일관되지 않은 동작이 발생하는 경우입니다.
• 교착 상태 – 두 작업이 서로의 리소스를 영원히 기다리는 경우입니다.
• 예측할 수 없는 충돌 - 특히 공유 메모리나 주변 장치에 안전하지 않게 액세스하는 경우.

 

이러한 문제는 초보자가 ESP32에서 멀티태스킹을 처음 사용할 때 매우 흔하게 발생합니다. 적절한 동기화가 없으면 멀티태스킹이 불안정해지고 디버깅이 어려워집니다.

 

FreeRTOS가 데이터 공유를 안전하게 해결하는 방법

 

FreeRTOS는 작업 간 통신 및 동기화를 안전하게 관리하기 위한 여러 가지 기본 메커니즘을 제공합니다 . 여기에는 다음이 포함됩니다.

 

• 큐 - 작업 간에 구조화된 데이터를 전송하는 데 사용됩니다.
• 세마포어 - 신호 전달 및 작업 동기화를 위해 사용됩니다.
• 뮤텍스 - 센서, 파일, 직렬 인터페이스와 같은 공유 리소스를 보호하기 위해 사용됩니다.
• 이벤트 그룹 – 여러 작업 간의 이벤트 기반 조정을 관리합니다.

 

이러한 도구는 한 번에 하나의 작업만 공유 데이터에 액세스하도록 하여 충돌을 방지하고 시스템 안정성을 유지합니다.

 

다음 섹션에서는 이러한 각 방법을 자세히 살펴보고, FreeRTOS 환경에서 작업이 효율적으로 통신하는 방법을 보여주는 실제 ESP32 예제를 살펴보겠습니다.

 

ESP32의 FreeRTOS 대기열

 

FreeRTOS에서 작업 간에 데이터를 공유하는 가장 일반적이고 안정적인 방법 중 하나는 큐(Queue)를 사용하는 것입니다 . 큐를 사용하면 시간 충돌이나 데이터 손상에 대한 걱정 없이 작업 간에 데이터를 안전하게 주고받을 수 있습니다.

 

 

https://hackmd.io/@RainbowEye0486/S1zxtaQ9_

 

 

FreeRTOS의 큐란 무엇인가

 

FreeRTOS의 큐는 한 작업에서 다른 작업으로 데이터를 전송하는 데 사용되는 FIFO(선입선출) 버퍼입니다 . 한 작업 이 메시지를 놓으면 다른 작업이 나중에 그 메시지를 가져오는 사서함 과 같다고 생각하면 됩니다 .

 

예를 들어, 센서 작업이 온도를 측정하면 해당 측정값을 대기열에 넣을 수 있습니다. 그러면 디스플레이 작업이 동일한 대기열에서 값을 읽어 화면을 업데이트할 수 있습니다.

 

대기열은 다음 사항을 확인합니다.

• 데이터는 전송된 순서대로 전달됩니다.
• 두 작업이 동시에 데이터에 액세스할 수 없습니다.
• 작업은 새로운 데이터가 도착할 때까지 차단(대기)될 수 있습니다.

 

ESP-IDF에서 큐를 만드는 방법

 

ESP32 FreeRTOS에서 큐를 생성하는 것은 간단합니다. xQueueCreate() 함수를 사용하며, 이 함수는 두 개의 매개변수를 받습니다:

1. 대기열 길이 – 대기열이 보유할 수 있는 항목 수.
2. 항목 크기 – 대기열에 저장된 각 항목의 크기(바이트).

 

예를 들면 다음과 같습니다.

 

QueueHandle_t testQueue;

void app_main(void)
{
    // Create a queue with space for 5 integer values
    testQueue= xQueueCreate(5, sizeof(int));

    if (testQueue== NULL)
    {
        printf("Failed to create queue\n");
        return;
    }

    // Create tasks here...
}

 

이 예에서 큐(testQueue)는 한 번에 5개의 정수를 저장할 수 있습니다 . 작업이 큐에 저장할 수 있는 용량보다 많은 데이터를 전송하려고 하면, 사용 가능한 공간이 생길 때까지 차단(대기)됩니다.

 

데이터 전송 및 수신 사용 xQueueSend()및 xQueueReceive()

 

대기열이 생성되면 작업은 다음 기능을 사용할 수 있습니다.

 

• xQueueSend()— 생산자 작업 에서 큐에 데이터를 전송하는 데 사용됩니다.
• xQueueReceive()— 소비자 작업 에서 큐에서 데이터를 읽는 데 사용됩니다.

 

기본 구문은 다음과 같습니다.

 

xQueueSend(testQueue, &dataToSend, portMAX_DELAY);
xQueueReceive(testQueue, &receivedData, portMAX_DELAY);

 

• 세 번째 매개변수는 큐가 가득 찬 경우(전송 시) 또는 비어 있는 경우(수신 시) 작업이 기다려야 하는 시간(틱 단위)을 정의합니다.
• portMAX_DELAY작업을 무기한 대기시키는 데 사용할 수 있습니다 .

 

예 - 센서 작업이 디스플레이 작업에 데이터를 전송함

 

다음은 두 작업이 큐를 사용하여 통신하는 방법을 보여주는 간단한 예입니다.

 

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

QueueHandle_t testQueue;

void SenderTask(void *pvParameters)
{
    int SentValue = 0;
    while (1)
    {
        SentValue++;
        printf("Sender Task: Sending value %d\n", SentValue);
        xQueueSend(testQueue, &SentValue, portMAX_DELAY);
        vTaskDelay(pdMS_TO_TICKS(1000)); // Send every second
    }
}

void ReceiverTask(void *pvParameters)
{
    int receivedValue = 0;
    while (1)
    {
        if (xQueueReceive(testQueue, &receivedValue, portMAX_DELAY))
        {
            printf("Receiver Task: Received value %d\n", receivedValue);
        }
    }
}

void app_main(void)
{
    testQueue = xQueueCreate(5, sizeof(int));

    if (testQueue == NULL)
    {
        printf("Queue creation failed!\n");
        return;
    }

    xTaskCreate(SenderTask, "Sender Task", 2048, NULL, 1, NULL);
    xTaskCreate(ReceiverTask, "Receiver Task", 2048, NULL, 1, NULL);
}

 

설명:

• SenderTask매초 새로운 판독값을 생성하여 대기열로 보냅니다.
• ReceiverTask새로운 값이 도착할 때까지 기다린 후 인쇄합니다.
• 두 작업은 독립적으로 실행되며 대기열을 통해 안전하게 통신합니다.

 

결과 - ESP-IDF 콘솔의 출력

 

아래 이미지는 두 작업이 모두 실행될 때 ESP-IDF 콘솔 에 인쇄된 로그를 보여줍니다.

 

 

 

ESP32 FreeRTOS 작업이 큐에 데이터를 전송하고 있습니다. 그리고 다른 작업이 큐에서 데이터를 수신하고 있습니다.

 

큐가 성공적으로 생성된 것을 확인할 수 있습니다.
송신자 태스크는 증분 값을 계속 전송하는 반면, 수신자 태스크는 이를 순서대로 수신하여 출력합니다.
이는 FreeRTOS 큐가 정상적으로 작동하고 있음을 확인시켜 줍니다 — 두 태스크 간에 실시간으로 데이터를 안전하게 전송하고 있습니다.

 

큐 크기 및 데이터 유형 선택을 위한 팁

 

효율적인 대기열 커뮤니케이션을 설계하는 데 도움이 되는 몇 가지 팁은 다음과 같습니다.

 

데이터 전송 속도에 따라 대기열 길이를 선택하세요.

생산자가 데이터를 전송하는 속도가 소비자가 읽는 속도보다 빠르면 대기열 크기를 늘리세요.

 

가벼운 데이터 유형을 사용하세요.

작은 구조체나 정수를 전송하면 큐의 속도가 빨라지고 메모리 효율성이 높아집니다.

 

대용량 데이터 전송은 피하세요.

센서 배열과 같은 대용량 데이터의 경우, 전체 버퍼 대신 포인터를 전송하세요.

 

대기열 사용량을 모니터링합니다.

uxQueueSpacesAvailable()를 사용하여 사용 가능한 공간을 확인하고 오버플로를 방지하십시오.

 

시간 제한을 현명하게 사용하세요.

항상 portMAX_DELAY를 사용하는 대신, 시스템의 응답성을 유지하기 위해 현실적인 대기 시간을 설정하십시오.

 

FreeRTOS에서 세마포어 사용

 

ESP32 기반 FreeRTOS 와 같은 멀티태스킹 시스템에서는 여러 작업이 함께 작동하거나 공유 리소스에 접근해야 하는 경우가 많습니다. 예를 들어, 두 작업이 동일한 UART, SPI 또는 ADC 주변 장치를 사용할 수 있습니다.

 

두 작업이 동시에 해당 장치를 사용하려고 하면 데이터 손상이나 타이밍 문제가 발생할 수 있습니다 .

 

이를 방지하기 위해 FreeRTOS는 작업의 액세스를 조정 하고 적절한 타이밍을 유지하는 데 도움이 되는 동기화 도구인 세마포어를 제공합니다 .

 

 

 

 

이진 세마포어 대 카운팅 세마포어

 

FreeRTOS는 바이너리 세마포어 와 카운팅 세마포어라는 두 가지 주요 세마포어 유형을 지원합니다 . 두 세마포어 모두 동기화에 사용되지만, 용도가 약간 다릅니다.

 

이진 세마포어

• 이는 사용 가능(0) 또는 사용 가능(1)의 두 가지 상태만 갖습니다 .
• 일반적으로 작업 간 또는 ISR(인터럽트 서비스 루틴)과 작업 간의 신호 전달 에 사용됩니다 .
• 예를 들어, 인터럽트가 발생하면 대기 중인 작업의 차단을 해제하기 위해 세마포어를 "제공"할 수 있습니다.

 

카운팅 세마포어

• 사용 가능한 리소스의 양을 추적하는 카운터처럼 작동합니다.
• 리소스의 인스턴스가 여러 개 있는 경우 유용합니다(예: 버퍼 풀).
• "줄 때마다" 카운트는 늘어나고, "받을 때마다" 카운트는 줄어듭니다.

 

유형	값 범위	일반적인 사용 사례
이진 세마포어	0 또는 1	작업 또는 ISR 동기화
카운팅 세마포어	0에서 N까지	여러 개의 동일한 리소스 관리

 

 

두 유형 모두 리소스 충돌을 방지하고 한 번에 하나의 작업만 공유 하드웨어나 데이터에 안전하게 액세스할 수 있도록 보장합니다.

 

세마포어가 작업 동기화를 돕는 방법

 

세마포어는 주로 다음과 같은 용도로 사용됩니다.

• 한 작업에서 다른 작업으로 신호 이벤트를 전달합니다 .
• 작업 간 실행 순서를 보장합니다 .
• 센서나 통신 포트와 같은 공유 리소스에 대한 액세스를 보호합니다 .

 

예를 들어:

 

• 생산자 작업은 새로운 데이터가 준비되면 세마포어를 제공할 수 있습니다.
• 소비자 작업은 데이터를 읽기 전에 세마포어를 기다릴 수 있습니다.

 

이를 통해 작업이 데이터가 사용 가능해지기 전에 데이터를 읽으려고 하거나 두 작업이 동시에 데이터를 쓰려고 하는 상황을 방지할 수 있습니다.

 

FreeRTOS는 이를 위해 간단한 API를 제공합니다.

 

xSemaphoreTake(mySemaphore, portMAX_DELAY);
xSemaphoreGive(mySemaphore);

 

이러한 기능은 작업 차단 및 깨우기를 자동으로 처리하므로 수동으로 타이밍을 관리할 필요가 없습니다.

 

예 - UART 전송과 ADC 읽기 동기화

 

예를 들어 두 가지 작업이 있다고 가정해 보겠습니다.

• ADC 작업 - ADC 채널에서 센서 데이터를 읽습니다.
• UART 작업 - 직렬 통신을 통해 데이터를 전송합니다.

 

이진 세마포어를 사용하여 동기화 할 수 있습니다 . UART 작업은 ADC 작업이 새로운 읽기를 완료한 후 세마포어를 제공할 때까지 기다립니다.

 

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

SemaphoreHandle_t dataReadySemaphore;
int sensorData = 0;

void ADCTask(void *pvParameters)
{
    while (1)
    {
        sensorData++;
        printf("ADC Task: New data = %d\n", sensorData);

        // Signal UART task that new data is ready
        xSemaphoreGive(dataReadySemaphore);

        vTaskDelay(pdMS_TO_TICKS(1000)); // Read every second
    }
}

void UARTTask(void *pvParameters)
{
    while (1)
    {
        // Wait until data is ready
        if (xSemaphoreTake(dataReadySemaphore, portMAX_DELAY))
        {
            printf("UART Task: Sending data = %d\n", sensorData);
        }
    }
}

void app_main(void)
{
    dataReadySemaphore = xSemaphoreCreateBinary();

    if (dataReadySemaphore == NULL)
    {
        printf("Failed to create semaphore!\n");
        return;
    }

    xTaskCreate(ADCTask, "ADC Task", 2048, NULL, 1, NULL);
    xTaskCreate(UARTTask, "UART Task", 2048, NULL, 1, NULL);
}

 

설명:

 

이 예제에서는 ADCTask와 UARTTask라는 두 작업이 이진 세마포어를 사용하여 동기화 상태를 유지하며 협력합니다.

dataReadySemaphore는 xSemaphoreCreateBinary()를 사용하여 생성됩니다.
이는 신호 역할을 하여 새 데이터가 준비되었을 때 한 작업이 다른 작업에 알릴 수 있게 합니다.

 

ADCTask는 센서 데이터 읽기를 시뮬레이션합니다.
매초마다 sensorData를 증가시키고 출력합니다. 그런 다음 세마포어를 양도(xSemaphoreGive())하여 새 데이터가 준비되었음을 알립니다.

 

UARTTask는 xSemaphoreTake()를 사용하여 해당 신호를 기다립니다.
세마포어가 양도되면 차단이 해제되고 최신 데이터를 전송(출력)합니다.

 

따라서 두 작업은 독립적으로 실행되지만 완벽하게 동기화됩니다:

 

ADC 작업 → 읽기 및 신호 전송
UART 작업 → 대기 및 전송

 

이렇게 하면 UART가 오래되거나 불완전한 데이터를 전송하지 않습니다. FreeRTOS 바이너리 세마포어 를 사용하여 작업 타이밍을 조정 하는 간단하고 안전한 방법입니다 .

 

결과 - ESP-IDF 콘솔의 출력

 

아래 이미지는 ESP-IDF 콘솔 에 인쇄된 로그를 보여줍니다 .

 

 

 

ESP32 세마포어는 UART로 데이터를 전송하기 전에 태스크에 의해 사용됩니다. 세마포어는 다른 태스크에 의해 부여됩니다.

 

ADC 태스크가 새 값을 읽을 때마다 세마포어를 전송하는 것을 볼 수 있습니다 .

그 직후, UART 태스크가 세마포어를 가져와 같은 값을 전송합니다.

이는 바이너리 세마포어를 사용한 태스크 동기화가 제대로 이루어졌음을 보여줍니다 .

 

세마포어 사용 시 흔히 저지르는 실수

 

세마포어는 간단하지만, 잘못 사용하면 까다로운 버그를 유발할 수 있습니다.

 

다음은 피해야 할 몇 가지 흔한 실수입니다.

 

• 작업 루프 내부에 세마포어를 생성합니다 . 항상 한 번만( 에서 app_main()) 생성하고 반복적으로 생성하지 마세요.
• 지연 없음(0틱)을 사용하면xSemaphoreTake() 작업이 끝없이 회전하고 CPU 시간을 낭비하게 됩니다.
• 세마포어를 주는 것을 잊어버림 - 대기 중인 작업은 결코 깨어나지 않습니다.
• 교착 상태 – 작업이 세마포어를 받아서 결코 해제하지 않는 경우입니다.
• 뮤텍스 대신 세마포어 사용 – 공유 데이터를 보호할 때 세마포어 대신 뮤텍스를 선호합니다(다음 섹션에서 설명).

 

ESP32 FreeRTOS의 뮤텍스

 

여러 작업이 I2C , SPI , UART 와 같은 공통 리소스를 공유하는 경우 , 한 번에 하나의 작업만 해당 리소스에 접근하도록 하는 것이 중요합니다. 그렇지 않으면 데이터가 손상되거나 시스템이 예기치 않게 작동할 수 있습니다.

 

이러한 상황을 처리하기 위해 FreeRTOS는 뮤텍스(상호 배제 객체)를 제공합니다 . 뮤텍스는 "잠금"과 같은 역할을 합니다. 즉, 한 작업이 잠금을 획득하면 다른 작업은 잠금이 해제될 때까지 기다려야 합니다.

 

뮤텍스란 무엇이고 세마포어와 다른 점은 무엇입니까?

 

언뜻 보기에 뮤텍스와 바이너리 세마포어는 비슷해 보일 수 있습니다. 둘 다 한 번에 하나의 작업만 리소스에 접근할 수 있도록 허용합니다.

 

하지만 몇 가지 주요 차이점이 있습니다.

 

특징	Semaphore	Mutex
목적	동기화 또는 신호	공유 자원 보호
소유권	소유권 없음 - 모든 작업은 주고받을 수 있음	그것을 수행하는 작업에 의해 소유됨
우선권 상속	지원되지 않음	지원됨
일반적인 사용	작업 동기화	리소스 잠금(예: I2C, SPI, UART)

 

간단히 말해서:

 

• 세마포어를 사용하여 작업 간에 신호를 보내 거나 동기화합니다 .
• 뮤텍스를 사용하여 공유 리소스를 보호 하고 동시 액세스를 방지합니다.

 

FreeRTOS의 우선 순위 상속

 

FreeRTOS에서 세마포어를 사용할 때 우선순위 반전이라는 문제가 발생할 수 있습니다 .

 

우선순위 역전이란 무엇인가요?

 

우선순위 역전은 다음과 같은 경우에 발생합니다.

 

1. 낮은 우선순위의 작업은 세마포어(또는 리소스)를 보유합니다.
2. 높은 우선순위의 작업에는 공유 리소스에 액세스하기 위해 동일한 세마포어가 필요합니다.
3. 중간 우선순위 작업은 낮은 우선순위 작업을 선점하여 낮은 우선순위 작업이 세마포어를 해제하지 못하도록 합니다.

 

결과적으로, 우선순위가 높은 작업은 더 높은 우선순위를 가짐에도 불구하고 예상보다 오랫동안 차단 됩니다. 이를 우선순위 역전이라고 합니다. 이는 예상치 못한 지연을 초래하고 시스템의 실시간 성능을 저하시킬 수 있습니다.

 

아래 이미지는 세마포어를 사용할 때의 우선순위 반전을 보여줍니다.

 

 

우선순위 역전이란 무엇인가요? 세마포어를 사용할 때 어떻게 발생하나요?

 

위 이미지에서 볼 수 있듯이 세마포어를 사용하면 우선순위가 높은 작업이 낮은 우선순위 작업이 실행되는 동안 대기하게 됩니다. 높은 우선순위 작업은 중간 우선순위 작업이 작업을 완료할 때까지 기다려야 합니다 . 이를 우선순위 역전 이라고 합니다 .

 

뮤텍스를 사용하면 우선순위 역전 문제를 해결할 수 있습니다. 뮤텍스를 사용하면 우선순위 상속이 보장되어 , 우선순위가 낮은 작업이 뮤텍스를 획득하면 우선순위가 가장 높은 작업으로 증가합니다.

 

우선 순위 상속이 중요한 이유

 

우선순위 상속은 이 문제를 자동으로 해결합니다.

 

• 높은 우선순위의 작업이 낮은 우선순위의 작업이 이미 보유한 뮤텍스를 가져오려고 하면 FreeRTOS는 일시적으로 낮은 우선순위의 작업의 우선순위를 높입니다 .
• 낮은 우선순위의 작업은 더 빨리 실행되고, 뮤텍스를 해제한 후 우선순위가 정상으로 돌아갑니다.

 

이익:

 

• 우선순위가 높은 작업이 너무 오랫동안 대기하는 것을 방지합니다.
• 실시간 동작을 방해할 수 있는 우선순위 역전을 방지합니다 .
• ESP32 애플리케이션에서 예측 가능하고 안전한 멀티태스킹을 보장합니다 .

 

예시 시나리오:

 

1. 낮은 우선순위 작업은 I2C 뮤텍스를 보유합니다.
2. 높은 우선순위의 작업에는 동일한 뮤텍스가 필요합니다.
3. 중간 우선순위 작업은 정상적으로 실행됩니다.
4. 우선순위 상속 없음 → 높은 우선순위 작업은 중간 우선순위 작업이 완료될 때까지 차단됩니다.
5. 우선순위 상속 → 낮은 우선순위의 작업은 일시적으로 높은 우선순위를 얻고, 더 빨리 완료되며, 뮤텍스를 해제하고, 높은 우선순위의 작업이 즉시 진행됩니다.

 

아래 이미지는 우선순위 역전 문제를 해결하는 우선순위 상속을 보여줍니다.

 

 

우선순위 상속이란 무엇인가요? 뮤텍스를 사용하면 우선순위 역전 문제가 어떻게 해결되나요?

 

이미지에서 볼 수 있듯이, 낮은 우선순위의 작업이 뮤텍스를 획득하면 대기 중인 가장 높은 우선순위의 작업의 우선순위를 얻습니다. 따라서 다른 작업은 해당 작업을 선점할 수 없습니다. 다른 작업은 뮤텍스가 해제되고 해당 뮤텍스를 기다리는 작업이 완료된 후에만 실행될 수 있습니다.

 

뮤텍스를 해제하면 작업의 우선순위가 정상으로 돌아갑니다.

 

이 메커니즘은 FreeRTOS 뮤텍스에 내장되어 있으며 자동으로 작동하므로 이를 처리하기 위한 추가 코드가 필요하지 않습니다.

 

뮤텍스가 데이터 손상을 방지하는 방법

 

두 작업이 동시에 동일한 I2C 버스 에 데이터를 쓰려고 한다고 상상해 보세요 . 보호 기능이 없다면 두 작업 모두 동시에 데이터를 전송하여 버스 충돌 이나 통신 장애를 일으킬 수 있습니다 .

 

뮤텍스 는 다음을 보장합니다.

 

• 한 번에 하나의 작업 만 리소스에 액세스할 수 있습니다.
• 이를 사용하려는 다른 작업은 뮤텍스가 해제될 때까지 기다려야 합니다.
• 작업이 완료되면 뮤텍스를 반환하여 다른 작업이 계속 진행될 수 있도록 합니다.

 

이렇게 하면 경쟁 조건이 방지되고 공유 주변 장치나 변수가 안전하게 유지됩니다.

 

FreeRTOS는 뮤텍스 제어를 위한 두 가지 간단한 API를 제공합니다.

 

xSemaphoreTake(xMutex, portMAX_DELAY);
xSemaphoreGive(xMutex);

 

예 - 공유 리소스 보호(I2C 또는 SPI 버스)

 

뮤텍스를 사용하여 두 작업이 어떻게 안전하게 I2C 버스를 공유할 수 있는지 살펴보겠습니다.

 

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

SemaphoreHandle_t sharedMutex;

void LowPriorityTask(void *pvParameters)
{
    while (1)
    {
        if (xSemaphoreTake(sharedMutex, portMAX_DELAY))
        {
            printf("LowPriorityTask: Holding shared resource  current priority: %u\n", uxTaskPriorityGet(NULL));
            vTaskDelay(pdMS_TO_TICKS(2000)); // Simulate long operation
            printf("LowPriorityTask: Releasing shared resource  current priority: %u\n", uxTaskPriorityGet(NULL));
            xSemaphoreGive(sharedMutex);
        }
        vTaskDelay(pdMS_TO_TICKS(500));
    }
}

void MediumPriorityTask(void *pvParameters)
{
    while (1)
    {
        printf("MediumPriorityTask: Doing background work\n");
        vTaskDelay(pdMS_TO_TICKS(500));
    }
}

void HighPriorityTask(void *pvParameters)
{
    while (1)
    {
        vTaskDelay(pdMS_TO_TICKS(1000)); // Let low task grab mutex first

        printf("HighPriorityTask: Needs shared resource\n");
        if (xSemaphoreTake(sharedMutex, portMAX_DELAY))
        {
            printf("HighPriorityTask: Got shared resource\n");
            vTaskDelay(pdMS_TO_TICKS(1000));
            printf("HighPriorityTask: Releasing shared resource\n");
            xSemaphoreGive(sharedMutex);
        }
    }
}

void app_main(void)
{
    sharedMutex = xSemaphoreCreateMutex();
    if (sharedMutex == NULL)
    {
        printf("Failed to create Mutex!\n");
        return;
    }

    // Priorities: High > Medium > Low
    xTaskCreate(LowPriorityTask, "LowPriority", 2048, NULL, 1, NULL);
    xTaskCreate(MediumPriorityTask, "MediumPriority", 2048, NULL, 2, NULL);
    xTaskCreate(HighPriorityTask, "HighPriority", 2048, NULL, 3, NULL);
}

 

위의 예는 우선순위 상속이 어떻게 작동하는지 보여줍니다.

 

LowPriorityTask :

먼저 뮤텍스를 가져와 잠시 동안 유지합니다(긴 작업 시뮬레이션).

 

HighPriorityTask :

나중에 동일한 뮤텍스를 가져오려고 시도하지만 낮은 우선순위 작업이 뮤텍스를 해제할 때까지 기다려야 합니다.

 

MediumPriorityTask :

일반적으로 낮은 우선순위 작업을 우선시하는 백그라운드 작업을 계속 실행합니다.

 

하지만 뮤텍스는 우선순위 상속을 사용하기 때문에 , 우선순위가 낮은 작업은 뮤텍스를 해제할 때까지 높은 작업의 우선순위를 일시적으로 상속받습니다.

 

이렇게 하면 중간 우선순위 작업이 낮은 우선순위 작업을 굶기는 것을 방지하여 우선순위 역전이 자동으로 해결됩니다.

 

결과 - ESP-IDF 콘솔의 출력

 

아래 이미지는 ESP-IDF 콘솔 에 인쇄된 로그를 보여줍니다 .

 

 

 

이미지는 뮤텍스를 사용하여 우선순위 상속을 생성하는 방법을 보여줍니다. 이렇게 하면 뮤텍스를 보유한 작업의 우선순위가 가장 높은 값으로 변경됩니다.

 

이미지에서 보여지는 내용은 다음과 같습니다.

 

LowPriorityTask가 먼저 시작됩니다.

낮은 우선순위 작업은 뮤텍스를 획득하고 일반 우선순위( 1 )로 공유 리소스를 사용하기 시작합니다.

 

MediumPriorityTask는 정상적으로 실행됩니다.

높은 우선순위 작업이 아직 뮤텍스를 사용하려고 하지 않았으므로 중간 우선순위 작업은 백그라운드 작업을 계속하고 낮은 우선순위 작업을 선점할 수 있습니다.

 

HighPriorityTask가 뮤텍스를 요청합니다.

높은 우선순위의 작업이 동일한 리소스에 접근하려고 하면, 낮은 우선순위의 작업이 뮤텍스를 여전히 보유하고 있기 때문에 차단됩니다. 이때 우선순위 상속이 적용됩니다. 즉, 낮은 우선순위의 작업의 우선순위가 높은 우선순위의 작업과 같도록 일시적으로 높아집니다.

 

LowPriorityTask는 우선 순위가 높아져 완료됩니다.

리소스를 해제할 때 출력되는 우선 순위가 3 인 것을 보면 우선 순위 상속이 활성화되었음을 알 수 있습니다.

이제 낮은 우선순위 작업이 중간 우선순위 작업보다 먼저 실행되어 뮤텍스를 빠르게 완료하고 해제합니다.

 

HighPriorityTask가 재개됩니다.

낮은 작업이 뮤텍스를 해제하자마자 높은 작업은 즉시 액세스 권한을 얻어 작업을 진행합니다.

 

정상 우선순위 복원
뮤텍스가 해제된 후 모든 작업은 원래 우선순위로 복귀합니다. 이후 이 주기가 반복됩니다.

 

이 로그는 우선순위 상속이 우선순위 역전을 어떻게 방지하는지 명확하게 보여줍니다 . 우선순위가 낮은 작업이 더 높은 우선순위의 작업이 동일한 뮤텍스를 기다리고 있을 때 중요 섹션을 빠르게 완료할 수 있도록 보장합니다.

 

다중 작업 조정을 위한 이벤트 그룹

 

복잡한 ESP32 애플리케이션에서는 여러 작업이 함께 작동하거나 특정 이벤트가 발생할 때까지 기다려야 하는 경우가 많습니다. FreeRTOS는 이러한 조정을 효율적으로 처리하기 위해 이벤트 그룹 이라는 강력한 기능을 제공합니다 .

 

이벤트 그룹을 사용하면 작업을 설정하고, 지우고, 특정 이벤트 비트를 기다릴 수 있으므로 대량의 데이터 교환 없이 멀티태스킹 동기화 에 적합합니다 .

 

이벤트 그룹이란 무엇입니까?

 

FreeRTOS의 이벤트 그룹은 다양한 시스템 이벤트를 나타내는 개별 플래그(비트) 의 모음과 같습니다 .

 

그룹의 각 비트는 고유한 조건을 나타낼 수 있습니다. 예:

 

• 비트 0 → 센서1 데이터 준비 완료
• 비트 1 → 센서2 데이터 준비 완료
• 비트 2 → Wi-Fi 연결됨

 

작업은 실행을 계속하기 전에 하나 이상의 비트가 설정될 때까지 기다릴 수 있습니다. 이를 통해 여러 작업 간의 깔끔하고 효율적인 조정이 가능합니다.

 

이벤트 비트를 생성하고 설정하는 방법

 

• 다음을 사용하여 이벤트 그룹을 만듭니다.EventGroupHandle_t eventGroup = xEventGroupCreate();
• 비트 설정(이벤트 신호):xEventGroupSetBits(eventGroup, BIT0);
• 비트를 기다립니다(이벤트가 발생할 때까지 차단):xEventGroupWaitBits(eventGroup, BIT0 | BIT1, pdTRUE, pdTRUE, portMAX_DELAY);

 

여기서 작업은 BIT0과 BIT1이 모두 설정될 때까지 기다립니다. 즉, 두 이벤트가 모두 발생한 것입니다.

 

예 - 여러 센서 작업 조정

 

두 개의 센서 작업이 독립적으로 데이터를 읽고, 두 센서가 모두 준비된 후에만 시작해야 하는 하나 의 처리 작업이 있다고 가정해 보겠습니다 .

 

• Sensor1 작업은 BIT0 읽기가 완료되면 설정됩니다 .
• Sensor2 작업은 BIT1 판독이 완료되면 설정됩니다 .
• 처리 작업은 두 비트가 모두 설정될 때까지 기다린 후 데이터 처리를 시작합니다.

 

이 방법을 사용하면 모든 센서가 작업을 완료했는지 확인하고, 데이터의 일관성과 동기화를 유지할 수 있습니다.

 

이를 보여주는 예는 아래와 같습니다.

 

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

EventGroupHandle_t sensorEventGroup;

#define SENSOR1_BIT (1 << 0)
#define SENSOR2_BIT (1 << 1)

void Sensor1Task(void *pvParameters)
{
    while (1)
    {
        printf("Sensor1: Reading data...\n");
        vTaskDelay(pdMS_TO_TICKS(1000)); // Simulate sensor delay
        printf("Sensor1: Data ready\n");

        xEventGroupSetBits(sensorEventGroup, SENSOR1_BIT);
        vTaskDelay(pdMS_TO_TICKS(2000)); // Wait before next cycle
    }
}

void Sensor2Task(void *pvParameters)
{
    while (1)
    {
        printf("Sensor2: Reading data...\n");
        vTaskDelay(pdMS_TO_TICKS(1500)); // Simulate different timing
        printf("Sensor2: Data ready\n");

        xEventGroupSetBits(sensorEventGroup, SENSOR2_BIT);
        vTaskDelay(pdMS_TO_TICKS(2000));
    }
}

void ProcessingTask(void *pvParameters)
{
    while (1)
    {
        printf("Processing Task: Waiting for both sensors...\n");

        // Wait for both Sensor1 and Sensor2 to signal readiness
        xEventGroupWaitBits(sensorEventGroup,
                            SENSOR1_BIT | SENSOR2_BIT,
                            pdTRUE,   // Clear bits after waiting
                            pdTRUE,   // Wait for both bits
                            portMAX_DELAY);

        printf("Processing Task: Both sensors ready! Processing data...\n");
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

void app_main(void)
{
    sensorEventGroup = xEventGroupCreate();

    if (sensorEventGroup == NULL)
    {
        printf("Failed to create Event Group!\n");
        return;
    }

    xTaskCreate(Sensor1Task, "Sensor1", 2048, NULL, 1, NULL);
    xTaskCreate(Sensor2Task, "Sensor2", 2048, NULL, 1, NULL);
    xTaskCreate(ProcessingTask, "Processing", 2048, NULL, 2, NULL);
}

 

이 코드는 FreeRTOS에서 이벤트 그룹을 사용하여 여러 작업을 조정하는 방법을 보여줍니다 .

 

두 센서 작업은 데이터가 준비되면 이벤트 비트를 설정하고, 처리 작업은 두 센서가 모두 완료될 때까지 기다린 후 데이터를 처리합니다. 이 코드는 큐나 세마포어를 사용하지 않고도 적절한 동기화를 보장합니다.

 

결과 - 콘솔 출력

 

아래 이미지는 각 센서 작업이 데이터를 읽고 비트를 설정하는 방법을 보여줍니다. 두 비트가 모두 설정되면 처리 작업이 실행 됩니다.

 

 

 

이 이미지는 처리 작업이 두 개의 센서 작업에 의존함을 보여줍니다. 두 센서 모두 데이터가 준비되었음을 나타내면, 처리 작업은 이를 감지하고 즉시 결합된 센서 데이터 처리를 시작합니다.

 

이 이미지는 처리 작업이 두 가지 센서 작업에 의존함 을 보여줍니다 . 처리 작업은 두 센서 모두 측정값을 읽을 때까지 기다린 후 시작합니다.

 

두 센서 모두 데이터가 준비되었음을 나타내면, 처리 작업은 이를 감지하고 즉시 결합된 센서 데이터를 처리하기 시작합니다.

 

이러한 접근 방식은 처리 작업이 불완전한 정보로 조기에 실행되지 않도록 보장하고 작업 간의 적절한 조정을 유지합니다. 이러한 순환은 실시간 시스템에서 바쁜 대기 없이 효율적으로 동기화되고, CPU 리소스를 보존하며, 정확한 데이터 처리를 보장하는 방법을 보여줍니다.

 

큐 대신 이벤트 그룹을 사용해야 하는 경우

 

다음과 같은 경우 이벤트 그룹을 사용하세요 .

 

• 실제 데이터를 보낼 필요는 없고, 상태나 이벤트를 신호로 전달 하기만 하면 됩니다 .
• 여러 작업은 공통적인 조건 에 따라 달라집니다 .
• 여러 이벤트를 동시에 기다리고 싶습니다 .

 

다음과 같은 경우 대기열을 사용하세요 .

 

• 작업 간에 데이터 (예: 센서 판독값, 메시지) 를 교환 해야 합니다 .
• 여러 개의 데이터 항목을 안전하게 버퍼링하려고 합니다.

 

아래 표는 FreeRTOS 큐와 이벤트 그룹의 차이점을 보여줍니다.

 

대기열

특징	이벤트 그룹	대기열
목적	작업 간 신호 전달 및 동기화에 사용됨	작업 간 데이터 송수신에 사용됨
데이터 처리	비트만 설정하거나 지웁니다(실제 데이터 전송 없음)	실제 데이터 값이나 구조를 전송합니다.
메모리 사용량	매우 낮음(몇 비트만)	더 높음(대기열 크기 및 데이터 유형에 따라 다름)
방향	일반적으로 다대일 또는 일대다 신호	일반적으로 일대일 또는 일대다 데이터 전송
차단 동작	작업은 하나 또는 여러 비트가 설정될 때까지 기다릴 수 있습니다.	데이터나 공간을 기다리는 동안 작업이 차단될 수 있습니다.
사용 사례 예	여러 작업이 완료될 때까지 기다리기(예: 모든 센서 준비 완료)	작업 간 센서 판독값 또는 메시지 전달
언제 사용해야 하나요?	이벤트나 상태 플래그 만 신호로 보내야 할 때	작업 간에 데이터나 메시지를 공유 해야 할 때

 

 

결론

 

ESP32 FreeRTOS 시리즈의 이 부분에서는 다양한 작업이 안전하게 통신하고 동기화되는 방법을 살펴보았습니다 .

 

다음 내용에 대해 알아보았습니다.

• 큐 - 작업 간에 데이터를 전송하기 위한 것입니다.
• 세마포어 - 동기화 및 타이밍 제어를 위해 사용됩니다.
• 뮤텍스 - 공유 리소스를 보호하기 위해 사용됩니다.
• 이벤트 그룹 – 여러 작업 간의 신호 전달 및 조정을 위해 사용됩니다.

 

이러한 각 메커니즘은 ESP32에서 안정적인 멀티태스킹 시스템을 구축하는 데 중요한 역할을 합니다 .

 

다음 튜토리얼에서는 FreeRTOS 소프트웨어 타이머 와 작업 알림에 대해 알아보겠습니다 . 이 가벼운 도구는 종종 큐나 세마포어를 대체하여 더 간단한 통신을 가능하게 합니다.