為什麼航天器、導彈喜歡用微控制器，而不是嵌入式系統？

sewain發表於2021-03-16

道哥的第 029 篇原創

一、前言

前幾天和一個在某研究所的發小聊天，他說：現在的航空、航天和導彈等武器裝備中，控制系統幾乎都是用微控制器，而不是嵌入式系統。

乍一聽，和我們的直覺有矛盾啊：那麼高大上的裝置，其中的控制邏輯一定很複雜，不用嵌入式系統怎麼來完成那麼複雜的功能控制啊？然後仔細瞭解了一下，才明白答案是：安全+可控。

這篇文章我們就來聊一下關於微控制器與嵌入式、作業系統與 RTOS 之間的那些事！通過這篇文章，讓你作業系統的實時性有一個系統、全面的理解！

二、關於微控制器與嵌入式系統之間界定

說實話，關於它倆的區分，沒有人可以給出一個標準的、正確的答案。每個人理解的微控制器與嵌入式系統，都是略有差別的。

拋開硬體，從應用程式開發的角度來看，我是這樣來理解的：

微控制器：可以直接使用狀態機來實現程式框架，也可以利用一些 RTOS(ucOS、FreeRTOS、vxWorks、RT-Thread)等來完成一些排程功能。

嵌入式系統：利用嵌入式 Linux 作業系統以及一些變種來編寫應用程式。

我知道自己的理解可能是不對的，至少不嚴謹、範圍狹隘，既然沒有標準答案，那姑且引用維基百科中的定義吧，畢竟概念是死的，更重要的是我們如何根據實際的需要來進行選擇。

1. 微控制器

微控制器，全稱單片微型計算機（single-chip microcomputer），又稱微控制器單元 MCU（microcontroller unit）。

把中央處理器、儲存器、定時/計數器、各種輸入輸出介面等都整合在一塊積體電路晶片上的微型計算機。

由於其發展非常迅速，舊的微控制器的定義已不能滿足，所以在很多應用場合被稱為範圍更廣的微控制器；

2. 嵌入式系統

嵌入式系統（Embedded System），是一種嵌入機械或電氣系統內部、具有專一功能和實時計算效能的計算機系統。

嵌入式系統常被用於高效控制許多常見裝置，被嵌入的系統通常是包含數字硬體和機械部件的完整裝置，例如汽車的防鎖死剎車系統。

現代嵌入式系統通常是基於微控制器（如含整合記憶體和/或外設介面的中央處理單元）的，但在較複雜的系統中普通微處理器（使用外部儲存晶片和外設介面電路）也很常見。

3. 嵌入式Linux

嵌入式Linux（英語：Embedded Linux）是一類嵌入式作業系統的概稱，這型別的作業系統皆以Linux核心為基礎，被設計來使用於嵌入式裝置。

與電腦端執行的linux系統本質上是一樣的，雖然經過了一些功能上的裁剪，但是本質上是一樣的，主要利用 Linux 核心中的的任務排程、記憶體管理、硬體抽象等功能。

4. RTOS

實時作業系統（RTOS），又稱即時作業系統，它會按照排序執行、管理系統資源，併為開發應用程式提供一致的基礎。

實時作業系統與一般的作業系統相比，最大的特色就是“實時性”，如果有一個任務需要執行，實時作業系統會馬上（在較短時間內）執行該任務，不會有較長的延時。這種特性保證了各個任務的及時執行。

三、非實時、軟實時、硬實時

首先要明白什麼叫實時性？實時性考慮的不是速度、效能、吞吐量，而是確定性，也就是說：當一個事件發生的時候，可以確定性的保證在多長時間內得到處理，只要能滿足這個要求，就可以成為硬實時。比如：

作業系統1：當中斷髮生時，可以保證在 1 秒內得到這裡，那麼它就是硬實時系統，雖然響應時間長，但它是確定的；
作業系統2：當中斷髮生時，幾乎都可以在 1 毫秒內完成，那麼那就不能成為硬實系統，雖然響應時間短，但是它不確定。

也看到有文章說：應該取消軟實時這個模稜兩可的說法，要麼是實時，要麼是非實時！

作業系統包含的功能很多：任務排程、記憶體管理、檔案管理等等，其中最核心的就是任務排程，這也是非實時、軟實時、硬實時的最大區別。

也就是說，衡量實時性的指標就是：

1. 中斷延時：一個外部事件引發的中斷髮生時，到相應的中斷處理程式第一條指令被執行時，所經過的時間；
2. 任務搶佔延時：當一個高優先順序的任務準備就緒時，從正在執行的低優先順序任務中搶奪 CPU 資源所經過的時間；

不同的作業系統，其任務排程機制也是不一樣的，而這個排程機制的策略，又是與實際的使用場景相關的。因此，並不存在哪個好、哪個不好這樣的說法，合適的就是最好的！

比如：我們的桌面系統，需要考慮的是多工、併發，需要同時執行多個程式，哪個程式慢一點，使用者無所謂，甚至覺察不到；但是對於一個導彈控制系統，當一個外部感測器輸入訊號，觸發一個事件時，對應的處理必須立刻執行，否則耽擱 1 毫秒，結果可能就是差之千里！

四、x86 Linux 系統的排程策略

我們日常使用的 PC 機，它的主要目標是並行執行多工，強調的是吞吐率(儘可能多的執行很多應用程式的程式碼)，因此，採用的是分時作業系統，也就是每個任務都有一個時間片，當一個任務分配的時間片用完了，就自動換出（排程），然後執行下一個任務。

我們平常在寫 x86 平臺上寫普通的客戶端程式時，很少需要指定應用程式的排程策略和優先順序，使用的是系統預設的排程機制。反過來說，也就是在某些需要的場合下，是可以設定程式的排程策略和優先順序的。

例如在 Linux 系統中，可以通過 sched_setscheduler() 系統函式設定 3 種排程策略：

SCHED_OTHER: 系統預設的排程策略，計算動態優先順序（counter+20-nice），當時間片用完之後放在就緒佇列尾；

SCHED_FIFO: 實時排程策略，根據優先順序進行排程，一旦佔用CPU就一直執行，直到自己放棄執行或者有更高優先順序的任務需要執行；

SCHED_RR: 也是實時排程策略，在 SCHED_FIFO 的基礎上新增了時間片。在執行時，可以被更高優先順序的任務打斷，如果沒有更高優先順序的任務，那麼當任務的執行時間片用完之後，就會查詢相同優先順序的任務來執行。

1. 為什麼 Linux 系統是軟實時的？

可能有小夥伴會有疑問：既然 Linux 系統中提供了 SCHED_FIFO 基於優先順序的排程策略，為什麼仍然不能稱之為真正的硬實時作業系統？這就要從 Linux 的發展歷史說起了。

Linux 作業系統在設計之初，就是為了桌面應用而開發的，在那個時代，多個終端(電傳打字機和螢幕)連線到同一個電腦主機，需要處理的是多工、並行操作，並不需要考慮實時性，因此，在 Linux 核心中的一些基因，嚴重影響了它的實時性，例如有如下幾個因素：

(1) 核心不可搶佔

我們知道，一個應用程式在執行時，可以在使用者態和核心態執行(當呼叫一個系統函式，例如：write 時，就會進入核心態執行)，此時任務是不可搶佔的。

即使有優先順序更高的任務準備就緒，當前的任務也不能立刻停止執行。而是必須等到當前這個任務返回到使用者態，或者在核心態中需要等待某個資源而睡眠時，高優先順序任務才可以執行。

因此，這就很顯然無法保證高優先順序任務的實時性了。

(2) 自旋鎖

自旋鎖是用於多執行緒同步的一種鎖，用來對共享資源的一種同步機制，執行緒反覆檢查鎖變數是否可用。由於執行緒在這一過程中保持執行，因此是一種忙等待。一旦獲取了自旋鎖，執行緒會一直保持該鎖，直至顯式釋放自旋鎖。

自旋鎖避免了程式上下文的排程開銷，因此對於執行緒只會阻塞很短時間的場合是有效的，也就是說，只能在阻塞很短的時間才適合使用自旋鎖。

但是，在自旋鎖期間，任務搶佔將會失效，這就是說，即使自旋鎖的阻塞時間很短，但是這仍然會增加任務搶佔延時，讓排程變得不確定。

(3) 中斷的優先順序是最高的

任何時刻，只要中斷髮生，就會立刻執行中斷服務程式，也就是中斷的優先順序是最高的。只有當所有的外部中斷和軟終端都處理結束了，正常的任務才能得到執行。

這看起來是好事情，但是想一想，如果有比中斷優先順序更高的任務呢？假如系統在執行中，網口持續接收到資料，那麼中斷就一直被執行，那麼其他任務就可能一直得不到執行的機會，這是影響 Linux 系統實時性的巨大挑戰。

(4) 同步操作時關閉中斷

如果去看 Linux 核心的程式碼，可以看到在很多地方都執行了關中斷指令，如果在這期間發生了中斷，那麼中斷響應時間就沒法保證了。

2. Linux 系統如何改成硬實時？

以上描述的幾個因素，對 Linux 實現真正的實時性構成了很大的障礙，但是現實世界又的確有很多場合需要 Linux 具有硬實時，那麼就要針對上面的每一個因素提出解決方案。

目前主流的解決方案有 2 個：

單核心解決方案：給 Linux 核心打補丁，解決上面提到的幾個問題，例如：RT-Preempt;

雙核心解決方案：在硬體抽象層之上，執行 2 個核心：實時核心 + Linux 核心，它們分別向上層提供 API 函式，例如：Xenomai;

這 2 種解決方案分別有不同的實現，從調研情況來看，RT-Preempt 和 Xenomai 是使用比較多的，下面分別來看一下他們的優缺點。

（1）RT-Preempt

這種方式主要是對 Linux 核心進行打補丁，解決了上面所說的幾個問題：核心不可搶佔、自旋鎖、關中斷以及終端優先順序的問題。

至於每一個問題是如何解決的，由於篇幅關係，這裡就不介紹了，感興趣的小夥伴如果需要的話，可以深入瞭解一下。

由於是直接在 Linux 核心上打補丁(以後肯定會合併到主分支中的)，因此對於應用程式開發來說，作業系統向上層提供的 API 介面函式可以保持不變，這對應用程式開發來說是一件好事情。

（2）Xenomai

Xenomai是一個 Linux 核心的實時開發框架，它希望通過無縫地整合到 Linux 環境中來給使用者空間應用程式提供全面的，與介面無關的硬實時效能。下面是 Xenomai 的架構圖：

在硬體抽象層之上，是 2 個並列的域(核心)，這 2 個核心分別向上層提供自己的 API 介面函式。

圖中 glibc 是 Linux 系統提供的庫函式，應用程式通過呼叫庫函式和系統呼叫來編寫程式。

Xenomai 也提供了相應的庫函式 libcobalt ，這個庫函式是需要我們在使用者層編譯、安裝的，就像安裝第三方庫一樣。

此外，Xenomai 還參考不同的作業系統風格，提供了好幾套 API 函式(之前的說法是：皮膚)，API 介面函式在這裡：

從圖中可以看到，Alchemy API 這套介面提供的功能更完善，提供了：定時器、記憶體管理、條件變數、事件、互斥鎖、訊息佇列、任務(可以理解為執行緒)等 API 函式。
這一套 API 函式中具體的功能與 POSIX 標準大體相同，在一些細節上存在一些差異。

由於 Xenomai 嚮應用層提供的 API 函式是獨立的一套，因此，如果我們需要建立實時任務，那麼就要呼叫這一套介面函式來建立任務，包括使用其中的一些資源(例如：記憶體分配)。而且文件中也提出了一些注意點，例如：某些資源不能在 Xenomai 與 Linux 系統之間混用。

五、RTOS 的優勢

上面已經說到，Linux 桌面系統的主要目標是吞吐量，在單位時間內執行更多的程式碼。

但是對於微控制器來說，首要目標不是吞吐量，而是確定性，因此衡量一個實時作業系統堅固性的重要指標，是系統從接收一個任務，到完成該任務所需的時間。也就是說，任務排程才是第一考量要素。

在微控制器開發中，一般有 2 種程式設計模型：基於狀態機(裸跑)，基於 RTOS。

如果基於狀態機，就不存在任務排程問題了，因為只有一個執行序列，所有的操作都是序列執行的，唯一需要注意的控制流程就是中斷處理。

如果基於 RTOS，主要利用的就是任務排程，實現真正的硬實時。這方面最牛逼的就是VxWorks了，當然價格也是非常可觀的，有些公司購買之後，甚至會把除了任務排程模組之外的其他模組全部重寫一遍，這也足以證明了 VxWorks 在任務排程處理上的確很厲害，這也是它的看家本領!

當然，對於簡單、需要嚴格控制執行序列的關鍵程式來說，使用有限狀態機的程式設計框架，一切都在自己的掌握中。只要程式碼中沒有 bug，那麼理論上，一切行為都是在控制之中的，這也是為什麼很多軍事裝置上使用微控制器的原因！

六、總結

關於任務排程的問題，是一個作業系統的重中之重，其中需要學習的內容還有很多，最近剛買了一本陳海波老師的新書，也就是華為的鴻蒙系統背後的靈魂人物。

如果有新的學習心得，再跟大家分享。

參考文獻：

https://linuxfoundation.org/blog/intro-to-real-time-linux-for-embedded-developers/
https://wiki.archlinux.org/index.php/Realtime_kernel_patchset
http://www.faqs.org/faqs/realtime-computing/faq/
https://xenomai.org/documentation/xenomai-3/html/README.INSTALL/

好文章，要轉發；越分享，越幸運！