FreeRTOS入門-概念介紹

開始前，先拋出一個問題：我們為什么需要操作系統？比如你使用計算器進行加減乘除等運算，人按鍵輸入，最后計算器液晶屏顯示結果，這只是一個單任務的操作，并且人的速度很慢，計算器大部分時間都在空閑等人。如果一個計算器連出來10個鍵盤，讓10個人同時使用，這個時候就需要一個操作系統來協調，這么看來操作系統首先需要一個調度器，如上圖，這樣多個任務就可以同時運行了，其次還需要對各個任務需要的硬件資源進行管理，比如硬盤、內存、網卡，另外還需要支持任務間的通信。如下圖，傳統操作系統的五大模塊：

1. 操作系統分類

操作系統一般可分為三種基本類型，即批處理系統、分時系統和實時系統。另外其他擴展的網絡操作系統、分布式操作系統、嵌入式操作系統等。

1.1批處理操作系統

就是把任務匯總到一塊，按順序排好，然后讓計算機一個一個處理，這樣計算機一次處理一批任務，空閑的時間就比較少了。其實就是把調度的工作讓人干了，匯總任務是需要人工做的，沒有調度這感覺不是操作系統，這現在已經不存在了，在計算機發展的早期還有。

1.2分時操作系統

所謂分時技術就是把處理器的運行時間分成很短的時間片，按時間片輪流把處理器分配給各聯機作業使用。若某個作業在分配給它的時間片內不能完成其計算，則該作業暫時停止運行，把處理器讓給其他作業使用，等待下一輪再繼續運行。由于計算機速度很快，作業運行輪轉得很快，給每個用戶的感覺好像是自己獨占一臺計算機。例如個人電腦里面的Windows、Linux，手機里面的安卓等都是分時操作系統，也是我們說的普通操作系統。

1.3實時操作系統

實時操作系統(RealTimeOperatingSystem，RTOS)是指使計算機能及時響應外部事件的請求在規定的嚴格時間內完成對該事件的處理，并控制所有實時設備和實時任務協調一致地工作的操作系統。實時操作系統從調度器算法，到中斷響應系統，到消息傳遞機制等所有的核心算法時間復雜度都是O（1），它表示系統的響應速度不依賴于系統任務的多少，負載的輕重，而只依賴于優先級的設計，就算當前系統滿負荷運行，優先級高的事件發生后，系統還將會在指定的時間內立即響應事件。

這里的時間限制可以分為兩種情況：如果某個動作必須絕對地在規定的時刻（或規定的時間范圍）發生，則稱為硬實時系統。例如，飛行器的飛行自動控制系統，這類系統必須提供絕對保證，讓某個特定的動作在規定的時間內完成。如果能夠接受偶爾違反時間規定，并且不會引起任何永久性的損害，則稱為軟實時系統，如飛機訂票系統、銀行管理系統。

我們AUTOSAR CP里面的RTOS就需要硬實時的操作系統。因為對于汽車的控制是需要及時的，不然可能造成事故，正所謂：人命關天。

1.4其他操作系統

隨著計算機體系結構的發展，又出現了許多種操作系統，它們是嵌人式操作系統、個人操作系統、網絡操作系統和分布式操作系統。

網絡操作系統把計算機網絡中的各臺計算機有機地結合起來，提供一種統一、經濟而有效的使用各臺計算機的方法，實現各個計算機之間的互相傳送數據。

分布式計算機系統是由多臺計算機組成并滿足下列條件的系統：系統中任意兩臺計算機通過通信方式交換信息；系統中的每一臺計算機都具有同等的地位，即沒有主機也沒有從機；每臺計算機上的資源為所有用戶共享；系統中的任意若千臺計算機都可以構成一個子系統，并且還能重構；任何工作都可以分布在幾臺計算機上，由它們并行工作、協同完成。

最后匯總一個圖：

2.OSEK OS

OSEK OS是一個為滿足汽車電子可靠性、實時性、成本敏感性等需求而打造的實時單核操作系統(RTAOS)。具備以下基本特性以及基本系統服務：

AUTOSAR OS是基于OSEK OS繼承發展而來，所以上述的OSEK OS的基本特點在AUTOSAR OS都能夠得到滿足，所以AUTOSAR OS是向后兼容的，也就意味著在OSEK OS上能夠運行的應用程序同樣也可以在AUTOSAR OS上運行。

AUTOSAR OS繼承OSEK OS，在OSEK OS的基礎上又特別明確了AUTOSAR OS至少需要提供的系統服務如下：

基于優先級的調度；

及時的中斷處理的能力；

中斷優先級必定高于task；

通過StartOS（） 與StartOSHook（）來創建啟動接口；

通過ShutdownOS() 與ShutdownOSHook來創建關機接口；

能夠在OSEK OS中跑的APP自然也能夠在AUTOSAR OS運行，但同時Autosar os也同時限制了OSEK OS的一些基本使用；

3.AUTOSAROS

3.1 AUTOSAR OS基本對象

AUTOSAR OS總共包含以下6大基本對象：Counter，Alarm，Schedule Table，Task，ISRs，Resource。

這6個基本對象必須歸屬于一個OS Application，可以簡單理解為OS Application是上述6大基本對象的容器，而歸屬于同一OS Application的基本對象則可以互相訪問，來自其他OSApplication的基本對象則需要通過配置來限制性訪問。

3.2 Task

大家在面試的時候被經常問到的一個問題就是進程和線程的區別，最典型的回答就是進程是系統資源分配的最小單位，比如分配了內存地址空間、寄存器、獨占的虛擬CPU等，線程是CPU調度的最小單位，線程享用父進程的系統資源，但是自己又可以異步的去執行。

可惜在RTOS里面由于要求實時性，這種異步執行需要等待的機制需要被砍掉，首先沒有了線程的概念。那么進程就是對應RTOS里面的Application，并且這個Application的資源都是獨占的，不進程一樣跟其他進程共享的。例如獨占一個真實的CPU，這里也叫做MCU，因為性能沒那么強悍，但是很穩定。有例如獨占一塊真實的內存區域，也就是說其資源是啟動前就靜態分配好的，不跟其他Application共享的，這里就是靜態系統的概念。

而傳統操作系統里面的進程就是動態系統，動態系統資源共享降低了實時性和安全性來提升資源利用率，在AUTOSAR AP中的微內核OS中會用到，主要支持一些對安全實時性要求不高的應用。

接下來說本章節的TASK，可以理解為一個for循環，順序一遍一遍的去執行的列表中的任務。這些任務組成了一個Application。

AUTOSAR OS中存在兩種任務：

基本任務(Basic Task)和擴展任務（Extended Task）。

基本任務則存在以下三種狀態：

運行狀態(Running)：處于運行狀態的任務可能被高優先級任務或者中斷搶占從而進入就緒狀態，且同一Core中任何時刻只會存在一個任務處于運行狀態，任務運行結束后則將自己掛起進入阻塞狀態；

就緒狀態(Ready):處于就緒狀態的任務由調度器決定是否啟動進入運行狀態，且該狀態時任務切換至運行狀態的前提；

阻塞狀態(Suspend):處于阻塞狀態的任務是被動的，可以由API函數或Alarm激活進入就緒狀態；

擴展任務與之相比，則多了一個等待狀態(Waiting),解釋如下：

等待狀態(Waiting)：當任務的運行需要等待某一或某些事件被置位時，任務進入就緒狀態。

基本任務與擴展任務的狀態機切換如下圖所示：

基本任務的代碼示例如下：

擴展任務的代碼示例如下

Task調度策略

AUTOSAR OS可根據各個任務的可搶占屬性配置，來提供不同的調度策略，調度策略可分為以下三種：

完全搶占式：OS所有任務均是可搶占類型；

非搶占式：OS中所有任務均是不可搶占的；

混合搶占式：OS部分任務是可搶占類型，部分任務是不可搶占類型；

3.3 Counter

Counter概念的引入是為了實現對硬件計數器以及軟件計數器的管理，為Alarm與Schedule table提供支持。即多個Alarm可以共用一個Counter，一個Schedule Table只能由一個Counter來驅動。Counter按照AUTOSAR定義可分為以下兩種：

Hardware Counter:該Counter的增加由硬件外設驅動，如Gpt或者timer等；

Software Counter：該Counter的增加通過調用API函數IncrementCounter來實現，且每次只能增加1；

基本原則：優先使用Hardware Counter，因為可以根據Task的激活狀況來減少無意義的時鐘中斷；

3.4 Alarm

在計數器的基礎上，AUTOSAR OS為應用軟件提供了鬧鐘機制，多個鬧鐘可以連接一個Counter，當到達Alarm所對應的計數器設定值時，則可以激活一個任務，設定一個event，調用callback或者增加計數器等功能，但只能是一對一。

不能像Schedule Table那樣，能夠在Expiry point同時設定多個Task或者多個Event，這也是為什么引入Schedule Table的原因。

一個軟件Counter +多個Alarm隊列就可以實現靜態定義的任務激活機制。但隨著Schedule Table的引入，因此一般建議能用Schedule Table就不要用Alarm。

3.5 Schedule Table

如上Alarm所述，當計數器的計數值依次達到各個Alarm設定的計數值時，各個Alarm被觸發，但很難保證各個Alarm有特定的時間間隔，且每個Alarm只能激活一個Task或者Event，所以需要多個Alarm來協作實現在同一時刻觸發多個Task或者Event，因此ScheduleTable應運而生！

Schedule Table會定義一系列終結點(Expiry Point)，且每個調度表都有一個以Tick為單位的持續時間(Duration)。每個終結點則是以Tick為單位的距離起始點的偏移量(Offset)，在每個終結點可以實現多個Task或者Event的設置。

與報警器類似，一個調度表只能由一個Counter驅動，同時調度表存在以下兩種調度方式：

單次執行(Single-Shot):調度表啟動之后 只運行一次，到達調度表終點則終止，即每個終結點只運行一次；

循環執行(Repeating):調度表啟動后可反復執行，到達調度表終點后重頭開始執行，則每個終結點會被周期性的執行，一般情況下激活任務采用此模式。

如下圖10所示，較為清晰了描述了調度表中Expiry Point與Task，Event激活之間的時序關系。

如下圖所示，則較為清晰的表現了Counter，Schedule Table以及Alarm三者之間的關系。

3.6 ISRs

在AUTOSAR中定義了兩類中斷服務程序(Interrupt Service Routine)為：

一類中斷(CategoryI)與二類中斷(Category)。

兩者之間的區別定義如下：

Categoty I：此類中斷服務程序不能夠使用OS提供的系統服務，當中斷執行完成之后則會重新跳轉至產生中斷的地方繼續執行，不會影響到任務的執行，因此占用系統資源較少。

Category II：該類中斷則可以調用OS系統服務，如激活任務或者設置事件等。

在AUTOSAR OS中，中斷的優先級始終高于任務的優先級，即最低優先級的中斷都可以打斷最高優先級的任務，即使該任務不可搶占也不例外。因此，中斷服務子程序的執行時間不宜過長，否則會影響到整個系統的實時性。

3.7 Resource Management

Resouce作為OS調度過程中一個十分重要的對象，Resource管理就顯得尤為重要。資源管理就是為了協調具有不同優先級的多個任務或者中斷對共享內存（如內存或者硬件等）的并發訪問。

不過幸運的是AUTOSAR OS采用上述的優先級天花板模式來避免任務優先級反轉以及死鎖問題的發生，即資源的上限優先級必須高于所有該資源的任務以及中斷的優先級，但是應低于不訪問該資源的任務的最低優先級。

其中為了保護共享資源而提出的鎖機制-自旋鎖(Spin Lock)。該自旋鎖一般用于多核操作系統解決資源互斥的問題。當內核控制必須訪問共享數據結構或進入臨界區是，如果自旋鎖已經被別的執行單元保持，調用者就一直循環在那里看是否該自旋所的保持者已經釋放了該鎖，從而達到某共享資源的互斥作用。

4. AS代碼中的RTOS

AS代碼：里面是有RTOS的，是作者自己寫的一個叫做askar，同時里面還有FreeRTOS等十個左右的RTOS，下次文章再介紹。

后記：

最比較忙近停更了一段時間，但是公眾號的事一直在心里。9月是開學季，也是學習的好時節，接下來再接再厲，先寫一系列OS入門的文章，直接介紹五六種OS的入門資料，絕對夠猛夠有料，敬請期待。

審核編輯：劉清