引言：当信号量成为性能瓶颈

在ESP32这类双核MCU上，FreeRTOS是标配RTOS。开发者常用信号量（Semaphore）来同步任务，但鲜有人意识到：信号量可能引发优先级反转，导致高优先级任务被低优先级任务阻塞，实时性大打折扣。尤其在多核场景下，问题更复杂。本文将带你用FreeRTOS任务通知（Task Notification）替代信号量，从根源上消除反转，并给出可直接落地的实战代码。

1. 优先级反转：信号量的隐藏代价

1.1 什么是优先级反转

假设有三个任务：高优先级H、中优先级M、低优先级L。L持有信号量，H等待该信号量。此时M就绪，抢占L（因为M优先级高于L），导致H被M间接阻塞——H明明优先级最高，却要等M执行完，这就是反转。

1.2 信号量的经典解法与局限

FreeRTOS提供优先级继承机制：当H等待信号量时，L临时提升到H的优先级。但这会带来额外开销，且在多核下继承逻辑复杂，甚至可能失效（因为两个核独立调度）。

1.3 任务通知：更轻量的替代

任务通知是FreeRTOS特有的机制，每个任务有一个32位通知值，可直接发送事件或数据。它不涉及内核对象，无需创建、删除，速度比信号量快约45%（官方数据）。更重要的是，任务通知是点对点的，不存在“持有”概念，因此天然免疫优先级反转。

2. ESP32多核架构下的任务通知实战

2.1 场景设计

我们设计一个数据采集系统：

  • 任务A（高优先级，核0）：读取传感器数据，处理并输出。
  • 任务B（低优先级，核1）：模拟慢速外设，产生数据就绪事件。

传统做法：B发送信号量，A获取。我们改用任务通知：B直接向A发送通知值（携带数据指针）。

2.2 硬件准备

  • ESP32开发板（如ESP32-DevKitC）
  • 一个按键或跳线（模拟传感器触发）

2.3 代码实现

步骤1：创建任务并获取句柄

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

TaskHandle_t taskA_handle = NULL;

// 任务A：高优先级，处理数据
void taskA(void *arg) {
    uint32_t notification_value;
    while (1) {
        // 阻塞等待任务通知，不设置超时
        if (xTaskNotifyWait(0, 0xFFFFFFFF, &notification_value, portMAX_DELAY) == pdTRUE) {
            // notification_value 携带数据指针（此处为示例，直接打印）
            printf("TaskA received notification, value: %lu\n", (unsigned long)notification_value);
            // 模拟数据处理
            vTaskDelay(pdMS_TO_TICKS(100));
        }
    }
}

// 任务B：低优先级，产生事件
void taskB(void *arg) {
    uint32_t count = 0;
    while (1) {
        vTaskDelay(pdMS_TO_TICKS(1000)); // 每秒触发一次
        count++;
        // 发送通知给任务A，不设置通知值（或可携带数据）
        BaseType_t higher_priority_woken = pdFALSE;
        xTaskNotifyFromISR(taskA_handle, count, eSetValueWithOverwrite, &higher_priority_woken);
        // 注意：在任务中也可用 xTaskNotify，但这里模拟ISR风格
        printf("TaskB sent notification, count: %lu\n", (unsigned long)count);
    }
}

void app_main(void) {
    // 创建任务A，优先级5，运行在核0
    xTaskCreatePinnedToCore(taskA, "taskA", 2048, NULL, 5, &taskA_handle, 0);
    // 创建任务B，优先级1，运行在核1
    xTaskCreatePinnedToCore(taskB, "taskB", 2048, NULL, 1, NULL, 1);
}

步骤2：关键API解析

  • xTaskNotifyWait(ulBitsToClearOnEntry, ulBitsToClearOnExit, *pulNotificationValue, xTicksToWait)：等待通知。第一个参数进入时清零哪些位，第二个退出时清零，第三个获取通知值。
  • xTaskNotifyFromISR(task_handle, ulValue, eAction, *pxHigherPriorityTaskWoken)：从ISR或任务发送通知。eSetValueWithOverwrite表示直接覆盖旧值，适合最新数据覆盖。

步骤3：优化：多核下的注意事项

  • 任务通知是单对单：一个任务只能被一个任务通知，不能像信号量那样多任务等待。若需广播，请用事件组。
  • 通知值可携带指针：例如将数据缓冲区地址作为通知值，但需确保内存安全。
  • ISR中使用专用API：在中断中必须用xTaskNotifyFromISR，并检查pxHigherPriorityTaskWoken，必要时执行portYIELD_FROM_ISR()。

3. 完整示例：传感器数据采集

下面是一个更贴近实际的案例：模拟传感器中断，通过任务通知传递数据，避免反转。

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

#define SENSOR_PIN GPIO_NUM_0

TaskHandle_t consumer_handle = NULL;

// 模拟传感器数据
static int sensor_value = 0;

// 中断服务例程
static void IRAM_ATTR sensor_isr(void *arg) {
    BaseType_t higher_priority_woken = pdFALSE;
    sensor_value = (sensor_value + 1) % 100; // 模拟新数据
    // 发送通知，携带数据指针（此处直接传值）
    xTaskNotifyFromISR(consumer_handle, sensor_value, eSetValueWithOverwrite, &higher_priority_woken);
    if (higher_priority_woken) {
        portYIELD_FROM_ISR();
    }
}

// 消费者任务（高优先级）
void consumer_task(void *arg) {
    uint32_t data;
    while (1) {
        if (xTaskNotifyWait(0, 0, &data, portMAX_DELAY) == pdTRUE) {
            printf("Consumer got sensor data: %lu\n", (unsigned long)data);
            // 处理数据...
        }
    }
}

void app_main(void) {
    // 创建消费者任务，优先级高，核0
    xTaskCreatePinnedToCore(consumer_task, "consumer", 2048, NULL, 10, &consumer_handle, 0);

    // 配置GPIO中断
    gpio_config_t io_conf = {
        .pin_bit_mask = (1ULL << SENSOR_PIN),
        .mode = GPIO_MODE_INPUT,
        .pull_up_en = GPIO_PULLUP_ENABLE,
        .intr_type = GPIO_INTR_NEGEDGE,
    };
    gpio_config(&io_conf);
    gpio_install_isr_service(0);
    gpio_isr_handler_add(SENSOR_PIN, sensor_isr, NULL);

    printf("System started. Press button to trigger sensor.\n");
}

4. 注意事项与陷阱

  • 通知值溢出：若使用eSetValueWithOverwrite，旧值会被覆盖，适合“最新数据”场景；若需累积计数，用eIncrement。
  • 多任务等待：任务通知不支持多任务同时等待同一事件，若需要，请使用队列或事件组。
  • 内存屏障：多核下，通知值传递指针时，需确保数据已同步（如使用vTaskDelay或内存屏障），否则可能读到脏数据。
  • 调试技巧：使用uxTaskGetStackHighWaterMark检查任务栈余量，任务通知比信号量更省栈。

5. 性能对比与总结

| 特性 | 信号量 | 任务通知 | |------|--------|----------| | 优先级反转风险 | 有（需继承机制） | 无 | | 执行速度 | 较慢（内核对象操作） | 快（直接操作任务TCB） | | 内存占用 | 需创建内核对象 | 零额外内存 | | 适用场景 | 多任务互斥、计数 | 单对单同步、轻量事件 |

在ESP32多核场景下，任务通知不仅避免了优先级反转，还减少了内核开销，尤其适合高频率事件通知。但请记住：没有万能药，对于多生产者-消费者模型，队列仍是更稳妥的选择。

结语

通过本文的实战，你已经掌握了用任务通知替代信号量的核心技巧。在嵌入式开发中，选择正确的同步原语，往往比优化代码更有效。下次遇到优先级反转，不妨试试任务通知——它可能让你的系统焕然一新。