ESP32-S3 CAM 開發板有兩個 Type C USB 槽, 一個是 UART, 一個是 OTG, 最近幾天測試發現測試發現燒錄時要用 UART, 燒錄完需斷電重開機, 然後改插 OTG 槽, 這樣按 Thonny 的 "執行/重新啟動" 才會順利進入 MicroPython 環境, 如果用 UART 會一直顯示 "Wainting for Bootloader", 我問 Gemini 原因, 回覆整理如下 :
- UART 槽 (COM Port / USB-to-TTL) :
它是透過一顆中介晶片 (通常是 CH343/CH340/CP210x) 來連接電腦與 ESP32 :
電腦 USB訊號 <-> 轉換晶片 <-> ESP32 的 TX/RX 腳位
此槽特點是硬體強制力強, 連接著 ESP32 的重置電路 (EN pin) 啟動模式腳位 (IO0), 它能透過電路訊號 (DTR/RTS) 強制把 ESP32 踢進下載模式 (Download Mode), 所以燒錄韌體時用它是最穩定的. - OTG 槽 (Native USB / USB Serial JTAG) :
它是直通 ESP32-S3 內部的 USB 控制器 :
電腦 USB訊號 <-> ESP32-S3 (沒有中間人)
它需要等 ESP32 內部的韌體 (如 MicroPython) 跑起來之後才能被電腦辨識, ESP32-S3 MicroPython 韌體預設會把 REPL (互動介面) 和模擬磁碟機指定給這個 OTG 端口.
當燒錄好支援 ESP32-S3 的 MicroPython 韌體後, 韌體啟動時會把 Python 的輸出視窗 (REPL) 導向到 Native USB (OTG) 端口而不是 UART 端口. 所以插 OTG 的話 Thonny 就能直接透過 USB 協定跟 MicroPython 對話. 如果插 UART 端口, 當在 Thonny 按下 "停止/重啟" 時, Thonny 會試圖透過 USB 送出一個訊號重置開發板, 並透過那顆 USB 中介晶片去控制硬體的 DTR 和 RTS 腳位, 使開發板進入 "等待燒錄模式" 而卡在 "Waiting for Bootloader"; 而在 OTG 槽, 這個重置是 "軟體重置 (Soft Reboot)", 效果與按 Ctrl+D 一樣而進入 MicroPython 互動執行環境.
沒有留言 :
張貼留言