這三年里我們一直在做一件事：

• 把 MCU 工程的初始化配置做成圖形化
• 并且支持多個 MCU 原廠、多個內(nèi)核

很多工程師第一反應(yīng)會想到 STM32Cube，這個類比并不奇怪。
但真正開始支持多廠商之后，我們發(fā)現(xiàn)一個有點(diǎn)反直覺的事實(shí)：

當(dāng)圖形化配置從單一廠商擴(kuò)展到多廠商，
工具本身反而不是最難的部分。

圖形化工具，本身并不神秘

從功能上看，一個 MCU 圖形化配置工具無非是：

• 時鐘樹配置
• 引腳復(fù)用
• 外設(shè)參數(shù)
• 工程生成

這些能力在單一廠商體系里，已經(jīng)被反復(fù)驗(yàn)證過。

真正的復(fù)雜性，藏在更底下

當(dāng)開始支持不同 MCU 廠商之后，問題很快出現(xiàn)：

• 不同廠商對時鐘系統(tǒng)的抽象差異極大
• GPIO / 復(fù)用規(guī)則無法直接套用
• 外設(shè)初始化順序、依賴關(guān)系各不相同
• 底層 SDK 的組織方式完全不一致

這時候會發(fā)現(xiàn)：

圖形化界面只是表現(xiàn)層，
真正復(fù)雜的是芯片初始化能力該如何被描述。

真正的瓶頸：芯片配置模板

在支持多廠商的過程中，我們反復(fù)遇到同一個問題：

• 每增加一家廠商
• 最費(fèi)精力的不是 UI
• 而是如何把這家廠商的 MCU 初始化能力
  放進(jìn)一套統(tǒng)一、可維護(hù)、可擴(kuò)展的配置模型里

如果只是跑一個工程，寫專用代碼并不難。
但如果目標(biāo)是：

• 能被工具識別
• 能被校驗(yàn)
• 能被復(fù)用
• 能長期維護(hù)

那就必須有一套清晰、穩(wěn)定的配置模板規(guī)則。

拋給大家一個問題

在多廠商 MCU 的圖形化配置場景下：

• 決定工具能否規(guī)?；?/li>
• 會不會其實(shí)是芯片配置模板本身？

后面幾篇，我會圍繞這個問題繼續(xù)展開。

審核編輯 黃宇