FreeRTOS 特性簡介

2021-09-30 12:02:07 字數 2971 閱讀 5028

url: 

freertos 由 richard barry 開發,是乙個開源的、可移植的、小型的嵌入式實時作業系統核心。freertos 既支援搶占式多工,也支援協作式多工。freertos的主要特性如下:

實時性:freertos 「可以」配置成為乙個硬(hard)實時作業系統核心。要注意這裡用的是「可以」,freertos 也可以配置為非實時型核心,甚至於部分任務是實時性的,部分不是。這一點比uc/os-ii 要靈活。

任務數量:freertos對任務數沒有限制,同一優先順序也可以有多個任務。這點上比uc/os-ii 好。

搶占式或協作式排程演算法:任務排程既可以為搶占式也可以為協作式。採用協作式排程演算法後,乙個處於執行態任務除非主動要求任務切換(yielding),否則是不會被排程出執行態的。

任務排程的時間點:排程器會在每次定時中斷到來時決定任務排程,同時外部非同步事件也會引起排程器任務排程。

排程演算法:任務排程演算法首先滿足高優先順序任務最先執行,當多於1個任務具有相同的高優先順序時,採用round robin 演算法排程。

任務間通訊:freertos 支援佇列和幾種基本的任務同步機制。

佇列:任務間傳遞資訊可以採用佇列方式,freertos 實現的佇列機制傳遞資訊是採用傳值方式,因此對於傳遞大量資料效率有些低。但可以通過傳遞指標的方式提高效率。中斷處理函式中讀寫佇列都是非阻塞型的。任務中讀寫佇列可以為阻塞型也可以配置非阻塞型。當配置為阻塞型時可以指定乙個阻塞的最大時間限(timeout)。

任務間同步:freertos 支援基本的訊號量功能。freertos 採用佇列來實現訊號量的功能,可以認為乙個值為n的訊號量就是乙個長度為n的佇列,佇列中每個元素的大小為0。這樣的佇列並不會浪費寶貴的記憶體空間。

對於死鎖(deadlock)的處理:freertos 並沒有實現一種可以完全避免死鎖的機制。只是通過指定乙個阻塞的最大時間限(timeout)來減少死鎖現象的發生。或者說是給出了當死鎖現象發生時解鎖的可能。當然能不能真的解鎖要依賴於使用者的處理**是否合適。

臨界區:freertos 採用開關中斷的方式實現臨界區保護。任務**中臨界區可以巢狀,freertos 會自動記錄每個任務中臨界區巢狀的層數。

暫停排程:與進入臨界區類似,freertos 可以通過暫時關閉任務排程來保證任務**不被更高優先順序的其他任務打斷,與臨界區不同,關閉任務排程並不會關閉中斷,這樣中斷處理函式仍會照常的執行。

記憶體分配:freertos 提供了多種記憶體動態分配的方法,具體程式中需要選擇其中一種。最簡單的記憶體分配方式提供了一種非常簡單的固定記憶體分配演算法,這種方式下只支援記憶體的分配,不支援分配記憶體的**。因此,任務建立後就不能被刪除。其他幾種記憶體分配演算法支援分配記憶體的**,有的方法支援鄰接記憶體塊的合併,有些不支援。對我個人來說,我還是比較欣賞uc/os-ii中記憶體分配的方法,既保證了實時性,也具有一定的靈活性。freertos 中提供的幾種方式,實時性好的功能上有缺陷,功能上完善的實時性卻不好。我通常採用的方式是採用最簡單的記憶體固定分配演算法,當需要動態釋放時將uc/os-ii中記憶體分配的**拿來用。

優先順序翻轉:freertos 沒有提供優先順序繼承機制或其他的避免優先順序翻轉的方法。

url: 

小型的實時作業系統,開源的,能夠應於多個硬體平台的,並不多!ucos和freertos,其他的,一堆在某個硬體平台的,尤其是8位系統裡面的一堆,就不說了!用起來,老說,沒有太多必要---8位微控制器本來就不適合使用作業系統,而作業系統最大的作用就是遮蔽底層,那就是最好能在多個硬體平台上使用才談得上遮蔽底層!只在乙個硬體平台上使用的,使用的時候不可不去了解底層,那就沒多少價值了,等於每次開始都是從頭開始!因此總覺的小型的作業系統,只有ucos和freertos比較有價值!其他的,不開源的,微控制器的作業系統,沒興趣去了解,當然使用的時候也不考慮用---不了解怎麼採用!

ucos基於優先順序排程,**公開,雖然是商業軟體,但是大家都可以拿到源**學習,這倒是不錯的!最初接觸嵌入式就是從ucos開始的!但是,還是對ucos不滿,優先順序固定,任務太少,每個優先順序只能有乙個任務,排程演算法單一,沒有定義乙個統一的驅動程式介面出來,做簡單的應用還可以,如果做複雜的,完全沒辦法。說實話,u-boot雖然是乙個bootloader,但是功能都比ucos強,如果加上排程演算法,管理一下記憶體,也比ucos好多了,只是u-boot是複雜系統才採用的東西!ucos2.8雖然擴充套件到256個任務,但是排程演算法很單一,而且又是商業軟體,沒有更多的人參與開發和擴充套件,這對它來說是很糟糕的!而ucos是基於8位發展起來的,出發思想什麼的,其實很受限!現在,不再看好ucos,也不想用ucos來做專案!

freertos的任務數量和排程演算法相對來說就好多了。基於優先順序排程,任務對應用來說是無限---隨便說說而已,只是說足夠使用或是遠遠用不完,16位的數量,無限了,相對ucos來說更是,而乙個優先順序可以有多個任務,相同優先順序採用輪換排程來執行!比較起來,好了很多!但是freertos很糟糕的一點是命名,看起來是很有規則,可是又臭又長,讓人受不了!gpl發布的軟體採用匈牙利命名法,名字長的讓人討厭。而檔案的組織形式又感覺凌亂!致命的問題:沒有為驅動定義乙個標準的介面來!

我需要乙個小型的作業系統---執行在16位和32位的微控制器上,有標準的驅動介面,帶一堆驅動,至少該包含uart、spi、i2c、usb、net的,其他的i2s之類的,有最好,任務數要很多,排程演算法應該可選擇,能夠使用gcc來編譯,還有一點,命名方式一定要簡潔明瞭,堅決不能又臭又長!不過現在看來找不到!自己寫乙個?也許,只是也許能夠寫出來,雖然對作業系統很了解,但是很多東西,很煩的,而且時間需要很多的,偶要為生活奔波,哪有那麼多時間!衡量了一下,改造freertos是最合適的辦法!改造了再安gpl協議發布,這是最好的方式!從命名方式到排程方式,然後定義乙個標準的驅動介面和管理方式!8位微控制器,不考慮包含了,我的應用只能使用16位和32位才能完成!

ThreadStatic特性簡介

在程式中,類的靜態成員變數 c static vb shared 在使用時,會在該類的多個例項之間共享。在多執行緒場合下,也不例外。有些讀者或許會想到如何建立每個執行緒自己的靜態變數呢,這裡threadstaticattribute就提供了一種十分簡單的方法。可以通過追加自定義特性 c thread...

kafka基本特性簡介

kafka是linkedin開發的用於日誌資料處理的流式訊息處理系統。官網上說kafka is a distributed partitioned replicated commit logservice.這句話充分體現了kafka的特性。kafka是首先是乙個用於處理流式資料的日誌處理系統,然後他...

Qt基本特性簡介

qt不只是介面庫,qt提供了功能豐富的c 類庫,比如網路程式設計,資料庫查詢,xml解析,md5加密等 從系統得到的訊息,比如滑鼠,鍵盤等。qt事件迴圈的時候讀取這些事件,轉換為qevent後依次派發到對應視窗進行處理。從低到高逐漸可以分為如下步驟 qmetaobject connection co...