如何在32位MCU平臺間移植

過去數年，關于單內核平臺標準化的討論不計其數，目的是讓設計從一家MCU供貨商的產品移植到另一家的產品變得容易。有趣的是，所有討論均從未涉及外設。然而，外設恰恰就是將應用從一家MCU供貨商移植至另一家的真正核心。

一切歸于外設

工程師在著手新設計之前，通常會先審視一下功能需求。希望系統做什么？用戶怎樣與之交互？ 諸如此類的一些問題。據此決定要采用什么電路以及控制這些電路所需的MCU片內外設。例如，工業級的HMI（人機界面）設備將需要支持LCD、按鈕和/或觸摸屏，與機器的通信、LED，以及揚聲器/蜂鳴器等。所有這些功能將需要MCU上的某些外設，如：CAN控制器用于通信、ADC用于觸摸屏及PWM定時器用于蜂鳴器等。外設具有的功能越多，所需的外部電路就越少。在某些情況下，還會減少需要編寫的代碼量。例如，使用特殊的蜂鳴器模式比為達到同樣目的而不得不設置PWM要簡單得多。

內核需求通常是顯而易見的。雖然內核很重要，但對于設計人員來說，關系不大。事實上，內核必須滿足兩個基本條件。速度是否足以執行創建最佳用戶體檢所需的所有軟件任務？ 是否能高效執行所有任務？只要滿足這兩點性能要求， 內核的類型無關緊要。

當然，內核還與固件/軟件相關。既有代碼是工程師必須考慮的一個問題。使用現成代碼能節省多少工作量？這個問題并非與內核直接相關，而與外設有關。因為大多數32位MCU代碼用C語言編寫，因此可重新編譯至任何內核。每家 MCU生產商的外設特性及編程模型均特定于其自家的產品，而與所采用的內核無關，這便是代碼難以移植的原因所在。

固件庫

為了給工程師提供便利，每家MCU生產商均提供一個固件庫，其中包含設置和使用各種MCU片內外設的代碼。由于不同廠家實現其外設的方式各不相同，甚至具有不同的特性，將應用程序從一種MCU移植至另一種MCU并非輕而易舉。

ARM一直以來都在為簡化應用程序的移植努力著，它定義了一種稱為Cortex?單片機軟件接口標準（CMSIS）的固件抽象層標準。采用Cortex-M系列內核的MCU生產商的固件庫均已采納了這一標準。遺憾的是，這個標準仍不能克服移植外設遇到的困難，對于變量或函數也未制定標準的命名約定。因此，將代碼從一種固件庫移植到另一種固件庫沒有捷徑，必須做大量工作。事實上，對于在ARM MCU供貨商之間移植應用程序，該標準幾乎沒有什么幫助。畢竟，對于MCU生產商來說，將應用程序輕而易舉移植到其他供應商的產品一點好處也沒有。

設計時考慮可移植性

由于MCU生產商不愿簡化其產品到其他供應商產品的可移植性，因此只能由設計工程師來使設計具有可移植性。通過實現一個抽象層，由該層創建硬件（即MCU外設）和應用程序代碼之間的標準編程接口即可實現這一點。至少可用以下兩種方法：

開發一個中介層或包裝器，從而實現在MCU生產商外設庫和您的代碼之間轉換。這可能是最快速高效的解決方案，但會在命令和數據路徑中添加較多代碼。

定義一個標準的函數和變量命名機制，并將其應用于所有外設庫。不必添加代碼，但卻很費時，具體取決于外設用法的復雜度。

實現移植性是個大工程，貫穿開發過程的始終。除了固件/軟件兼容性，還有引腳兼容的問題。將應用從一個MCU供應商的產品移植到另一個往往要重新布置PCB，而且可能還需要不同的外部器件，比如電容和穩壓器。

總結

無論使用何種內核，在32位MCU供應商的產品間移植均相當復雜。一切都取決于外設和相關的固件庫。每家MCU生產商均提供固件庫和應用筆記，盡力使設計過程盡可能地簡單。他們也將努力減輕其器件在其系列間移植的工作。但是他們卻不愿意使移植到競爭對手的解決方案變得過于容易。這是設計工程師要解決的問題，應該在每個項目開始時評估這樣做的成本和好處。
審核編輯：彭菁