Embedded

從一句抱怨開始 第三天了。 這塊點心小板真的夠硬。Claude Code 在大放送期間讓我能一直衝，結果還是頂到了用量限制。早上後來去參加研討會，腦子裡一直在想一件事： 我花了多少時間在 copy/paste？ JTAG 的 call stack、SWD 的暫存器狀態、Serial Console 的 log——一段貼過去，AI 給建議，我改一下 code，重新 build、flash、再抓 log，再貼回去。來來回回。有時貼錯視窗，有時貼漏了關鍵的那幾行。 跟以前純靠自己 debug 比起來，確實快很多。但還是不夠快。Bug 像俄羅斯套娃，抓掉一層，裡面還有一層。每一次的「這次應該好了」到「怎麼又掛了」的迴圈，都讓人想把鍵盤推開。 所以我在想，如果能消除人為因素的話呢？ 一個想法：給 AI 眼睛跟手 問題說清楚了就好解決。 我需要的不是更聰明的 AI，而是讓 AI 能自己看、自己動、自己驗。 不再是我充當「人肉資料傳輸管道」，把硬體的訊號用眼睛看完之後再貼給 AI，而是讓 AI 直接接上硬體的感知介面，取得第一手的訊號，做出判斷，然後直接驅動工具鏈——build、flash、reset——再自己確認結果。 這個想法就是 AI-HIL（AI Hardware-in-the-Loop）。 Giving hardware the soul of AI, realizing automated closed-loop development in the physical world. AI-HIL 是什麼 AI-HIL 把 Claude Code 從「code 產生器」升級成「系統級工程師」。 透過 Model Context Protocol (MCP)，Claude Code 連接到實體硬體，獲得三種能力： 感知（Perception）：讀 Serial log、JTAG call stack、電流波形、Camera 畫面 行動（Action）：Build/Flash firmware、硬體 Reset、電源控制 閉環驗證（Closed-Loop Validation）：自動確認修復是否有效，記錄 bug 模式 換句話說，AI 不再只是坐在我旁邊出主意，而是能自己上工的 AI Employee。 ...

我的一位同事在測試 GStreamer 的 alsasrc 與 osssrc 插件時發現，alsasrc 消耗了相當驚人的 CPU 資源（在我們使用的晶片上約占 16%）。他詢問我，為何晶片供應商提供的測試工具卻能維持極高的效率（約僅占 1~2%）。這巨大的效能差距引起了我的好奇，我決定深入研究原因。 經過數小時的調查，我發現當參數設定為「非阻塞模式 (non-blocking mode)」時，該插件可能會在 While 迴圈中導致忙碌等待 (busy wait)。我對程式碼進行了簡單修改並重新執行，結果 CPU 使用率降低到 12%。雖然略有改進，但我依然感到有些沮喪。 於是，我開始嘗試不同的參數組合，因為我同事發現了 alsasrc 與測試工具間的三個差異點： alsasrc 設定為「非阻塞模式」，而測試工具為「阻塞模式 (block mode)」。 alsasrc 的聲道設定為 1，而測試工具設定為 2。 測試工具限制了緩衝區大小 (buffer size)，而 alsasrc 沒有這項限制。 針對第一點：我原以為非阻塞模式應該更有效率，但關鍵在於必須改善其忙碌等待的機制。 針對第二點：這非常奇特，因為當我在 alsasrc 插件將聲道數設定為 2 時，CPU 使用率竟然大幅降低。這讓我開始懷疑這是否與 I2S 匯流排的特性有關。我在網路上搜尋，並未發現任何資料指明「當音訊匯流排為 I2S 時，必須在 GStreamer 的 alsasrc 插件中將聲道參數設為 2」。稍後我會進一步確認此現象。 針對第三點：我認為限制緩衝區大小以優化效能是合理的做法。