當想要創建一個合適的專案，或是更進一步探索這個想法並將其產品化時，必須先考量要從哪種軟體框架入手。另外，還須分辨Espruino、Arduino、microPython、Segger embOS、Micrium uC/OS-II以及在uC/OS-II和uC/OS-III之間有那些區別。還要決定該採用初始成本較低的開放原始碼框架，或者選擇須要支付前期費用的商業解決方案來加速設計過程。
因此，這裡將討論在為微控制器(MCU)或無線微控制器專案選擇一套優秀的軟體時，所需要考慮的各種要素。
認識軟體框架 從專案中找靈感
所謂的「軟體框架」這個詞，本文將其解釋為「撰寫軟體的一種特定方式」。例如，Arduino提供撰寫程式碼的一種特定方式，允許軟體的片段可以跨越多個專案被重新使用。
軟體框架是由幾個不同的部分所組成，並由程式語言、應用程式介面(API)以及某些工具集的聯結等元件所定義。例如，在Arduino和Espruino的案例中，軟體框架可以被緊密地關聯到工具，或是在Micrium和FreeRTOS的案例中則是去耦合的(Decoupled)。
了解作業系統 分構運行步驟
該如何選擇一個軟體框架呢？首先，須要對一些作業系統、軟體組件等這些名詞解釋得更明確一點；作業系統(OS)核心需求在撰寫可執行特定需求的程式碼，藉由這些程式碼做出產品區隔。但是，仍然須要依靠軟體的其他部分共同規劃完成，例如ADC的驅動程式或SD卡的檔案系統堆疊，而這些軟體通常被稱為軟體元件。
做一個簡單明瞭的比喻，將軟體元件想像成磚塊，然後把作業系統視為水泥(圖1)。在作業系統中定義了磚塊的形狀以及磚塊間將如何互動作用，因此當加入更多元件到軟體時，依舊能繼續完美地協同工作。這聽起來相當不錯，但是否真的需要一個作業系統？畢竟增加作業系統，同時帶來了額外的負荷，不只會消耗數千位元組的快閃記憶體，為事件的回應增加延遲的時間，還須要花費些許的時間學習如何在作業系統環境中撰寫程式。
 |
| 圖1 可將軟體元件想像成磚塊，把作業系統視為水泥。 |
根據一般的經驗法則，如果選用的快閃記憶體容量是128KB或更高，並且需要通訊功能，便需要一些堆疊如通用序列匯流排(USB)、乙太網路、安全數位輸入輸出(SDIO)、控制區域網路(CAN)、Wi-Fi、藍牙低功耗(BLE)，因此從長期來看，使用作業系統還是比較好的選擇。
在作業系統中，最重要的其中一件事情便是排程器(Scheduler)。排程器是用在為可能會爭奪相同資源的不同任務，分配資源和處理時間的元件。在一般情況下，排程器有兩種作業的方式，而這正是即時(RT)在即時作業系統(RTOS)的意義所在。
即時意味著在一個固定的時間內，會有一個特定的任務一定可以被執行。假設得到一個須要處理的無線電封包，無論裝置目前正在做甚麼事，即時作業系統的核心會先離開其目前所執行的任務，先完成此高優先等級的任務。這種方式在處理器的利用率上並不是最有效率的，但在通訊堆疊中，或是在重視反應時間的應用中，例如馬達控制應用，這是有必要的。
商用vs.開放原始碼 方案選擇的兩難
如果已經想通是否須要採用即時作業系統，並開始收集軟體的需求。此時將需要一個USB堆疊和乙太網路堆疊，搭配外部媒介存取控制(MAC)/實體(PHY)驅動程式一起將裝置連接到網際網路。但是，該從哪裡開始呢？真的只須要為首選的微控制器下載最新的FreeRTOS範本和繼續下載開放原始碼軟體並放到裝置中就可以嗎？或者必須要尋求產品所需軟體的商業供應商，以獲得完整的軟體組合比較好呢？
為了做出更明智的決定，還須為選定的解決方案提出一個總體擁有成本(TCO)的概念。所謂的總體擁有成本包含的不僅是付出的軟體貨幣價值，還包括花費在尋找解決方案、收集不同的元件，並將不同的元件整合到專案以及開發、測試和生產的工作時間(圖2)。
 |
| 圖2 當決定要採用何種微控制器時，必須把一些隱形成本也納入考量。 |
在一般情況下，看到的是商業解決方案的總體擁有成本，將比自己整合開放原始碼元件的解決方案要來得更低一些。但既然是商業解決方案便涉及到初始成本，這些廠商通常要求在使用解決方案的前期，取決於自身所需要的元件，便必須先支付1萬到10萬美元之間的費用。相對地，下載FreeRTOS並開始整合自己的解決方案，在某些擁有密集資源的應用中，可節省金錢，但卻消耗更多的整體資源。
決定作業系統種類 選擇適用軟體框架
到此階段時，很多人可能都會認為：「只要給我一個可以讓我開始使用的框架就好了！」但可惜還沒那麼快，肯定有一些方案優於其他選項，但由於微控制器的應用非常多樣性，因此沒有那種單一且適用於所有需求的解決方案。
接下來，將針對主流作業系統和軟體框架深入探討：
慎選作業系統 商用抑或開放源碼
所有在這裡所提到的作業系統，都應該具有即時能力(RTOS)。說到商用解決方案的選擇，可從以下三項選擇其一：
這是在微控制器業界最流行的兩個即時作業系統，因其創新商業模式，Micrium允許下載完整的軟體套件進而開發，待創造營收時，才須要開始支付解決方案的費用。此外，也在安全關鍵系統中擁有重要的地位，並且其大部分軟體元件都已經通過認證。
嵌入式軟體市場的新進者，但這並不意味著他們是新手。該軟體產品已經開發了超過20年的時間，並已經使用在其硬體產品之中，對裝置的支援程度非常好，並配有一個完備的驅動程式庫。
由業界資深人士所創辦，該公司專注在所有關於性能的事物上，並擠壓出零組件中每一個時脈週期的效能。其通常被看作是作業系統中的勞斯萊斯，並已經有很多安全關鍵系統的相關認證。
若要從開放原始碼中找尋相關的解決方案，計有以下三種選擇：
FreeRTOS與Micrium uC/OS一樣，都是在業界最常被採用的即時作業系統之一。擁有龐大的社群，許多人都在為軟體做出貢獻，例如TCP/IP堆疊，但做為開放原始碼軟體，便意味著沒有公司會負責整合，因此需要更多的人力物力和時間來整合出一個完整的解決方案。也有一些公司在FreeRTOS的生態系統中，專門從事將差異化的軟體組件提供給那些需要整合協助的客戶。例如，Wittenstein High Integrity System就提供一個具有安全認證的FreeRTOS替換核心，稱為SAFERTOS，以及HCC Embedded提供可以用在任何即時作業系統的USB、乙太網路和檔案系統。
由安謀國際(ARM)負責整合工作，mbed OS解決一般在開放原始碼軟體容易所遇到的痛點。但因為仍然是處於萌芽階段，適合想對此系統有些貢獻者。
RIOT OS被冠以「物聯網中最佳作業系統」，以通訊概念為基礎所建立起來的作業系統。即使在面對困難的通訊問題時，RIOT OS仍然精簡且高效率操作。但即便如此，由於也還在積極發展的階段，撰寫程式時仍須花幾個小時來進行除錯。
依據專案發展 挑選軟體框架
有些作業系統的功能就像是將磚塊黏合在一起的水泥，會與發展框架緊密地結合在一塊，因此一般而言，不能將其只使用在專案的某一部分，必須圍繞著它來進行整個開發流程。這些框架往往是使用比C++更高階的語言所撰寫，通常可以在即時作業系統上運行。
mbed也出現在這裡，這時則是做為快速原型的專案。使用C++編寫，並對大多數微控制器和電路板有絕佳的支援，擁有一個龐大的元件函式庫和一個採用網頁架構的漂亮整合式開發環境(IDE)。在框架準備全面部署前，仍然需要一點成熟的時間，因而較適合硬體原型開發。
Espruino是在微控制器上運行的即時JavaScript解譯器。允許動態更改程式碼，甚至不需要燒錄微控制器便可以撰寫程式碼。但其開始量產之前，仍然需要一些時間來發展，因而較適用於硬體原型。此外，Espruino有成為一個不可忽視的軟體框架的巨大潛力。
microPython所能做的事與Espruino大致相同，差別僅在於其使用Python而不是JavaScript。其發展的概念是，讓開發者從產品開發的一開始到量產時，都有已預先編譯程式的支援，並使用C語言來撰寫時序關鍵的程式碼。其目前仍在開發當中。
microEJ是一個採用Java架構的框架，可輕鬆地為自身的裝置打造好看的圖形化應用程式，目前已經在許多智慧手表和一些物聯網(IoT)裝置中使用。
以目的為依憑 貫徹專案執行
如果想要著手進行裝置的開發，而無考慮量產事宜，諸如mbed和microPython這類的框架，便是入門的好方法。但若是要建立更大的部署，採用一個純粹的即時作業系統將會是更好的選擇。
但對於以工作時間取代金錢來做為軟體投資的公司，FreeRTOS或RIOT這類非商業解決方案便有其優勢。反之，要是能負擔得起前期投資者，Segger、Express Logic和Micrium等商業解決方案，將大幅降低軟體開發風險和縮短產品上市的時間。
在商業解決方案中，特別是如Micrium的穩定性和已認證的程式碼基礎、廣泛普及的部署、良好的零件支援、開放的原始碼，以及易於負擔的商業模式，更使其在商業解決方案中顯得特別突出。
(本文作者為Silicon Labs軟體開發產品經理)