一、前言
1. 單片機
2. 嵌入式系統
3. 嵌入式 Linux三、非實時、軟實時、硬實時
四、x86 Linux 系統的調度策略
1. 為什么 Linux 系統是軟實時?
2. Linux 系統如何改造成硬實時?
(1) RT-Preempt
(2) Xenomai五、RTOS 的優勢
六、總結一、前言前幾天和一個在某研究所的發小聊天,他說:現在的航空、航天和導彈等武器裝備中,控制系統幾乎都是用單片機,而不是嵌入式系統。
乍一聽,和我們的直覺有矛盾啊:那么高大上的設備,其中的控制邏輯一定很復雜,不用嵌入式系統怎么來完成那么復雜的功能控制啊?然后仔細了解了一下,才明白答案是:安全+可控。
這篇文章我們就來聊一下關于單片機與嵌入式、操作系統與 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 種調度策略:
1. SCHED_OTHER: 系統默認的調度策略,計算動態優先級(counter+20-nice),當時間片用完之后放在就緒隊列尾;
2. SCHED_FIFO: 實時調度策略,根據優先級進行調度,一旦占用CPU就一直執行,直到自己放棄執行或者有更高優先級的任務需要執行;
3. 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,那么理論上,一切行為都是在控制之中的,這也是為什么很多軍事設備上使用單片機的原因!
六、總結關于任務調度的問題,是一個操作系統的重中之重,其中需要學習的內容還有很多,最近剛買了一本陳海波老師的新書,也就是華為的鴻蒙系統背后的靈魂人物。
如果有新的學習心得,再跟大家分享。
原文標題:What,航天器、導彈喜歡用單片機?為什么不是嵌入式系統?
文章出處:【微信公眾號:嵌入式ARM】歡迎添加關注!文章轉載請注明出處。
責任編輯:haq
-
單片機
+關注
關注
6037文章
44563瀏覽量
635888 -
嵌入式
+關注
關注
5085文章
19138瀏覽量
305708 -
操作系統
+關注
關注
37文章
6838瀏覽量
123380
原文標題:What,航天器、導彈喜歡用單片機?為什么不是嵌入式系統?
文章出處:【微信號:gh_c472c2199c88,微信公眾號:嵌入式微處理器】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論