为什么需要双核任务分配

ESP32-S3 内置双核 Xtensa LX7，主频高达 240MHz，并集成 2.4GHz WiFi/BLE。默认情况下，Arduino 或 ESP-IDF 会把所有任务动态调度到两个核心上，导致 WiFi 协议栈处理中断时，实时控制任务被抢占，产生几十微秒到毫秒级的抖动。

对于电机控制、传感器采样等需要严格周期的场景，这种抖动不可接受。解决方案是：将 WiFi 协议栈固定到 Core 0，将实时控制任务固定到 Core 1，并合理配置中断优先级和任务优先级。

核心原理与关键 API

核心亲和性（Core Affinity）：FreeRTOS 允许创建任务时指定运行核心，xTaskCreatePinnedToCore() 是核心 API。
中断分配：ESP32-S3 的外设中断可绑定到指定核心，通过 esp_intr_alloc() 的 ESP_INTR_FLAG_IRAM 和核心参数控制。
WiFi 任务默认行为：ESP-IDF 的 WiFi 任务（如 wifi、esp_timer）默认运行在 Core 0，但未强制绑定，需手动设置。
缓存与内存：双核共享内存，但每个核心有独立缓存。跨核访问共享数据需使用原子操作或互斥锁，避免缓存不一致。

配置步骤

1. 固定 WiFi 协议栈到 Core 0

在 menuconfig 中设置：

Component config → Wi-Fi → WiFi Task Core ID → 0
Component config → FreeRTOS → Run FreeRTOS only on first core → 取消勾选

同时确保 CONFIG_FREERTOS_UNICORE 为 n。

2. 创建实时控制任务并绑定到 Core 1

使用 xTaskCreatePinnedToCore()，并设置最高优先级（例如 configMAX_PRIORITIES - 1）。

3. 配置外设中断到 Core 1

对于需要硬实时的外设（如 GPIO 边沿中断、定时器），使用 esp_intr_alloc() 时传入核心编号。

完整代码示例

以下代码基于 ESP-IDF v5.x，创建一个 1ms 周期的控制任务在 Core 1，同时 WiFi 在 Core 0 运行。

#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "driver/gpio.h"
#include "esp_timer.h"
#include "esp_wifi.h"
#include "esp_event.h"
#include "nvs_flash.h"

#define CONTROL_GPIO 2
#define CONTROL_PERIOD_US 1000  // 1ms

// 共享变量：使用 volatile 防止编译器优化
static volatile uint32_t g_control_ticks = 0;
static portMUX_TYPE g_mux = portMUX_INITIALIZER_UNLOCKED;

// 实时控制任务，绑定到 Core 1
void control_task(void *arg)
{
    gpio_config_t io_conf = {
        .pin_bit_mask = (1ULL << CONTROL_GPIO),
        .mode = GPIO_MODE_OUTPUT,
        .pull_up_en = GPIO_PULLUP_DISABLE,
        .pull_down_en = GPIO_PULLDOWN_DISABLE,
        .intr_type = GPIO_INTR_DISABLE,
    };
    gpio_config(&io_conf);

    int64_t next_wake = esp_timer_get_time();
    while (1) {
        // 翻转 GPIO，模拟控制信号
        gpio_set_level(CONTROL_GPIO, 1);
        gpio_set_level(CONTROL_GPIO, 0);

        portENTER_CRITICAL(&g_mux);
        g_control_ticks++;
        portEXIT_CRITICAL(&g_mux);

        // 精确延时到下一个周期
        next_wake += CONTROL_PERIOD_US;
        int64_t now = esp_timer_get_time();
        int64_t delay = next_wake - now;
        if (delay > 0) {
            esp_rom_delay_us(delay);
        } else {
            // 如果落后，重置基准
            next_wake = now;
        }
    }
}

// WiFi 事件处理（运行在 Core 0）
static void wifi_event_handler(void *arg, esp_event_base_t event_base,
                               int32_t event_id, void *event_data)
{
    if (event_base == WIFI_EVENT && event_id == WIFI_EVENT_STA_START) {
        esp_wifi_connect();
    }
}

void app_main(void)
{
    // 初始化 NVS
    esp_err_t ret = nvs_flash_init();
    if (ret == ESP_ERR_NVS_NO_FREE_PAGES || ret == ESP_ERR_NVS_NEW_VERSION_FOUND) {
        nvs_flash_erase();
        nvs_flash_init();
    }

    // 初始化 WiFi 为 STA 模式
    esp_netif_init();
    esp_event_loop_create_default();
    esp_netif_create_default_wifi_sta();
    wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT();
    esp_wifi_init(&cfg);
    esp_event_handler_register(WIFI_EVENT, ESP_EVENT_ANY_ID, &wifi_event_handler, NULL);
    esp_wifi_set_mode(WIFI_MODE_STA);
    esp_wifi_start();

    // 创建实时控制任务，绑定到 Core 1，优先级最高
    xTaskCreatePinnedToCore(control_task, "control_task", 4096, NULL,
                            configMAX_PRIORITIES - 1, NULL, 1);

    // 主任务可以继续处理其他低优先级工作
    while (1) {
        vTaskDelay(pdMS_TO_TICKS(1000));
        portENTER_CRITICAL(&g_mux);
        uint32_t ticks = g_control_ticks;
        portEXIT_CRITICAL(&g_mux);
        printf("Control ticks: %lu\n", ticks);
    }
}

踩坑记录与注意事项

坑1：WiFi 任务未真正固定到 Core 0。仅在 menuconfig 中设置 WiFi Task Core ID 不够，某些 IDF 版本中 esp_timer 和 tcpip 任务仍可能跑在 Core 1。建议在启动后调用 vTaskCoreAffinitySet() 强制绑定关键任务。
坑2：中断优先级冲突。WiFi 中断默认优先级较高，若控制任务的中断优先级低于 WiFi，仍会被抢占。应将控制相关中断优先级设为高于 WiFi 中断（但低于 configMAX_SYSCALL_INTERRUPT_PRIORITY）。
坑3：共享数据未加锁。双核同时读写 g_control_ticks 会导致数据竞争。必须使用 portENTER_CRITICAL 或原子操作。
坑4：esp_rom_delay_us 在双核下精度下降。该函数是忙等待，若另一个核心频繁访问内存，会因总线仲裁导致延时变长。建议使用硬件定时器或 esp_timer 高精度定时器。
坑5：栈空间不足。控制任务若调用浮点运算或 printf，需分配至少 4KB 栈，否则会崩溃。
坑6：未关闭看门狗。长时间忙等待可能触发任务看门狗，需在 menuconfig 中调整或定期喂狗。

验证与调试

使用 esp_timer_get_time() 测量控制任务的实际周期抖动，目标应小于 10μs。
通过 vTaskGetRunTimeStats() 查看各核心负载，确保 Core 1 不被其他任务干扰。
若 WiFi 吞吐量下降，可适当降低控制任务优先级或减少临界区长度。

总结

ESP32-S3 双核为实时控制与无线通信共存提供了可能，但必须显式绑定任务核心、管理中断优先级、保护共享数据。本文的代码和避坑清单可直接用于电机控制、传感器采集等场景，帮助你在 1ms 周期下稳定运行 WiFi 协议栈。

ESP32-S3 双核任务分配实战：把 WiFi 协议栈和实时控制拆到不同核心的踩坑记录