如何挑擇適合 IoT 的 RTOS 和微控制器平台

開發物聯網 (IoT) 元件可能比許多開發人員或公司所想的更具挑戰性。光是將嵌入式系統連線到雲端的動作，就會大幅提高系統的時序複雜性。而時序複雜性的增加，意味著開發人員需使用更好的方法來管理軟體，以決定要執行的程式碼以及執行時機。要避免編寫自訂的排程器，或是以裸機形式處理時序，最好的方法是採用即時作業系統 (RTOS) 來協助管理時序的複雜性。

目前使用 RTOS 有個難題在於，許多開發人員以前習慣沒有作業系統 (OS) 的裸機環境，因此要挑選適合特定應用的 RTOS 並不容易。若在網路上快速調查 RTOS 市場，便會發現目前市場上有百餘種 RTOS 可供開發人員使用，從開放的原始碼到通過認證的商用 RTOS 都有。那麼，該如何挑選 RTOS 並開始使用呢？

本文將介紹如何評估哪個 RTOS 最適合您的應用，並查看 STMicroelectronics 和 Renesas 推出的入門級開發平台。

挑選 RTOS 時應考量的因素

即時作業是開發人員構建應用程式碼的基礎。為了確保在穩固且可靠的基礎上構建應用，選擇正確的 RTOS 極為關鍵。不過，在絕大多數情況下，挑選 RTOS 時僅僅考量單一參數：成本。

雖然成本是重要的考量因素，但不應是唯一的因素。如果開發團隊發現其所選的 RTOS 很難連接、實作或是缺乏支援，很容易就會花費比商用 RTOS 多十倍的成本，更別說因此而損失的專案時間了。一般來說，挑選適合應用的 RTOS 時，開發團隊有八種不同類別的因素需列入考量，其中包括：

• 法律責任與風險
• 效能
• 功能
• 成本
• 生態系統
• 中介軟體
• RTOS 廠商
• 工程偏好

在各個類別裡，可能要針對每款 RTOS 評估多項條件。舉例來說，在法律責任類別，團隊可能需考慮下列因素：

• RTOS 侵權責任
• 賠償
• 保固
• 從法律角度審查 RTOS 的必要性

在效能類別，開發人員可能需考慮下列因素：

• 可執行記憶體覆蓋區
• RAM 覆蓋區
• 最高程度的確定性
• 執行階段效率

開發與執行團隊可檢視每個主要類別，以決定要用哪個條件來評估 RTOS。一旦設定好條件，便能使用 Kepner-Tregoe (KT) 矩陣評估多款不同的 RTOS。這是一個理性的決策模型，可協助收集、優先排序和評估資訊，並將重點放在風險的評估和優先級別上。此模型可消除決策過程中的個人偏見，有助於達成最佳可行的選擇，並將負面影響降至最低。讓我們看看如何使用 KT 矩陣來挑選 RTOS。

使用 KT 矩陣挑選 RTOS

用來挑選 RTOS 的 KT 矩陣可依照圖 1 和圖 2 所示進行設置。其概念是，針對每個類別，我們找出所需的挑選條件，並將這些條件列入單一欄位中。我們可針對各項條件決定權重，即針對該條件對我們而言的重要性進行評分，分數為 1 至 5，其中 5 代表極為重要 (例如成本)，而 1 則沒那麼重要 (例如法律責任)。接著每位團隊成員皆可就各項條件對每款待評估 RTOS 的重要性進行評分，並將結果填入各欄位中。然後就可針對各項條件進行加權、加總，得到無偏頗的數字結果。最高數值的 RTOS 便是最符合條件的 RTOS。

圖 1：用於挑選 RTOS 用的 KT 矩陣上半部分，包含對責任風險、RTOS 效能、功能與成本的評估。(圖片來源：Beningo Embedded Group)

圖 2：用於挑選 RTOS 用的 KT 矩陣下半部分，包含對生態系統、中介軟體、廠商與業務的評估。(圖片來源：Beningo Embedded Group)

圖 1 和圖 2 列出相當多待評估的條件，數量可能超出絕大多數開發團隊有興趣評估的範圍，但只要將權重設定為 0，或在試算表中隱藏該列，即可輕鬆消除條件數量。

展開 RTOS 開發的平台

開發人員在評估 RTOS 時可能會遇到一個難題，就是判斷 RTOS 是否符合效能與能力需求。在許多情況下，開發人員在進行深入評估，並實際使用 RTOS 之前都無從得知是否符合需求。其實有種簡單又經濟的 RTOS 評估和測試方法，那就是運用既有的 RTOS 開發平台。讓我們看看幾個可支援常見開放原始碼 FreeRTOS 和 Express Logic 的 ThreadX 作業系統平台。

首先要介紹的是 STMicroelectronics 的 STM32Cube 平台。STM32Cube 平台支援 FreeRTOS，是 STMicroelectronics 的 STM32CubeMx 和 STM32CubeIDE 開發環境的一部分。這些工具能讓開發人員輕鬆啟用 FreeRTOS，只需勾選 FreeRTOS 方塊即可，然後使用 FreeRTOS 組態工具，設定裡面的所有組態值即可。此方法能讓開發人員迅速上手並執行 FreeRTOS，如此即可開始評估其功能及效能特色。

在 STMicroelectronics 工具鏈中，有多種不同的開發板可供選擇。其中有一款開發板已歷經實際考驗且在這幾年廣受歡迎，那就是 STM32F429 探索板 (STM32F429I-DISC1) (圖 3)。

STM32F429 採用 Arm^® Cortex^®-M4 處理器，時脈速度高達 168 MHz。此微控制器支援 2 MB 的快閃記憶體和 256 KB 的 SRAM，其程式碼和記憶體足以開發相當先進的應用程式。此開發板還具有 LCD、多個 LED 及可擴充的 I/O。

圖 3：STM32F429I 探索板是低成本的開發板，採用 Arm Cortex-M4 處理器，對於想要評估 RTOS 的開發人員來說，可提供充裕的處理能力。(圖片來源：STMicroelectronics)

若開發人員要使用的 RTOS 型 IoT 邊緣裝置可能還需要執行機器學習作業，STM32F7 探索板 (STM32F746G-DISCO) 會是更好的選擇 (圖 4)。STM32F7 探索板採用 Arm Cortex-M7 處理器，其具有快取空間、時脈速度高達 216 MHz，並含有 1 MB 的快閃記憶體和 340 KB 的 SRAM。此開發板還包括 4.3 吋的 480 x 272 像素顯示器、乙太網路、SD 插槽、USB、麥克風和揚聲器接頭等等。

圖 4：STM32F746G 探索板是一款低成本的開發板，採用 Arm Cortex-M7 處理器，不僅能讓開發人員評估 RTOS，還可執行其 IoT 邊緣裝置所需的任何機器學習推論功能。(圖片來源：STMicroelectronics)

最後一個應考慮的開發板是 STM32L0 Nucleo 板 (NUCLEO-L073RZ) (圖 5)。STM32L0 Nucleo 板採用 Arm Cortex-M0+，其設計可達到最低可行的能耗，因此非常適合以電池供電的低功率 IoT 邊緣裝置。STM32L0 微控制器的時脈速度高達 24 MHz，還具有 192 KB 的快閃記憶體與 20 KB 的 SRAM。此開發板的特性相當符合 RTOS 運行的最低要求。此開發板採用裸板設計，只有一個使用者開關和一個 LED。

圖 5：NUCLEO-L073RZ STM32L0 開發板採用 Arm Cortex-M0+ 處理器，能為低功率裝置提供高效能。(圖片來源：STMicroelectronics)

第二個要介紹的平台是 Renesas Synergy™ 平台。在嵌入式產業中，此平台在嵌入式產業具有獨特地位，因為隨附豐富的第三方軟體以及著名供應商提供的開發工具。

例如，如果有人使用 STMicroelectronics 開發板，而且想要將 Express Logic 的 ThreadX RTOS 搭配 IAR Systems 的 Embedded Workbench 編譯器與開發環境使用，就需要從 IAR 取得編譯器、從 Express Logic 取得 RTOS，還要購買授權才可使用。但是，開發人員只需購買 Renesas Synergy 平台中的某個微控制器，就能自動取得這些工具以及搭配的 RTOS，更可取得其他中介軟體。

若開發人員想在高階處理器上測試 ThreadX，Renesas Synergy 的 SK-S7G2 開發板 (YSSKS7G2E30) 是絕佳的選擇 (圖 6)。SK-S7G2 採用 Arm Cortex-M4 處理器，時脈速度達 240 MHz，並具有 3 MB 的快閃記憶體和 640 KB 的 RAM。此開發板的配備相當齊全，包括 LCD、大量 LED、I/O 擴充、CAN、PMOD 擴充，並可輕鬆存取序列埠及額外的 I/O。

圖 6：Renesas Synergy 的 SK-S7G2 開發板隨附商用開發工具，包括 Express Logic 的 ThreadX RTOS。(圖片來源：Renesas)

另一款可用於測試 ThreadX 的開發板是 Renesas Synergy 的 TB-S5D5 (YSTBS5D5E10) (圖 7)。TB-S5D5 板是低成本的開發板，內含 Arm Cortex-M4 處理器，時脈速度為 120 MHz，並具有 1 MB 的快閃記憶體和 384 KB 的 SRAM。為了將成本降到最低，此開發板僅含有最低限度的功能，僅具有使用者按鈕、電容式觸控功能和一個 LED。

圖 7：Renesas Synergy 的 TB-S5D5 開發板為開發人員提供 1 MB 的程式碼快閃記憶體以及 384 KB 的 SRAM，可用於測試 ThreadX。(圖片來源：Renesas)

對開發人員來說，特別是對 IoT 應用感興趣的開發人員，其他值得關注的選項還有 Renesas Synergy 的 AE-Cloud1 IoT 套件 YSAECLOUD1 (圖 8)，以及 Renesas Synergy 的 AE-Cloud2 蜂巢通訊 IoT 套件 YSAECLOUD2 (圖 9)。

Synergy Cloud1 IoT 套件可讓開發人員透過 Wi-Fi 連接到雲端，而 Cloud2 蜂巢通訊套件還可讓開發人員透過蜂巢網路進行連線。這兩款開發板都採用 S5D9 處理器，並具有板載感測器和 LED，可從雲端進行監測和控制。這些套件還隨附 ThreadX 等預載軟體，因此開發人員可使用其本身的 RTOS 測試整個連線解決方案。(這有助於開發人員評估上述 KT 矩陣的中介軟體部份)。

圖 8：Renesas Synergy 的 AE-Cloud1 IoT 套件，是專為 IoT 裝置設計的開發板，可透過 Wi-Fi 連接雲端。此套件可控制 LED 並監測來自 Amazon Web Services (AWS) 或 Microsoft Azure 等雲端供應商的感測器數值。(圖片來源：Renesas)

圖 9：Renesas Synergy 的 AE-Cloud2 Cellular 蜂巢通訊 IoT 套件是專為 IoT 裝置設計的開發板，可透過 Wi-Fi 或蜂巢網路連接雲端。此套件可控制 LED 並監測來自 AWS 或 Azure 等雲端供應商的感測器數值。(圖片來源：Renesas)

針對上述平台，有個重要事項必須注意：在平台上評估 RTOS 時，請確保是以同等的條件進行比較。例如，若在時脈速度為 168 MHz 的 STM32F429 探索板上評估 FreeRTOS，則請確保使用相同的開發板，或時脈速度相同的開發板來評估其他 RTOS。

RTOS 的使用訣竅與秘訣

每款 RTOS 都有自己的「訣竅與秘訣」，但有幾條經驗法可通用於各款 RTOS：

• 靜態分配任務和 RTOS 物件。若以動態方式分配任務和物件，需要使用記憶體分配程式 (malloc())，而這具有非確定性，可能會造成堆積碎片問題，進而導致效能低落，在最糟的情況甚至會造成系統當機。
• 根據應用需求更改預設堆疊大小；對大多數任務而言，許多 RTOS 提供的預設堆疊值都過大，這會導致 RAM 的浪費。請手動設定預設堆疊大小，同時確保按照每項任務的功能和需求來調整堆疊大小。
• 從任務調用的函數應可重入。這可確保從多個任務調用函數時，若某個任務被更高優先順序的任務中斷，就不會有其他任務資料受損的風險。
• 儘量使用記憶體區塊集區 (若有)。記憶體區塊集區是具有確定性行為的記憶體集區，可在執行階段使用，能對記憶體進行動態分配。此方法比使用 malloc() 更妥當，但大多數開放原始碼作業系統都不具備此記憶體管理能力。
• 盡可能減少應用中使用的任務數量。使用 RTOS 時，許多開發人員忍不住想建立大量任務，但建立任務就需要有任務控制區塊以及相關的獨立堆疊空間，因此建立不必要的任務會大幅減少可用記憶體。

結論

IoT 應用促使嵌入式系統軟體的複雜性隨之提高，因此為了幫助開發人員應對這個複雜性難題並予以抽象化，使用 RTOS 已成為必要之舉。訣竅就是不能隨意挑選 RTOS。每款 RTOS 都各有所長，若挑選的 RTOS 不符合開發人員的用途，記會浪費大量的時間與精力。

相反地，開發人員應積極主動參與 RTOS的挑選過程，仔細評估各個不同層面，不光是評估 RTOS 本身，還要考慮到週邊部份，如 RTOS 廠商，以及遇到問題時可取得的支援等。有個有效的方法就是使用 KT 矩陣來仔細評估考慮中的 RTOS，然後在完全支援該系統的微控制器平台上，執行所選的 RTOS，確保其適用於相關應用。