URL: http://blog.csdn.net/liyuanbhu/article/details/7911163
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 沒有提供優先級繼承機制或其他的避免優先級翻轉的方法。
小型的實時操作系統，開源的，能夠應於多個硬件平臺的，並不多!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位才能完成！
