程式鬼話｜韌體工程師可以怎麼問 AI
最近很多人在談 AI 寫程式， 但如果你真的在做韌體，很快會發現一件事：
AI 最好用的地方， 其實不只是幫你直接寫 code。 還有： 幫你理解系統。
下面是我自己比較常用的幾種方式。
■ 用 AI 快速理解規格書
很多 MCU 的文件都非常厚。
有時候一份 規格書就幾百、千頁。
如果直接從頭看，很容易迷路。
我通常會先問 AI：metad
例如：
MSP430FR2311支援幾組UART? 或者：
我要在MSP430FR2311上設定兩個500Hz的PWM要選哪隻腳位 AI 通常會先幫你整理一個大概的結構。
他會自己收尋，或是你可以餵他文件(但規格書通常很肥，若有簡易版的文件更好)
這時候再回去看規格書，
會快很多。
有時規格書也會寫錯，若發現AI邏輯怪怪的 還是要個地方合理懷疑一下
■ 用 AI 做跨平台理解
很多韌體工程師都會遇到一個問題：
換 MCU。
例如： STM32 → TI Microchip → NXP
很多晶片的概念其實差不多， 但名稱和設定方式都不一樣。
AI 在這裡很好用。
例如我會問：
以下是我TI MSP430FR2311的UART接收的function跟初始化 ….. …..
幫我整合到這個專案(Microchip ATtiny3217)
AI 不一定一次成功， 但可以省下很多自己慢慢轉移的時間。
通常都會有一些小地方出問題， 導致韌體編譯不過。
但基本再丟回去問AI， 都可以解完。
■ 用 AI 做跨語言理解
有時候問題不是 MCU。 而是語言。
例如： C/Python/JavaScript
同一個邏輯，不同語言寫法差很多。
AI 在這裡其實很方便。
例如我會問：
以下這段code是之前我用python寫出來的 功能是收尋藍芽裝置，並分析他的封包
….. (程式碼) …..
幫我轉成C語言 我要貼到韌體專案裡
開發藍芽的韌體，我常常會用python來開發驗證程式協助我開發跟確認藍芽封包
G蛋也會自己用AI開發Android跟IOS的應用程式來驗證韌體
G蛋也會用python寫IOT後台程式(以前寫的時候沒AI)，所以我算是個語言都會碰到，現在有AI真的是方便很多
■ 用 AI 整理 Debug 思路
很多韌體問題其實不是語法錯。
而是系統行為。
例如：
● 偶爾重開機
● 某些時候延遲突然變大
● 某個事件偶爾沒被處理
這時候我有時會把狀況描述給 AI：
系統偶爾重開 可能有哪些原因？ AI 通常會幫你列出幾個方向：
● interrupt 卡住 ● 記憶體問題 ● watchdog 觸發
這其實很像一個 可以隨時討論問題的工程同事。
build code fail我現在都丟給AI處理 自己都懶得去找原因
其實就像是跟同事討論除錯，只是你不用等你同事有空，AI可以一直陪你(付費版)
■ AI 是工具，不是工程判斷
AI 確實可以幫你加速很多事情：
查資料 理解平台 整理 code
但有些事情
例如： interrupt 要怎麼設計 資源要怎麼分配 系統流程怎麼安排 這些其實都是工程判斷。
AI 可以幫忙。 但可能最後真實是設計的太複雜， 韌體編譯不過。
或是生了一堆糞code， 影響資源分配， 引出其他問題。
所以判斷AI給你的， 設計方式邏輯。
我們要自己能判斷， 能不能用。
■ 延伸閱讀
如果你對這個議題有興趣，
我在 Medium 另外寫了一篇
比較偏觀點的文章：
《AI 時代，韌體工程師反而更自由了》
裡面會談到：
為什麼 AI 其實讓工程師更自由，
而不是更容易被取代。 https://vocus.cc/article/69ac5073fd89780001f14f6b
AI 可以幫你查規格、轉語言、補程式與整理除錯方向，但裝置身份、資料解析、歷史、離線補送、API 與 APP 要怎麼分工，最後仍然需要工程師自己做系統判斷。
如果你已經有程式或韌體基礎，想從單點開發升級成完整 IoT Server 能力，可以接著看這門課提供的架構、程式基底與 Labs：