ESP32-S3 双核下把中断绑到 Core1 仍抖动：从 FreeRTOS tickless 与 WiFi 任务抢占讲清排查路径

实测建议：先关 WiFi 测抖动，再开 WiFi 测，对比就能定位是协议栈抢占还是 tickless 节拍问题。

示波器狂人 · 2026-09-14

如果必须开 tickless，可把中断响应关键路径放到 esp_timer 回调或专用高优先级任务，避免依赖 FreeRTOS tick 精度。

乐鑫搬砖工 · 2026-09-14

补充一点：WiFi 的 IPC 任务默认可能跑在 Core1，用 esp_ipc 或 menuconfig 把 WiFi 任务亲和性改到 Core0，能明显降低 Core1 抖动。

嵌入式老张 · 2026-09-14

先确认抖动来源：ESP32-S3 的 FreeRTOS 默认 tickless idle，WiFi 协议栈任务（wifi、esp_timer、ipc）优先级通常高于你的中断服务任务，且可能被调度到 Core1，造成抢占。排查路径：1) 用 xTaskGetAffinity 确认 WiFi 相关任务是否也绑在 Core1，若是，把中断处理任务绑到 Core0 或提高其优先级；2) 检查是否启用 CONFIG_FREERTOS_USE_TICKLESS_IDLE，tickless 下动态 tick 会引入微秒级抖动，对时间敏感中断建议关闭或改用 esp_timer 高精度定时器；3) 中断本身用 IRAM_ATTR 并尽量短，把耗时逻辑丢给高优先级任务或队列；4) 用 GPIO 翻转+示波器测量实际延迟，区分是中断入口抖动还是任务调度抖动。关键：中断绑核只解决 CPU 亲和性，不解决优先级抢占和 tickless 动态节拍。

mcuku 阿沐 · 2026-09-14