32位元微控制器的應用可攜性—現實還是神話?

簡介

2008年11月，ARM®宣佈推出Cortex™ 微控制器軟體界面標準（Microcontroller Software Interface Standard， CMSIS）。他們聲稱，對於新設備的軟體發展專案或將現有軟體在不同晶片廠商的基於Cortex-M 的微控制器之間轉移時，這項標準可降低軟體設計成本。這聽起來很不錯，但事實確實如此嗎？本文將對這些說法進行研究以確定其真實度。我們先回顧一下典型微控制器的元件，然後觀察在典型週邊韌體庫上添加一個抽象層能夠實現或無法實現什麼樣的結果。

根據ARM所言，CMSIS 是「適用於 Cortex-M處理器系列的與廠商無關的硬體抽象層。CMSIS為不同晶片廠商和中介軟體供應商的處理器提供了簡單一致的軟體界面，這簡化了軟體重複性，縮短了開發人員對於新微控制器（MCU）的學習過程以及新設備的上市時間。CMSIS的問世使晶片廠商可將資源集中在突出其產品的週邊功能上，無需在對微控制器進行編程時保持各自不相容的標準。」

為了解本文背景，我們需要瞭解一下微控制器是如何設計的。微控制器是高度整合的系統解決方案。實際上，可將其稱為晶片系統（System on Chip， SoC）。與任何SoC 一樣，該晶片的功能是通過與CPU核心整合在一起的週邊硬體進行定義的。當然，CPU核心的性能和架構決定了可在晶片上執行的程式碼種類，但晶片與系統其他部分的互動要通過週邊來進行。微控制器週邊的靈活性使其成為獨特的SoC。由於這種靈活性，微控制器的設置和控制可能相當複雜。在實際進行任何操作前需要設置大量暫存器。為幫助設計人員完成此任務，晶片廠商提供了可簡化程式碼開發的韌體庫。這些韌體庫包括了用於設置所有暫存器以及控制微控制器各個部分所必需的所有函數。由於各個晶片廠商的微控制器具有不同的週邊和功能，因此每個廠商都會提供一個獨一無二的韌體庫，以使其產品在競爭對手中脫穎而出。我們來看一下微控制器的哪些部分形成了各廠商之間的區別。

系統架構

每個微控制器製造商對實現整體系統整合（即系統匯流排、時脈鏈和記憶體）都有自己的方式，即使CPU核心相同時也是如此。憑藉這些實現方案，各製造商建立了各自的優勢，使自己的微控制器成為更適合客戶的解決方案。讓我們來研究每一個系統組成：

l   時脈鏈提供系統的時脈訊號，以協調所有其他功能的時序。時脈鏈旨在優化系統速度並使系統實現經濟運行。晶片所含的功能和週邊以及晶片旨在解決的問題直接影響著時脈鏈的結構。因此，各家製造商的時脈鏈結構不盡相同。此外，在進行任何操作前，都需要使用適當的值對時脈鏈暫存器進行規劃。

l   系統匯流排的架構定義了所有 MCU功能的整合方式。有些製造商會使用一條或多條週邊匯流排，具體情況取決於所整合的週邊。  所有這一切都會改變需要設置的暫存器的種類和數量，以盡可能利用所有可用的功能。

l   儘管所有微控制器都同時具有非揮發性記憶體（如快閃）和易揮發性記憶體（如 SRAM），但每家製造商的具體整合方式都不相同。有些製造商將快閃記憶體儲存器直接連接到核心與匯流排矩陣，而其他一些製造商則將其連接到系統匯流排或匯流排矩陣。   RAM有時會分布於兩個獨立的記憶體組，以允許核心和週邊同時存取。這些不同的記憶體結構可能會影響程式碼的編寫方式，當設計人員從一個製造商轉到另一個時，這通常會對應用程式的效能產生直接影響。

週邊

每個製造商都在其微控制器上提供了一系列標準和專用的硬體週邊。

l   標準週邊提供通用功能，例如通過 UART或 SPI實現串列通訊。這些週邊也可以是計時器或PWM。標準週邊在所有MCU製造商的產品中都很常見，但它們可能會有某些增強功能，為客戶提供更大的靈活性和 /或更多功能。與微控制器的任何其他部分一樣，標準週邊有自己的暫存器。儘管標準週邊的功能可能相同，但幾乎每個製造商實現標準週邊的方式都不相同，進而導致各個MCU廠商產品的暫存器結構也各不相同。

l   專用週邊適用於某些應用獨有的特定任務。 例如，無刷馬達控制 PWM、用於音頻重播的 I2S或加密 / 解密。 根據複雜性的不同，這些專用週邊可能只有幾個暫存器，也可能有 30個以上的暫存器。

韌體庫

如前文所述，  每個MCU 製造商都有自己的週邊韌體庫，用以幫助客戶實現設計並迅速進入雛型階段。韌體庫包括由晶片製造商開發的程式碼，用於設置晶片各部分中 （如時脈、匯流排和週邊）的所有暫存器。提供可輕鬆設置各個暫存器的函數叫用，以助於開發人員專注於輸入應用程式所需的參數。函數負責將這些參數寫入相應的記憶體位置。通過使用韌體庫中的函數，開發人員不必瞭解所有暫存器及其位置便可使晶片正常運行。這樣可將節省下的時間集中在更特定於應用程式的任務上，例如為應用程式開發適當演算法。

週邊韌體庫還包括用於控制週邊（也通過暫存器完成）的函數。同樣，開發人員無需關注暫存器的位元和單元，只需為其程式碼選擇正確的函數。

抽象層可應用到週邊韌體庫以幫助簡化程式碼開發，這正是 CMSIS發揮作用的地方。但還有一個疑問：這是否會產生程式碼相容性問題？

事實觀察

現在我們已清楚地瞭解各個微控制器製造商都能提供什麼，我們可以看一下抽象層能為設計人員做些什麼（如果有的話）。 首先，我們來看 CMSIS聲稱所能提供的功能，同時應記住前文所述的系統架構、週邊和韌體庫。

CMSIS 版本 1.3

1.核心週邊存取層：包含用於存取核心暫存器和週邊的名稱定義、位址定義和輔助函數。它還定義了一個用於 RTOS核心與設備無關界面，   其中包含除錯通道定義。

2.這些軟體層由晶片合作夥伴通過以下方式進行擴展：

a)設備週邊存取層，   提供所有設備週邊的定義；

b)用於週邊的存取函數（可選）： 提供用於週邊的附加輔助函數。

仔細閱讀此說明後，我們可以看到 CMSIS提供了一種通用語言，通過它可描述 MCU 的不同元件。

接下來，我們看一下兩個不同的 「晶片合作夥伴」（使用 ARM Cortex-M處理器核心的 MCU製造商）所生產的 MCU中包含的部分功能。

表1：

顯而易見的是，儘管這兩個32位元MCU製造商都使用Cortex-M3核心，但主要功能仍有區別。表中列出的功能是微控制器最標準的功能，即便如此它們仍有不同。這意味著，即使這兩個製造商使用相同的核心，也需要對軟體進行調整才能運行最基本的程式，例如I/O反向或使用UART。如果不進行一定程度的程式碼重寫，而只是對基本參數進行調整，則無法在A和B之間移植軟體。

根據定義，CMSIS提供了用於存取核心元素的標準化語言，但晶片合作夥伴/MCU製造商必須提供自己的韌體才能與設備週邊進行互動。任何MCU的兩個最基本功能都會涉及（1）如何使系統架構與週邊相關聯，（2）如何設計MCU週邊的結構以實現所需控制和/或功能。這是製造商提供的韌體庫能幫助解決的問題，也是程式碼相容性問題的核心所在。向這些韌體庫添加抽象層有助於提高可攜性，但無法解決兩個MCU之間的所有功能差異。任何高階週邊功能都無法移植到不存在該功能的另一MCU上， 無論是否有抽象層。微控制器製造商實現的這些增強功能有助於使 MCU從競爭對手中脫穎而出，並幫助設計人員改進解決方案。但這會導致程式碼不相容。

細節討論

抽象層的概念與作業系統的設計有關。它創建了一種操作系統存取處理器（正在運行該作業系統）的標準方式，並且可以簡化更改處理器的過程。必須知道的是，處理器（微處理器元件，MPU）是系統元件整合度最低的核心，這使得各製造商的處理器的相似度要遠大於MCU。此外，處理器上運行的程式碼是軟體，而不是韌體。也就是說，程式碼通常不控制任何硬體。另一方面，微控制器是晶片系統，這意味著核心與整合週邊之間的聯繫更為緊密。對於MCU，如果要運行RTOS，則抽象層的概念最有意義。另一方面，使用 RTOS 會使應用程序程式碼與硬體分離，進而去除微控制器應用中常見的嚴格控制。

如果某個應用程式正在RTOS上運行，則可將其移植到任何支援該特定RTOS的微控制器。在運行Micrium µCOS II的Cortex-M3微控制器上開發的程式碼可移植到基於

MIPS M4K的微控制器，因為µCOS II在該平台上也可以運行。應用程式與硬體隔離，並且只要程式碼的新部分具有所有相關功能，移植就應該相對很容易。

但在另一方面，如果沒有RTOS，情況就不是這樣了。如前文所述，每個製造商都會以自己的方式整合核心、記憶體和週邊。其中一些差異使得創建一個適用於不同製造商的標準抽象層非常困難，並且還有一個問題：他們想讓這變得簡單嗎？

在大多數微控制器應用程式中，在核心上運行的程式碼與硬體週邊之間的牢固連接非常關鍵。實際上，該連接使得創建任何種類的標準抽象層（可在不同製造商的MCU間轉換）都很困難。抽象層可以對標準功能（例如UART或SPI）有所幫助。但即使是UART，如果原始程式碼對9位元模式的UART使用了韌體庫函數，則在新MCU沒有9 位元模式的UART（即沒有用於此用途的庫函數）時，必須重寫程式碼。更複雜的是，在大多數情況下設計人員不是通過標準函數來定義MCU的值，而是通過其獨特的週邊開發最優解決方案。例如，如果能以更高的精確度和安全性控制電機，您將從競爭對手中脫穎而出。 專用韌體庫正是在這裡起作用，而使事情變得更加複雜。

專用週邊和韌體庫

週邊韌體庫支援指定微控制器上的所有週邊，包括標準週邊和專用週邊。但為了更好地支援客戶，某些製造商還為特定應用（如電機控制、圖形和網路等）提供專用韌體庫。這些專用韌體庫總是專有的，在許多情況下包含無法在製造商之間轉移的知識產權。在大多數情況下，所涉及的應用程式都很複雜，設計人員不會願意從頭開發應用程式。此外，製造商通常將其週邊支持的所有特殊功能都整合到庫中，在不對程式碼進行較大修改的情況下無法移植到其他製造商的MCU上。

可攜性

在我們的範例中，廠商A和B的微控制器都使用了ARM Cortex-M3核心，並且都具有符合CMSIS標準的韌體庫。這是否意味著他們的庫（例如電機控制庫）可以互相移植？

其實不見得。這兩個製造商對週邊和韌體採用了完全不同的方法。廠商A使用專用演算法庫（可能由多人經過數年開發而成）來最高效地利用其微控制器上的專用週邊。而廠商B則專注於使用更通用的週邊並構建通用週邊庫，對於特定應用則使用範例程式碼和應用筆記進行說明。

這兩種完全不同的方法使得在這兩個製造商的MCU之間移植程式（例如電機控制副程式）非常困難，儘管它們使用了相同的核心。此外，庫函數的命名也不相同，這意味著用戶必須重寫程式碼中的所有庫函數叫用，並且要弄清將哪些變數和值提交給函數。這完全不是所謂的可攜性。

關注重點

設計人員關注的重點是開發特定最終用途程式碼時的速度、效率和可靠性。廠商A和B採用不同的方法來達到這些目標。廠商A使用基於專用硬體的方法，而廠商B的方法更加專注於通用硬體。廠商A針對特定應用提供了經過潛心開發的專用庫，以最大限度地利用其微控制器的功能。而廠商B只提供基本構件，讓開發人員構建自己的解決方案。

在速度和可靠性方面，廠商A的方法佔據優勢，因為很大一部分的應用程式開發工作已經完成且經過測試，並整合在其韌體庫中。至於效率方面，廠商A也有明顯優勢，因為其軟體專為其硬體進行了優化。但是，這些優勢沒有一項與CMSIS或可攜性有關。對兩個廠商的MCU所進行的比較不應基於抽象層，而應該著重於使用某個MCU實現其預期最終用途的順利程度。那些針對特定微控制器開發了定制韌體庫的製造商具有明顯優勢。正在尋找控制器的設計人員可將精力放在比較特定演算法對其需求的適用程度上。儘管CMSIS這樣的API對於隱藏硬體複雜性（例如針對 RTOS）很有用，並在二者之間形成無縫界面，但無法保證軟體在各個製造商間的可攜性。

宗旨

要考慮的最後一點是微控制器的基本宗旨。開發MCU的目的是為日常設備的控制帶來可編程性和靈活性。通過整合CPU、非揮發性記憶體和週邊（類比和數位），這一目標已經實現。無需那些使電腦變得通用的高級功能，微控制器可充分利用少量硬體來實現所需功能。專用於MCU特定週邊結構的韌體庫大幅減少了開發應用程序所需的時間和工作量。如前文所述，向這些韌體庫添加抽象層有助於改進開發過程，對於跨專案重複使用程式碼也更為簡單，但要付出一定代價。使用抽象層時存在程式碼變和效能下降問題。添加抽象層使微控制器更類似於計算機。這在某種程度上與形成微控制器基本宗旨的特質相反。實際上，它使開發過程更為複雜，因為它要求應用程式遵守CMSIS的特定語言要求，而且無法保證程式碼相容性。

參考文獻

1 www.arm.com/products/processors/cortex-m/cortex- microcontroller-software-interface-standard.php

2 http://www.onarm.com/download/download395.asp

請注意以下有關 Microchip 設備程式碼保護功能的要點：

l   Microchip 的產品均達到 Microchip 資料手冊中所述的技術指標。

l   Microchip 確信：在正常使用的情況下，Microchip 系列產品是當今市場上同類產品中最安全的產品之一。

l   目前，仍存在著惡意、甚至是非法破壞程式碼保護功能的行為。就我們所知，所有這些行為都不是以 Microchip 資料手冊中規定的操作規範來使用 Microchip 產品的。這樣做的人極可能侵犯了知識產權。

l   Microchip 願與那些注重程式碼完整性的客戶合作。

l   Microchip 或任何其他半導體廠商均無法保證其程式碼的安全性。程式碼保護並不意味著我們保證產品是 「牢不可破」的。

程式碼保護功能處於持續發展中。 Microchip 承諾將不斷改進產品的程式碼保護功能。任何試圖破壞 Microchip 程式碼保護功能的行為均可視為違反了 《數位設備千年版權法案 （Digital Millennium Copyright Act）》。如果這種行為導致他人在未經授權的情況下，能存取您的軟體或其他受版權保護的成果，您有權依據該法案提起訴訟，從而制止這種行為。