實時操作系統 (RTOS) 正在成為大多數嵌入式開發人員需要在其應用程序中使用的必要組件。隨著他們的微控制器轉向 32 位架構以及他們的設備開始連接到互聯網，曾經是傳統裸機開發人員的開發人員開始過渡到使用 RTOS。無論你是剛剛開始使用 RTOS 還是已經使用多年，開發人員在使用 RTOS 時都會面臨一些挑戰。

　　挑戰 #1 – 決定何時使用 RTOS

　　裸機開發人員面臨的首要挑戰是決定何時使用 RTOS。事實上，在需要進行切換之前，開發人員可以做很多事情來模擬搶占式調度。那么，有哪些關鍵指標表明 RTOS 是正確的選擇? 以下是開發人員應考慮的幾個問題：

　　應用程序是否包含連接堆棧，例如 USB、WiFi、TCP/IP 等?

　　使用 RTOS 會簡化系統時間管理嗎?

　　如果使用 RTOS，應用程序管理和維護會得到改善嗎?

　　是否需要確定性行為?

　　程序任務是否需要相互搶占的能力?

　　MCU 是否具有至少 32 kB 的代碼空間和 4 kB 的 RAM?

　　如果大多數問題的答案是肯定的，那么使用 RTOS 將有助于簡化應用程序開發。

　　挑戰 #2 – 設定任務優先級

　　選擇任務優先級可能是一項挑戰。哪個任務應該具有最高優先級? 下一個最高? 甚至可以安排任務嗎? 這些是使用 RTOS 的嵌入式開發人員經常想到的問題。不少開發人員似乎只是根據他們認為任務的重要性隨機分配優先級。以這種方式選擇優先級是災難的根源。開發人員應該首先使用速率單調調度來大致了解他們的周期性任務是否可以成功調度。RMS 假設任務是周期性的并且不會相互交互，因此它只是一個起點，但可以讓開發人員完成 80% 的工作。之后，開發人員可以使用跟蹤工具來觀察他們的系統行為并進行微調。

　　挑戰#3——調試

　　調試嵌入式系統是一項重大挑戰。開發人員可以花費 20% 到 80% 的開發周期來調試他們的應用程序代碼，平均通常在 40% 左右。那是花費大量時間進行調試。使用 RTOS 會使調試復雜化。RTOS 可能會引入諸如優先級反轉、死鎖和任務抖動等問題。剛開始使用 RTOS 的開發人員可能沒有意識到可以使用全新的調試技術(例如跟蹤)來調試他們的系統。這些工具可以記錄任務開始和結束執行的時間以及事件發生的時間，例如數據被放入消息隊列或互斥鎖被鎖定。甚至可以使用跟蹤工具來驗證應用程序是否按預期執行。不用說，調試是每個開發團隊都面臨并需要解決的大問題。

　　挑戰#4——管理記憶

　　開發人員面臨的一個重要挑戰是管理內存。使用 RTOS 時，內存管理有幾個層次。首先，如果開發人員使用資源受限的設備，他們可能需要配置他們的 RTOS 以最小化代碼大小。通常 RTOS 優化需要調整 RTOS 配置文件以禁用使用大量代碼空間或 RAM 的功能。其次，嵌入式開發人員需要正確管理他們的 RTOS 對象以及他們如何在系統中分配內存。使用堆和字節池可能會導致不確定的行為以及內存碎片。使用 RTOS 默認堆棧大小可能會導致使用過多 RAM，或者更糟糕的是，堆棧溢出。這些問題可以通過執行最壞情況堆棧分析和使用塊內存池來解決，但這并不能使問題變得微不足道。

　　挑戰#5——學習曲線

　　從裸機編碼技術切換到 RTOS 環境的開發人員經常在學習 RTOS 方面遇到困難。網絡上和書籍中有很多很棒的材料，它們提供了有關主要 RTOS 對象以及如何使用它們的想法，但是擁有 RTOS 應用程序的理論知識是一回事。設計和實現一個真正的應用程序并解決所有的細微差別和問題是另一回事。進行過渡的開發人員應該選擇他們最喜歡的開發套件，即他們感興趣的 RTOS 端口，然后開始設計一些簡單的東西，以縮短學習曲線。

　　結論

　　無論你是使用 RTOS 的新手還是經驗豐富的老手，作為嵌入式開發人員，我們在設計和實施基于 RTOS 的應用程序時都面臨著非常相似的挑戰。隨著系統復雜性的增加，每個嵌入式軟件工程師都需要成為使用 RTOS 的專家。