ESP32 雙核心教學：何時分工、何時別碰 Core 0

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-09-09

XDA Developers 的教學文章提醒，針對採用雙核心 Xtensa 處理器的 ESP32 板，Arduino IDE 的一般 sketch 通常在 Core 1 執行 setup() 與 loop()；Core 0 則主要處理 Wi‑Fi、Bluetooth 等背景協定工作。這不代表 Core 0 完全閒置，亦不表示所有專案都必須手動動用它。對正在製作感測器、顯示器、藍牙傳輸或連網控制器的創客和學生而言，重點在於辨識單一 loop() 是否已被慢速工作拖住，以及在分工後能否承擔同步與排程的複雜度。

最容易誤解的地方，是把「雙核心」直接等同於「程式自動快一倍」。XDA 所述情況其實較具體：自訂程式與無線協定原已有基本分工，而開發者若把更多工作釘選至 Core 0，便會與系統無線工作共享該核心。xTaskCreatePinnedToCore() 是一個可用的分派工具，並非把任何工作丟往另一核心後便可忽略的效能捷徑；若 task 長時間佔用 Core 0，watchdog 可能因系統 task 得不到執行時間而觸發重啟。

先找出單一 loop 的真正瓶頸

文章以同一個 loop() 先讀取 I2C 感測器、再經 Bluetooth 串流資料為例：當其中一項操作需要等待，下一項工作便要延後開始。若同一專案還要刷新顯示器、處理網絡呼叫或寫入 SD 卡，控制邏輯的反應時間便可能受這些較慢工作牽制。這是雙核心分工最有價值的場景：目的不是追求抽象的運算分數，而是減少彼此獨立、等待時間不同的工作互相阻塞。

在 Arduino 環境中，可在 loop() 呼叫 xPortGetCoreID()，檢視程式正在運行的核心；XDA 指出，一般情況會看到回傳值為 1。這個觀察有助開發者建立正確起點：Core 1 上的程式已足以應付不少簡單 sketch，因此單純的感測讀值、按鍵輸入或小型顯示更新，未必值得改成多 task 架構。先量度或觀察哪一段造成卡頓，比起一開始就拆成兩核心，更容易維護。

合理的分工，是把時間敏感工作留在主流程

按 XDA 的建議，可把主要感測讀取、顯示更新和控制邏輯保留在 Core 1，並考慮將可容許延遲的 SD 寫入，以及非阻塞式網絡工作安排給 Core 0。這只是一種工作分配方向，實際設計仍要看各 task 的執行時間、資料依賴和無線使用量。舉例說，若控制器必須頻密採樣並即時更新畫面，將較慢的儲存工作移走，理論上可令主控制流程較少因等待寫入而停頓；這是由文章例子引出的設計分析，並非對所有 ESP32 專案的保證。

實作時，開發者可透過 xTaskCreatePinnedToCore() 把指定 task 綁定到特定核心。不過，綁定與平行並不會自動解決資料交換問題：兩個 task 若同時讀寫同一份狀態，仍需要設計保護機制。XDA 點名 mutex 與 queue，正是處理跨核心 thread-safety 的基本考量。前者可避免多個 task 在同一時間改動共享資源；後者則可讓一個 task 把資料交給另一個 task 處理，減少直接共用資料所帶來的競爭情況。

Core 0 的限制比「還有半粒晶片」更重要

最關鍵的守則是：任何釘選至 Core 0 的 task，都要定期交回控制權給 scheduler。XDA 建議使用 vTaskDelay()，即使只延遲 1ms，也讓 Wi‑Fi／Bluetooth stack 有機會取得 CPU 時間。若 task 持續忙等、無限計算或以阻塞方式霸佔核心，無線背景工作可能被餓死，最後由 watchdog 偵測到問題並重啟系統。這也是為何把工作搬到 Core 0 前，應先檢查 task 是否真的會讓出執行時間。

因此，較穩妥的開發次序是先維持單核心的清晰流程，再把已確認會阻塞、且能獨立運作的工作拆出；拆出後以 queue 或 mutex 處理資料交接，並確保 Core 0 task 有 vTaskDelay() 等讓步點。對只做基本讀值或簡單控制的作品，保留原來結構通常更直接；對同時要感測、顯示、傳輸及儲存資料的作品，雙核心才較可能帶來可感知的改善。

下一步值得觀察的，將是 ESP32 開發者能否把「使用第二核心」由單純釘選 task，提升為有明確時序、共享資料規則和無線資源預留的設計。尤其是同時依賴 Bluetooth 或 Wi‑Fi 的裝置，Core 0 的可用空間從來都要與協定工作共同計算；明白這項限制，才較能判斷一個專案是否適合多核心分工。