最近很多人在談 AI 寫程式，
但如果你真的在做韌體，很快會發現一件事：
AI 最好用的地方，
其實不只是幫你直接寫 code。
還有：
幫你理解系統。
下面是我自己比較常用的幾種方式。
■ 用 AI 快速理解規格書
很多 MCU 的文件都非常厚。
有時候一份 規格書就幾百、千頁。
如果直接從頭看，很容易迷路。
我通常會先問 AI：
例如：
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 其實讓工程師更自由，
而不是更容易被取代。
