微控制器實時操作系統實踐1實時系統介紹

0書籍簡介

這本實踐指南將為你提供最重要的功能知識，以使實時操作系統（RTOS）在微控制器（MCU）上啟動和運行。如果你有興趣學習如何通過使用實際硬體的實例來實現RTOS的應用，並討論常見的性能與開發時間的權衡，那麼你就來對地方了！我們將使用自由RTOS來實現代碼！

我們將使用FreeRTOS內核實現代碼，使用低成本的STM Nucleo開發板與流行的STM32 ARM MCU一起工作，並使用SEGGER調試工具調試/分析代碼。 本書中使用的所有工具都是經過挑選的，因為它們對於剛剛入門的業餘愛好者或專業人士來說很容易獲得，同時也因為它們在現實世界的專業團隊中很受歡迎。你通過閱讀本書和通過實例獲得的知識和經驗將直接適用於專業環境中的實際開發。

本書適用對象

RTOS編程不是初學者的話題，絕對不是學習嵌入式系統的正確起點。如果你對MCU或C語言完全陌生，那麼你最好從基礎知識開始，在進入這個更高級的話題之前獲得一些實踐經驗。

那麼，誰能從本書中受益最多？

• 專業程式員： 你總是在裸機上編程（沒有操作系統），並希望通過學習如何使用RTOS來滿足嚴格的定時要求、平衡併發操作和創建模塊化代碼來提高你的MCU編程技能。

• 對 "弄髒自己的手 "感興趣的學生： 你一直在學習理論知識，聽講座，併在實驗室進行編碼練習，但現在你正在尋找完整的指南，幫助你開始使用你可以實際觸摸和互動的東西。

• 創客們進入了更高級的主題： 你已經寫了一些草圖或腳本，但你正在尋找你的下一個挑戰。也許你想從頭開始創建一個完整的基於MCU的系統--這裡的信息將幫助你走上編程的軌道。你甚至會得到一些提示，瞭解為你的項目選擇MCU時應該註意什麼。

本書的內容

本書共包括17章，分佈在四個部分。如果你對某些材料已經很熟悉，就沒有必要直接閱讀本書。例如，如果你對基本的RTOS概念和實時系統已經很熟悉，可以跳到第4章，選擇合適的MCU。以下是本書各章的簡要說明：

第1章，實時系統介紹，簡單介紹了什麼是RTOS以及何時和為何要使用RTOS。還討論了基於MCU的RTOS的硬體和軟體替代方案。

第2章，瞭解RTOS任務，提供了超級迴圈和RTOS任務的比較，包括使用兩者實現並行操作的各種方式。

第3章，任務信號和通信機制，是對更多RTOS概念的簡短介紹，其中有大量的圖表。 這一章和第2章 "理解RTOS任務 "一起，如果你需要的話，應該可以作為參考，快速複習一下這些概念和術語。

第4章，選擇合適的MCU，幫助你瞭解在選擇MCU時應該考慮什麼。在瞭解了硬體和固件之間的相互依存關係之後，我們來看看為什麼硬體和固件工程師在系統設計中都有參與是如此重要。

第5章 "選擇IDE "介紹並討論了各種類型的集成開發環境（IDE），包括為什麼你可能決定選擇一種而不是另一種（或者根本不選擇）的原因。這裡涵蓋了關於設置STM32CubeIDE和導入示例代碼的說明。

第6章，實時系統的調試工具，涵蓋了調試嵌入式系統的工具，包括我們將在本書其餘部分使用的調試工具--SEGGER Ozone和SEGGER SystemView可視化軟體。這裡介紹瞭如何使用Ozone和SystemView的說明。基於硬體的測試設備和一些其他有用的工具也包括在你的嵌入式系統開發工作流程中。

第7章，FreeRTOS調度器，教你使用FreeRTOS創建任務的各種方法以及如何排除啟動失敗的故障。你將獲得對任務狀態和優化性能的不同方法的理解。

第8章，保護數據和同步任務，包括使用信號的任務同步和使用互斥的數據保護，以及如何避免競賽條件和優先順序反轉。還涉及到軟體定時器。

第9章，任務內通信，研究了任務間傳遞信息的不同方式，有使用隊列按值和參考傳遞信息的不同例子，討論了兩種方法的優點和註意事項。我們還將瞭解一種輕量級的任務間通信機制--直接任務通知，包括任務通知和隊列的比較。

第10章，驅動程式和ISRs，深入探討了幾個詳細的例子，說明如何用各種FreeRTOS基元實現高效的驅動程式，包括信號燈、隊列和流緩衝器。我們還將研究FreeRTOS如何與MCU硬體（如DMA）結合使用，以提供極其有效的CPU驅動實現。這一章既可以直接使用MCU外圍寄存器，也可以使用STM32 HAL代碼。

第11章，跨任務共用硬體外設，教你如何創建可以在多個任務中安全使用的驅動程式，同時共用硬體資源。我們將對STM提供的USB CDC實現進行調整，使其更加友好和高效，用一個突變器和隊列來包裝它，以便在多個任務中安全使用。

第12章，創建良好抽象架構的技巧，涵蓋了代碼的可重用性、靈活性和硬體的可移植性，著眼於創建抽象，使你的工作更容易。還包括一些關於源代碼組織的建議，以幫助促進重用。

第13章，用隊列創建鬆散耦合，是本書所有概念的高潮。它包括完整的鬆散耦合架構的例子，用來創建適當的抽象的、端到端的應用程式。我們將使用先前開發的USB CDC虛擬通信埠以及LED抽象，使用命令隊列創建鬆散耦合的、完全可重用的LED排序器。這個嵌入式應用可以用Python編寫的跨平臺用戶界面從PC上控制。

第14章，選擇一個RTOS API，繼續我們的高層架構討論，看一下可用於訪問FreeRTOS功能的三種不同的API：本地FreeRTOS API，ARM的CMSIS-RTOS，以及POSIX。討論的主題包括對可用功能的比較，以及為什麼你會在不同的項目中選擇其中一個。

第16章，多處理器和多核系統，告訴你多處理器和多核系統是如何用於各種原因的--瞭解它們是什麼，以及如何讓系統的不同部分進行通信。

第17章，故障排除提示和下一步，涵蓋了系統故障排除的提示，包括如何避免堆棧溢出的提示和如何對掛起的系統進行故障排除。還包括對下一步工作的一些建議

準備

我們已經盡一切努力使本書中的例子對廣大讀者來說儘可能的簡單。 為了最大限度地利用本書（通過實例工作），你將需要以下硬體：

• 一臺可以上網的Windows、macOS或Linux電腦
• 一塊STM32 Nucleo-F767ZI開發板
• 兩根Micro-USB電纜
• 跳線--20至22 AWG（約0.65毫米）實心線

由於本書的目標是為低級別的嵌入式系統編程，我們將使用C語言作為首選。假設有一些微控制器的知識，以及閱讀數據手冊的能力。如果你對C語言（或C++）有很好的理解，那麼你應該可以輕鬆地閱讀本書--不需要以前的RTOS知識。由於我們將在嵌入式系統中使用MCU，所以在硬體方面也會有一些偶爾的討論，主要涉及到MCU和開發板的特性。這些主題將涵蓋足夠的細節，具有最低限度的硬體知識的人應該能夠跟上，沒有太大困難。你應該能夠自如地與開發硬體進行互動和處理，儘管不需要任何實際組裝。

1實時系統介紹

實時系統有各種各樣的實現方式和使用情況。本書的重點是如何使用實時操作系統（RTOS）在微控制器單元（MCU）上創建實時應用程式。

在這一章中，我們將首先概述什麼是RTOS，並瞭解可能有實時要求的廣泛系統。從那裡，我們將看看實現實時性能的一些不同方法，以及可能使用的系統類型（如硬體、固件和軟體）的概述。最後，我們將討論什麼時候在MCU應用中使用RTOS是明智的，什麼時候可能完全沒有必要。

到底什麼是實時性？

任何對特定事件有確定響應的系統都可以被認為是 "實時 "的。如果一個系統在不符合時間要求時被認為是失敗的，它一定是實時的。如何定義故障（以及故障系統的後果）可以有很大不同。認識到實時性要求可以有很大的不同，這一點極其重要，既包括時間要求的速度，也包括如果沒有達到所要求的實時期限，後果的嚴重性。

時序要求的範圍

為了說明可能遇到的定時要求的範圍，讓我們考慮從模數轉換器（ADC analog-to-digital converters）獲取讀數的幾個不同系統。

我們要看的第一個系統是一個控制系統，它被設置為控制烙鐵的溫度（如下圖所示）。我們所關註的系統部分是MCU、ADC、感測器和加熱器。

MCU負責以下工作：

• 通過ADC從溫度感測器獲取讀數
• 運行閉環控制演算法（以保持烙鐵頭的溫度恆定）。
• 根據需要調整加熱器的輸出
  

由於焊頭的溫度變化不是非常快，MCU可能只需要每秒獲取50個ADC樣本（50Hz）。負責調整加熱器的控制演算法（以保持恆定的溫度）以更慢的速度運行，5赫茲：

ADC將斷言硬體線路，表示轉換已經完成，並準備讓MCU將讀數轉移到其內部存儲器。讀取ADC的MCU有多達20毫秒的時間將數據從ADC傳輸到內部存儲器，然後才需要進行新的讀取。MCU還需要運行控制演算法來計算加熱器輸出的更新值，頻率為5赫茲（200毫秒）。這兩種情況（雖然不是特別快）都是實時要求的例子：

現在，在ADC讀數的另一端，我們可能有高帶寬的網路分析儀或示波器，它將以幾十GHz的速率讀取ADC！在這種情況下，ADC的原始讀數很可能是在幾百個小時內完成！原始ADC讀數可能會被轉換成頻域，併在高解析度前面板上以圖形方式顯示，每秒幾十次。像這樣的系統需要進行大量的處理，必須遵守極其嚴格的時間要求，如果它要正常運作的話。

在光譜的中間位置，你會發現諸如閉環運動控制器等系統，它們通常需要在數百赫茲至數十千赫茲之間執行其PID控制迴路，以便在快速移動的系統中提供穩定性。那麼，實時性有多快？嗯，僅從ADC的例子就可以看出，這取決於。

在前面的一些例子中，如示波器或電烙鐵，如果不能滿足計時要求，就會導致性能不佳或報告錯誤的數據。在電烙鐵的情況下，這可能是溫度控制不佳（這可能導致組件損壞）。對於測試設備來說，錯過最後期限可能導致錯誤的讀數，這就是失敗。這對一些人來說可能不是什麼大問題，但對該設備的用戶來說，他們依賴所報告數據的準確性，這可能是非常重要的。一些用於標準驗證的實驗室設備對產品的一致性進行檢查。如果設備中存在未被髮現的故障，導致測量不准確，就可能報告出不正確的數值。可能有可能重新進行可疑的測試。然而，最終，如果重新測試的頻率過高，可靠的讀數不能指望，那麼測試設備將開始變得可疑，並被視為不可靠，銷售將下降--所有這些都是因為一個實時要求沒有得到持續滿足。

在其他系統中，如無人機的飛行控制或工業過程式控制制中的運動控制，如果不能及時運行控制演算法，可能會導致更多的物理災難，如崩潰。在這種情況下，其後果有可能危及生命。

值得慶幸的是，可以採取一些措施來避免所有這些故障情況的發生。

保證實時行為的方法

確保一個系統做它要做的事情的最簡單的方法之一是確保它在滿足要求的同時儘可能的簡單。這意味著要抵制將簡單的任務過度複雜化的衝動。如果烤麵包機是用來烤麵包的，就不要在上面加一個顯示屏，讓它也告訴你天氣情況；只要讓它在適當的時間內打開加熱元件即可。這個簡單的任務已經完成了多年，不需要任何代碼或可編程設備。

作為程式員，如果我們遇到一個問題，我們傾向於立即伸手去拿最近的MCU並開始編碼。然而，產品的一些功能（尤其是當產品有電子機械部件時）最好不用代碼來處理。車窗其實不需要帶輪詢迴圈的MCU來運行，通過驅動器打開電機，觀察感測器的反饋來關閉它們。這項任務實際上可以由一些機械開關和二極體來處理。如果給定的系統需要一個反饋報告機制--比如在視窗卡住的情況下需要斷言錯誤--那麼可能別無選擇，只能使用一個更複雜的解決方案。然而，作為工程師，我們的目標應該始終是相同的--儘可能簡單地解決問題，不增加額外的複雜性。

如果一個問題可以單獨通過硬體來解決，那麼在拿出MCU之前，先與團隊一起探討這種可能性。如果問題可以通過使用簡單的while迴圈來執行一些感測器狀態的輪詢來處理，那麼就簡單地輪詢感測器的狀態；可能沒有必要開始編碼中斷服務程式（ISRs）。如果設備的功能是單一用途的，那麼在很多情況下，完整的實時操作系統可能會妨礙工作--所以不要使用它!

實時系統的類型

有許多不同的方法來實現實時行為。下麵的部分是關於你可能遇到的各種類型的實時系統的討論。還要註意的是，有可能出現以下系統的組合，作為子系統一起工作。這些不同的子系統可以出現在產品、板卡、甚至是晶元層面（這種方法在第16章多處理器和多核系統中討論）

硬體

最初的實時系統，即硬體，仍然是滿足極其嚴格的公差和/或快速定時要求的首選。它可以用離散數字邏輯、模擬組件、可編程邏輯或特定應用集成組件（ASIC application-specific integrated component）來實現。可編程邏輯器件（PLD Programmable logic devices）、複雜可編程邏輯器件（CPLD complex programmable logic devices）和域可編程門陣列（FPGA field-programmable gate arrays）是該解決方案中可編程邏輯器件部分的不同成員。基於硬體的實時系統可以涵蓋從模擬濾波器、閉環控制和簡單的狀態機到複雜的視頻編解碼器的任何東西。當實施時考慮到省電，可以使ASIC比基於MCU的解決方案消耗更少的功率。一般來說，硬體的優點是可以即時並行地進行操作（當然，這是過度簡化），而單核MCU則只能給人以並行處理的假象。

實時硬體開發的缺點一般包括以下幾點：

• 非可編程設備的不靈活性。
• 所需的專業技術通常不如軟體/固件開發人員那麼普遍。
• 全功能可編程器件的成本（例如，大型FPGA）。
• 開發定製ASIC的高成本。

裸機固件

裸機固件被認為是（為我們的目的）不是建立在某種類型的預先存在的內核/調度器之上的任何固件。一些工程師更進一步，認為真正的裸機固件不能使用任何預先存在的庫（如供應商提供的硬體抽象庫），這種觀點也有一定的道理。裸機實現的好處是，用戶的代碼可以完全控制硬體的所有方面。主迴圈代碼執行被打斷的唯一方法是中斷發生時。在這種情況下，其他東西控制CPU的唯一方法是讓現有的ISR完成，或讓另一個更優先的中斷啟動。

當有少量相對簡單的任務需要執行時，或者有單一的任務時，裸機固件解決方案就很出色。如果固件保持專註並遵循最佳實踐，由於ISR（或在某些情況下，缺乏ISR）之間的相互作用相對較少，確定的性能通常容易測量和保證。在一些極端的情況下，對於高負載的MCU（或在ROM/RAM方面受到高度限制的MCU），裸機是唯一的選擇。

隨著裸機實現在非同步處理事件時變得更加複雜，它們開始與實時操作系統提供的功能重疊。要記住的一個重要考慮是，通過使用RTOS--而不是試圖推出你自己的線程安全系統--你會自動受益於RTOS供應商所做的所有測試。你也有機會使用具有事後分析能力的代碼--今天所有的RTOS都已經存在了好幾年了。作者一直在調整和增加功能，以使它們在不同的應用中變得強大和靈活。

基於RTOS的固件

在MCU上運行調度內核的固件是基於RTOS的固件。調度器和一些RTOS原件的引入允許任務在它們自己擁有處理器的假象下運行（在第2章，瞭解RTOS任務中詳細討論）。使用RTOS可以使系統在後臺執行其他複雜任務的同時保持對最重要事件的響應。

所有這些任務的運行都有一些弊端。共用數據的任務之間可能會出現相互依賴的情況--如果處理不當，這種依賴性會導致任務意外地阻塞。雖然有處理這種情況的規定，但它確實增加了代碼的複雜性。中斷一般會使用任務信令來儘快處理中斷，並將儘可能多的處理推遲到任務中。如果處理得當，這種解決方案對於保持複雜系統的響應是非常好的，儘管有許多複雜的互動。然而，如果處理不當，這種設計範式會導致更多的時間抖動和更少的確定性。

基於RTOS的軟體

運行在包含記憶體管理單元（MMU）和中央處理單元（CPU）的完整操作系統上的軟體被認為是基於RTOS的軟體。用這種方法實現的應用程式可能非常複雜，需要在各種內部和外部系統之間進行許多不同的交互。使用完整的操作系統的好處是伴隨著它的所有能力--包括硬體和軟體。

在硬體方面，通常有更多的CPU核心以更高的時鐘速率運行。可以有數千兆位元組的記憶體和持久性存儲器。增加外圍硬體可以像增加一塊卡一樣簡單（只要有預先存在的驅動程式）。

在軟體方面，有大量用於網路堆棧、用戶界面開發、文件處理等的開源和供應商專有解決方案。在所有這些能力和選項之下，內核仍然以這樣一種方式實現，即關鍵任務不會被無限期地阻斷，這在傳統的操作系統中是可能的。正因為如此，獲得確定性的性能仍然是可以做到的，就像RTOS固件一樣。

精心製作的操作系統軟體

與基於RTOS的軟體類似，一個標準的操作系統擁有開發者可以要求的所有庫和功能。然而，缺少的是對滿足時間要求的嚴格關註。一般來說，用傳統操作系統實現的系統會有更少的確定性行為（在安全關鍵的情況下，沒有一個可以真正指望的）。如果在沒有災難性後果的情況下，有一個寬鬆的實時性要求，如果沒有按時完成一個躊躇滿志的最後期限，只要在選擇運行什麼軟體堆棧和控制它們的資源使用方面謹慎行事，標準的操作系統就可以發揮作用。帶有PREEMPT_RT補丁的Linux內核是這種類型的實時系統的一個很好的例子。

所以，現在實現實時系統的所有選項都已被列出，現在是時候準確定義我們說的RTOS，特別是基於MCU的RTOS是什麼意思。

定義實時操作系統

操作系統（如Windows、Linux和macOS）的創建是為了提供一個一致的編程環境，將底層硬體抽象化，使其更容易編寫和維護電腦程式。它們為應用程式員提供了許多不同的基元（如線程和互斥），可以用來創建更複雜的行為。例如，可以創建一個多線程程式，提供對共用數據的保護性訪問：

前面的應用程式並沒有實現線程和互斥基元，它只是利用了它們。線程和互斥的實際實現是由操作系統處理的。這有幾個優點：

• 應用程式代碼不那麼複雜。
• 更容易理解--無論哪個程式員都使用相同的原語，從而更容易理解由不同人創建的代碼。
• 硬體可移植性更好--有了適當的預防措施，代碼可以在操作系統支持的任何硬體上運行而無需修改。

在前面的例子中，mutex被用來確保每次只有一個線程可以訪問共用數據。在通用操作系統的情況下，每個線程都會很高興地等待突變體無限期地可用，然後再去訪問共用數據。這是實時操作系統與通用操作系統不同的地方。在RTOS中，所有阻塞的系統調用都是有時間限制的。RTOS不允許無限期地等待mutex，而是允許指定一個最大延遲。例如，如果線程1試圖獲取Mutex，但在100毫秒（或1秒）後仍未得到它，它將繼續等待Mutex變得可用。

在RTOS的實現中，要指定等待Mutex變得可用的最大時間。如果線程1指定它必須在100毫秒內獲取Mutex，並且在101毫秒後仍未收到Mutex，線程1將收到通知，說Mutex沒有被及時獲取。指定這個超時是為了幫助創建確定性的系統。

任何提供執行給定代碼的確定性方式的操作系統都可以被認為是實時操作系統。這個實時操作系統的定義涵蓋了相當多的系統。

有幾個特征傾向於將RTOS應用與另一RTOS應用區分開來：不滿足實時截止日期的頻率是可以接受的，以及不滿足實時截止日期的嚴重程度。不同範圍的RTOS應用通常被歸納為三類--硬、固和軟實時系統。

不要太糾結於固和軟實時系統之間的區別。這些術語的定義在我們的行業內甚至沒有一致的意見。重要的是，你要知道你的系統的要求，並設計一個解決方案來滿足這些要求!

如果故障會導致生命或重大財產的損失，那麼故障的嚴重程度一般被認為是安全關鍵型的。有一些硬實時系統與安全無關。

硬實時系統

硬實時系統必須在100%的時間內滿足其最後期限。如果系統沒有達到最後期限，那麼它就被認為是失敗了。這並不一定意味著如果故障發生在硬實時系統中就會傷害到人，只是說如果系統錯過了一個截止日期，它就失敗了。

硬實時系統的一些例子可以在醫療設備中找到，如心臟起搏器和具有極其嚴格控制參數的控制系統。在心臟起搏器的情況下，如果心臟起搏器錯過了在正確的時間點進行電脈衝的最後期限，它可能會殺死病人（這就是為什麼心臟起搏器被定義為安全關鍵型系統）。

相反，如果電腦數控（CNC）銑床上的運動控制系統沒有及時對指令做出反應，它可能會將刀具插入正在加工的零件的錯誤部位，從而毀掉它。在我們提到的這些案例中，故障造成了生命損失，而另一個則把一些金屬變成了廢品，但這兩個故障都是由錯過的最後期限造成的。

固實時系統

與硬實時系統相比，固實時系統幾乎在所有時間都需要達到其最後期限。如果視頻和音頻瞬間失去同步，可能不會被認為是系統故障，但可能會使視頻的消費者感到不安。

在大多數控制系統中（類似於前一個例子中的烙鐵），稍微超出規定時間的幾個樣本的讀取不太可能完全破壞系統控制。如果控制系統有ADC，可以自動獲取新的樣本，如果MCU沒有及時讀取新的樣本，它將被新的樣本覆蓋。這種情況可能偶爾發生，但如果發生得太頻繁或太頻繁，溫度穩定性就會被破壞。在要求特別高的系統中，可能只需要錯過幾個樣本，整個控制系統就會失靈。

軟實時系統

當涉及到系統必須滿足其最後期限的頻率時，軟實時系統是最寬鬆的。這些系統通常只提供一個遵守最後期限的最大努力的承諾。

汽車中的巡航控制是軟實時系統的很好的例子，因為對它沒有硬性規定或期望。駕駛員通常不期望他們的速度能收斂到設定速度的+/- x mph/kph之內。他們期望在合理的情況下，例如沒有大的坡度，控制系統最終會讓他們在大多數時間內接近他們的理想速度。

實時操作系統的範圍

實時操作系統的功能各不相同，它們最適合的處理器架構和尺寸也各不相同。在較小的方面，我們有較小的以8-32位MCU為重點的RTOS，如FreeRTOS、Keil RTX、Micrium µC、ThreadX，以及更多。 這類RTOS適合在微控制器上使用，並提供一個緊湊的實時內核作為最基本的產品。當從MCU轉向32位和64位應用處理器時，你會傾向於找到RTOS，如Wind River VxWorks和Wind River Linux、Green Hills的Integrity OS，甚至是帶有PREEMPT_RT內核擴展的Linux。這些完整的操作系統提供了大量的軟體選擇，為實時調度要求以及一般計算任務提供瞭解決方案。即使有了我們剛剛提到的操作系統，我們也只是觸及了可用的錶面。在所有級別的實時操作系統中，無論大小，都有免費和付費的解決方案（有些價格遠遠超過10000美元）。

那麼，既然有免費的解決方案，你為什麼還要選擇付費呢？免費提供的RTOS解決方案和付費解決方案之間的主要區別因素是安全批准、中間件和客戶支持。 因為實時操作系統提供了高度確定的執行環境，它們經常被用於複雜的安全關鍵型應用。我們所說的安全關鍵，一般是指一個系統，其故障可能會傷害人或造成重大損失。這些系統需要確定性的操作，因為它們必須一直以可預測的方式行事。保證代碼在固定的時間內對事件做出反應是確保它們行為一致的重要一步。這些安全關鍵型應用中的大多數都受到監管，並有自己的一套管理機構和標準，如飛機的DO-178B和DO-178C或工業應用的IEC 61508 SIL 3和ISO 26262 ASILD。為了使安全關鍵型認證更經濟實惠，設計者通常會保持這些系統的代碼極其簡單（因此有可能從數學上證明系統將穩定運行，不會出錯），或者轉向已經通過認證的商業RTOS解決方案，作為一個起點。威騰斯丁公司的SafeRTOS是FreeRTOS的衍生產品，已獲得工業、醫療和汽車領域的認證。

中間件也可以是複雜系統中的一個極其重要的組成部分。中間件是運行在用戶代碼（你，應用程式員編寫的代碼）和較低層，如RTOS或裸機（無RTOS）之間的代碼。付費解決方案的另一個價值主張是，生態系統提供了一套預集成的高質量中間件（如文件系統、網路堆棧、GUI框架、工業協議等），最大限度地減少了開發，降低了整體項目風險。使用中間件而不是自己開發的原因是為了減少內部開發團隊編寫的原始代碼量。這既降低了風險，也減少了團隊花費的總時間--因此，根據項目複雜性和進度要求等因素，這可能是一項值得的投資。

付費解決方案通常也會直接由固件供應商提供某種程度的客戶支持。雇佣和保留工程師的成本很高。管理人員最害怕的莫過於走進一個滿是工程師的房間，這些人正在為他們的工具而困惑，而不是為需要解決的真正問題而工作。有了專家的幫助，只需一封電子郵件或一個電話，就可以大大提高團隊的生產力，從而縮短周轉時間，使每個人的工作環境更加愉快。

FreeRTOS有付費的支持和培訓選項，以及付費的中間件解決方案，這些都可以被整合。然而，也有開放源碼和/或免費提供的中間件組件，其中一些將在本書中討論。

本書使用的RTOS

什麼這本書只涉及一個MCU模型上的一個RTOS？有幾個原因，其中一個原因是我們要講的大部分概念幾乎適用於任何可用的RTOS，就像良好的編碼習慣超越了你碰巧要編碼的語言一樣。通過專註於一個RTOS和一個MCU的單一實現，我們將能夠更深入地探討一些話題，而不是在嘗試討論所有的替代方案時才有可能。

FreeRTOS是最流行的用於MCU的RTOS實現之一，而且非常廣泛。它已經存在了15年之久，並且已經被移植到幾十個平臺。如果你曾經與熟悉RTOS編程的真正的底層嵌入式系統工程師交談過，他們肯定聽說過FreeRTOS，而且很可能至少使用過一次。通過把註意力集中在FreeRTOS上，你將有能力迅速地把你的FreeRTOS知識遷移到其他硬體上，或者在情況需要時過渡到其他RTOS。

我們使用FreeRTOS的另一個原因？嗯，它是免費的! FreeRTOS是在MIT許可下發佈的。關於許可和其他FreeRTOS衍生產品的更多細節，如SAFERTOS和OpenRTOS，請參見https://www.freertos.org/a00114.html。

下麵的圖表顯示了FreeRTOS在一個典型的ARM固件堆棧中的位置。堆棧指的是構成系統的所有不同層的固件組件，以及它們是如何堆疊在一起的。這裡的用戶是指使用FreeRTOS的程式員（而不是嵌入式系統的終端用戶）：

一些值得註意的項目如下：

• 用戶代碼能夠訪問相同的FreeRTOS API，不管底層的硬體埠實現如何。
• FreeRTOS並不阻止用戶代碼使用供應商提供的驅動程式、CMSIS或原始硬體寄存器。
• 擁有一個在不同硬體間一致的標準化的API意味著代碼可以很容易地在硬體目標之間遷移，而不需要不斷地重寫。讓代碼直接與硬體對話的能力也提供了必要時編寫極其有效的代碼的手段（以犧牲可移植性為代價）。

何時使用實時操作系統

偶爾，當有人第一次瞭解到實時操作系統這個術語時，他們會錯誤地認為實時操作系統是在嵌入式系統中實現實時行為的唯一方法。這當然是可以理解的（尤其是考慮到這個名字），但這與事實相去甚遠。有時，最好把RTOS看作是一種潛在的解決方案，而不是用於一切的解決方案。一般來說，對於一個基於MCU的RTOS來說，要成為一個特定問題的理想解決方案，它需要有Goldilocks級別的複雜性--不要太簡單，但也不要太複雜。

如果有一個極其簡單的問題，例如監測兩個狀態併在它們同時出現時觸發警報，那麼解決方案可能是一個直接的硬體解決方案（例如一個AND門）。在這種情況下，可能沒有理由使事情進一步複雜化，因為AND門的解決方案將是非常快的，具有高度的確定性和極端的可靠性。它也將需要很少的開發時間。

現在，考慮一下只有一兩個任務需要執行的情況，如控制電機的速度和觀察編碼器以確保正確的距離被穿越。這當然可以用離散的模擬和數字硬體來實現，但有可配置的距離會增加一些複雜性。此外，調整控制環路的繫數很可能需要調整電位器的設置（可能是針對每個單獨的板子），按照今天的製造標準，這在某些或大多數情況下是不可取的。因此，在硬體解決方案方面，我們只能用CPLD或FPGA來實現運動控制演算法和跟蹤行走的距離。這恰好是一個非常合適的選擇，因為它有可能小到可以裝入CPLD，但在某些情況下，FPGA的成本可能是不可接受的。這個問題也是由MCU經常處理的。如果現有的內部資源不具備硬體語言或工具鏈所需的專業知識，那麼裸機MCU固件解決方案可能是一個不錯的選擇。

假設問題更加複雜，例如控制幾個不同執行器的設備，從感測器中讀取數據，並將這些值存儲在本地存儲器中。也許該設備還需要坐在某種網路上，如乙太網、Wi-Fi、控制器區域網路（CAN），等等。一TOS可以很好地解決這種類型的問題。事實上，有許多不同的任務需要完成，或多或少地相互非同步，這使得我們很容易認為RTOS帶來的額外複雜性將得到回報。實時操作系統幫助我們確保低優先順序的、更複雜的任務，如網路和文件系統堆棧，不會幹擾時間更緊迫的任務（如控制執行器和讀取感測器）。在許多情況下，可能會有某種形式的控制系統，通常會從在明確的時間間隔內運行中受益，這是實時操作系統的優勢。

現在，考慮一個與前面類似的系統，但現在有多種網路要求，例如為網頁提供服務，處理複雜的企業環境中的用戶認證，以及將文件推送到需要基於不同網路文件協議的各種共用目錄。這種複雜程度可以用RTOS來實現，但同樣，根據可用的團隊資源，這可能最好留給完整的操作系統來處理（無論是RTOS還是通用的），因為許多所需的複雜軟體堆棧已經存在。有時，可以採取多核方法，其中一個核心運行RTOS，另一個運行通用操作系統。

現在，可能很明顯，沒有確切的方法來確定哪種實時解決方案對所有情況都是正確的。每個項目和團隊都有自己獨特的要求、背景、技能組合和背景，為這個決定提供了舞臺。選擇一個問題的解決方案有很多因素；重要的是要保持開放的心態，選擇在那個時間點上最適合你的團隊和項目的解決方案。