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 時代，韌體工程師反而更自由了》

裡面會談到：

為什麼 AI 其實讓工程師更自由，

而不是更容易被取代。