ESP32 双核任务分配不当导致 Wi-Fi 吞吐量骤降的实战分析

注意ESP32的FreeRTOS tick频率（默认100Hz）会影响任务切换粒度，若任务频繁抢占，可考虑将tick提高到1000Hz，但会增加功耗，需权衡。

低功耗工程师 · 2026-08-27

实测发现，DMA和中断共享优先级时，若用户ISR处理过长（超过Wi-Fi beacon间隔），会直接导致丢包。务必在ISR中只做标志位，实际处理放任务。

无线调试员 · 2026-08-27

补充一点：如果使用Arduino框架，默认loop运行在核心1，但Wi-Fi事件处理在核心0，建议将网络相关回调（如WiFiEvent）中的耗时操作移到核心1，避免阻塞协议栈。

嵌入式老张 · 2026-08-27

ESP32双核任务分配不当导致Wi-Fi吞吐量骤降，核心原因是Wi-Fi协议栈和TCP/IP栈默认运行在核心0（协议核心），而用户任务若抢占核心0的CPU时间（尤其是高优先级或长时间占用），会直接延迟Wi-Fi中断处理和协议栈调度，造成吞吐量断崖式下降。实战建议：1）将计算密集型任务（如音频处理、算法运算）固定到核心1（应用核心），使用xTaskCreatePinnedToCore指定核心，并设置适当优先级（低于Wi-Fi任务优先级，通常Wi-Fi任务优先级为23，用户任务建议≤10）；2）避免在核心0上运行阻塞型任务（如delay、while轮询），若必须，则使用vTaskDelay或事件组让出CPU；3）检查Wi-Fi任务是否被饿死，可通过vTaskGetRunTimeStats观察各任务运行时间占比，若核心0上用户任务占比过高，需调整任务亲和性；4）启用Wi-Fi的PS（省电）模式时，吞吐量本身会下降，若需高吞吐，应关闭PS（esp_wifi_set_ps(WIFI_PS_NONE)）。最后，使用iperf实测验证，并配合ESP-IDF的SystemView或FreeRTOS trace分析任务调度。

mcuku 阿沐 · 2026-08-27