姓名：姜思維? ? ? ? ?學(xué)號：19020100333? ? ? ? 學(xué)院：電子工程學(xué)院

轉(zhuǎn)自：https://blog.csdn.net/weixin_41213648/article/details/88249890?spm=1001.2014.3001.5501

【嵌牛導(dǎo)讀】uC/OS-III&FreeRTOS區(qū)別

【嵌牛鼻子】uC/OS-III? ? ?FreeRTOS? ? 區(qū)別

【嵌牛提問】什么是uC/OS-III和FreeRTOS的區(qū)別荠医？

【嵌牛正文】

1、uCOS-III中所有的內(nèi)核對象（如任務(wù)控制塊、消息隊(duì)列、信號量等）都是靜態(tài)創(chuàng)建的斋射，需要用戶提供纠吴。FreeRTOS中的內(nèi)核對象支持動態(tài)和靜態(tài)兩種創(chuàng)建方法。

（PS： 其實(shí)系統(tǒng)提不提供動態(tài)創(chuàng)建功能并不那么重要力细，因?yàn)樵陟o態(tài)創(chuàng)建的方法的基礎(chǔ)上加入內(nèi)存管理機(jī)制系枪，就能自已封裝實(shí)現(xiàn)動態(tài)創(chuàng)建函數(shù)）

2雀哨、uCOS-III中的任務(wù)狀態(tài)較多，因?yàn)樗嬖凇盎緺顟B(tài)+掛起狀態(tài)”這類狀態(tài)嗤无，F(xiàn)reeRTOS中掛起態(tài)是個單獨(dú)的狀態(tài)震束。在FreeRTOS中，如果suspend一個正在阻塞的任務(wù)当犯，API內(nèi)部會把任務(wù)從相應(yīng)阻塞表中刪除垢村，并將其掛在xSuspendedTaskList上，當(dāng)該任務(wù)被resume后嚎卫，它就是就緒態(tài)嘉栓，而不會重新返回阻塞態(tài)。而uCOS-III中的任務(wù)即便在阻塞時被suspend了拓诸，它依然處于阻塞態(tài)（即等待某個事件發(fā)生）侵佃，如果在suspend的過程中事件發(fā)生了，它將解除阻塞態(tài)奠支，變?yōu)榧兇獾膾炱饝B(tài)馋辈；如果在resume后，該事件仍未發(fā)生倍谜，它將解除掛起態(tài)迈螟，變?yōu)樽枞麘B(tài)。

（PS： 我感覺uCOS-III中的“掛起”更能稱之為“掛起”）

3尔崔、為了實(shí)現(xiàn)中斷和任務(wù)的同步答毫，需要在中斷中進(jìn)行post操作，uC/OS-III為了減少中斷執(zhí)行的時間季春，提高系統(tǒng)中斷響應(yīng)的實(shí)時性洗搂，設(shè)計(jì)了OS_tickTask和OS_IntQTask，這樣原本在中斷里需要進(jìn)行的一些較為耗時的操作就被放到了任務(wù)級代碼中執(zhí)行了载弄。而FreeRTOS并沒有這樣的設(shè)計(jì)耘拇。

（PS： 我覺得，從這一點(diǎn)上侦锯，可以看出uC/OS-III的實(shí)時性要比FreeRTOS好驼鞭。

另外，可能有的同學(xué)不理解為什么中斷執(zhí)行時間少了尺碰，系統(tǒng)的實(shí)時性就好了挣棕。這是因?yàn)橄到y(tǒng)實(shí)時性的一個關(guān)鍵指標(biāo)就是中斷延遲響應(yīng)的時間。某個中斷可能會被延遲響應(yīng)的時間亲桥，受系統(tǒng)關(guān)中斷時間的影響洛心，也會受其它同等優(yōu)先級或者高優(yōu)先級中斷執(zhí)行時間的影響，所以減少某個中斷的執(zhí)行時間题篷，將有助于減少其它中斷的延遲響應(yīng)時間）

4词身、uC/OS-III和FreeRTOS的任務(wù)切換都是利用的PendSV中斷。

? ? ? ? 在FreeRTOS的PendSV中斷中番枚，它會計(jì)算就緒的最高優(yōu)先級的任務(wù)法严，再去進(jìn)行上下文切換损敷。而uC/OS-III在觸發(fā)PendSV中斷前，會計(jì)算好已就緒的最高優(yōu)先級的任務(wù)深啤，放在OSTCBHighRdyPtr中拗馒，這樣在PendSV中斷中就不用計(jì)算就緒的最高優(yōu)先級的任務(wù)是誰了。所以uC/OS-III中PendSV中斷的執(zhí)行時間更短溯街，這有利于提高系統(tǒng)的實(shí)時性诱桂。

5、uCOS-III的任務(wù)操作句柄就是任務(wù)控制塊TCB的指針呈昔。FreeRTOS中單獨(dú)設(shè)置了任務(wù)操作句柄這種數(shù)據(jù)類型挥等，它實(shí)質(zhì)上也是TCB的指針。表面上看堤尾，多此一舉肝劲，但其實(shí)這種設(shè)計(jì)對用戶是友好的，用戶不需要了解TCB這種內(nèi)核數(shù)據(jù)結(jié)構(gòu)的存在郭宝，就可以操作任務(wù)了涡相。

6、對于時間片輪轉(zhuǎn)調(diào)度的功能剩蟀。

? ? ? ? FreeRTOS是每個時間片（即每個systick中斷里）發(fā)生同優(yōu)先級的任務(wù)切換催蝗。

? ? ? ? 而uCOS-III中每個任務(wù)能保持的時間片可以單獨(dú)設(shè)置，需要在任務(wù)初始化時作為形參傳入育特。這樣做的壞處是對用戶不太友好（API的形參如果太多丙号，應(yīng)用開發(fā)人員接受起來有些麻煩）；這樣做的好處是不會在每個時間片都發(fā)生任務(wù)的切換（任務(wù)切換是需要開銷的）缰冤，提高了總的CPU利用率犬缨。

? ? ? ? 另外，uC/OS-III中棉浸，由于可以對每個任務(wù)的時間片分別進(jìn)行設(shè)置和修改怀薛，所以可以很方便地調(diào)節(jié)同優(yōu)先級下每個任務(wù)的CPU占用率，盡管兩個任務(wù)的優(yōu)先級是一樣的迷郑，但是有個任務(wù)比較重要枝恋，我們希望讓它的CPU占用率高一點(diǎn)，這時只要把它的時間片設(shè)置得大一點(diǎn)即可嗡害。而在FreeRTOS中同優(yōu)先級下的每個任務(wù)對CPU的占用率都只能是一樣的焚碌。

7、uCOS-III內(nèi)核中的鏈表大多是不循環(huán)的雙向鏈表（有頭有尾）霸妹，在插入和刪除操作時十电，要考慮特殊情況（比如插入表頭、插入表尾等特殊情況）。

? ? ? ? 而FreeRTOS內(nèi)核中的鏈表為雙向循環(huán)鏈表鹃骂，并引入了xListEnd保證了鏈表永遠(yuǎn)非空台盯，所以每個元素的插入和刪除都是作為表中的一般元素（非表頭和表尾）進(jìn)行的，操作效率要比uC/OS-III高一些畏线。

8爷恳、對于修改任務(wù)優(yōu)先級的操作，F(xiàn)reeRTOS和uCOS-III都是可選項(xiàng)象踊。

? ? ? ? 對于uCOS-III，在修改任務(wù)優(yōu)先級時棚壁，如果任務(wù)處于阻塞態(tài)杯矩，內(nèi)核會將pend_data從阻塞對象的pend_list上刪除，并重新按照新的任務(wù)優(yōu)先級插入袖外，即調(diào)用OS_PendListInsertPrio()史隆。

? ? ? ? 而FreeRTOS對于修改阻塞態(tài)的任務(wù)的優(yōu)先級，似乎只是修改了TCB里的優(yōu)先級字段就完事兒了曼验，這點(diǎn)雖然不會造成較大的影響泌射，但是違背了“優(yōu)先級高的任務(wù)優(yōu)先獲得阻塞對象”的設(shè)計(jì)原則。不知這是否是bug鬓照。

9熔酷、uCOS-III的信號量是沒有上限的，只要post豺裆，它的信號量值就會增加（不能溢出）拒秘。而FreeRTOS中的信號量基于Queue_t實(shí)現(xiàn)，其隊(duì)列容量（uxLength）將作為信號量的上限臭猜。

10躺酒、uCOS-III支持PendAbort，而FreeRTOS不支持蔑歌。

11羹应、uCOS-III中的軟件定時器是靠對systick分頻實(shí)現(xiàn)的，與OS_TickTask運(yùn)行原理類似次屠，都采用的哈希散列表組織定時器园匹。

? ? ? ? FreeRTOS中的定時器是按照超時時間組織成了有序鏈表。prvTimerTask與LwIP中的tcpip_thread一樣劫灶，每次都試圖按照當(dāng)前超時鏈表上的最近超時時間阻塞在queue上偎肃。

? ? ? ? FreeRTOS的定時器機(jī)制，單獨(dú)設(shè)計(jì)了一個queue浑此，所有Timer相關(guān)的API（函數(shù)或宏）本質(zhì)上都是對該queue的一次消息投遞累颂，由prvTimerTask來完成對消息的解析并處理。這樣做的好處就是：只在一個線程中進(jìn)行與Timer相關(guān)數(shù)據(jù)的操作，省去了互斥帶來的開銷紊馏。

13料饥、uCOS-III的許多API，都設(shè)計(jì)了OS_ERR* 的參量朱监，它可以用來向應(yīng)用程序傳遞許多出錯信息岸啡，雖然這會增加API的復(fù)雜度，給應(yīng)用程序開發(fā)人員帶來一些麻煩赫编。比如OSQueuePend巡蘸，通過&err，我們可以知道這次pend操作是成功還是失敗的擂送，如果失敗悦荒，是怎么失敗的（比如：超時、隊(duì)列被刪除嘹吨、隊(duì)列被PendAbort等）搬味。有的人可能會說，只要觀察函數(shù)返回值蟀拷，就可以知道此次pend操作時成功還是失敗的碰纬，沒必要設(shè)置OS_ERR* 這個參量。但是這樣做無法得知失敗的具體原因问芬。

? ? ? ? FreeRTOS在設(shè)計(jì)API時就沒有設(shè)計(jì)這個錯誤參量悦析，應(yīng)用程序開發(fā)人員只能通過API函數(shù)的返回值來判斷操作是否成功，但是如果失敗此衅，則無法得到更多的關(guān)于失敗的信息她按。

（PS： 從這一點(diǎn)上可以看出，uC/OS-III提供了更健壯的內(nèi)核）

14炕柔、對于消息隊(duì)列酌泰，uCOS-III只支持出隊(duì)阻塞，不支持入隊(duì)阻塞匕累，即OSQueuePost這個函數(shù)在消息隊(duì)列已滿的情況下陵刹，不會自已阻塞去等待隊(duì)列里騰出空間，而是直接返回郵箱已滿的錯誤信息欢嘿，用戶需要及時檢查返回的錯誤碼衰琐，進(jìn)行處理。

FreeRTOS中即支持出隊(duì)阻塞炼蹦，也支持入隊(duì)阻塞羡宙。

（PS： 在uC/OS-III中盡管不支持post阻塞，但如果必須實(shí)現(xiàn)post阻塞（比如LwIP移植中的sys_arch_mbox_post接口實(shí)現(xiàn)）也是很容易的掐隐，只要利用信號量和消息隊(duì)列再加上一個阻塞隊(duì)列專門用來記錄等待post的任務(wù)即可狗热，這是對uC/OS-III內(nèi)核進(jìn)行二次開發(fā)）钞馁。

15、uC/OS-III使用消息指針代表消息匿刮，F(xiàn)reeRTOS使用消息內(nèi)容的完整備份代表消息僧凰，在uC/OS-III中，投遞了消息以后熟丸，要保證該指針在消息被利用前一直有效（即保證消息內(nèi)容不被刪除训措、覆蓋），在FreeRTOS中則無所謂光羞，另外在FreeRTOS中也可以將消息指針當(dāng)做消息內(nèi)容傳遞绩鸣，這樣就可以模擬出跟uC/OS-III一樣的效果了。

如此看來纱兑，F(xiàn)reeRTOS的消息設(shè)計(jì)更加靈活呀闻。但是要注意，使用指針的好處是避免消息的拷貝萍启，這可以提高內(nèi)核的處理效率，尤其是消息內(nèi)容較大或者消息需要輾轉(zhuǎn)多個消息隊(duì)列的時候屏鳍。所以我覺得像uC/OS-III這樣設(shè)計(jì)就挺好的勘纯，沒必要考慮其他情況。另外钓瞭，uC/OS-III的消息是以O(shè)S_MSG結(jié)構(gòu)體存在的驳遵，里面除了消息指針以外，還包含了時間戳山涡，提供了更豐富的信息堤结。不過要注意，由于它使用了OS_MSG結(jié)構(gòu)體承載消息鸭丛，而OSQueuePost函數(shù)內(nèi)部是通過預(yù)先定義好的OS_MSG結(jié)構(gòu)體內(nèi)存池去獲取這種結(jié)構(gòu)的竞穷，所以需要用戶在編譯工程代碼時根據(jù)自己使用到的消息的規(guī)模去配置內(nèi)存池大小，一些人以為從uC/OS-II過渡到uC/OS-III的好處就是再也不用事先配置每種內(nèi)存池的大小了（當(dāng)應(yīng)用需求變化鳞溉，總是需要調(diào)整瘾带，比較麻煩），但千萬別忘了有一個（也是唯一一個）內(nèi)存池需要提前配置好大小熟菲。

16看政、在消息投遞時，如果有任務(wù)在消息隊(duì)列的pend列表中等待抄罕，uC/OS-III的做法是直接將該消息post給等待的任務(wù)并把它就緒允蚣，整個消息不會經(jīng)過消息隊(duì)列。而FreeRTOS的做法是將該消息放置到消息隊(duì)列中呆贿，然后檢查是否有任務(wù)正等待接收消息嚷兔，如果有，就將其就緒，由就緒的任務(wù)去主動獲取該消息谴垫。

FreeRTOS的做法實(shí)現(xiàn)了投遞消息與取出消息的解耦章母，但這帶來了一個問題，就是當(dāng)某個任務(wù)投遞完一個消息翩剪，并使A任務(wù)就緒了乳怎，而在A任務(wù)執(zhí)行前，又有一個高優(yōu)先級的B任務(wù)從這個消息隊(duì)列中取出了該消息前弯，那么A任務(wù)在以后試圖從消息隊(duì)列中取出消息時蚪缀，會出現(xiàn)失敗，這是FreeRTOS中所有內(nèi)核對象的pend操作都可能會出現(xiàn)的情況恕出，內(nèi)核的做法是會重新計(jì)算超時時間询枚，只要沒超時，就重新阻塞（按新的阻塞時間）浙巫，這種設(shè)計(jì)會降低內(nèi)核的執(zhí)行效率金蜀。在uC/OS-III中，每一次的消息post操作的畴，要么消息被post到了消息隊(duì)列上渊抄，要么消息被post給了任務(wù)，操作結(jié)果是明確的丧裁，操作過程是高效的护桦。

（PS： 我覺得，從這一點(diǎn)可以看出uC/OS-III的內(nèi)核要比FreeRTOS具有更好的效率煎娇、行為可預(yù)測性）

17二庵、uCOS-III的pend函數(shù)用opt字段區(qū)分是try pend還是block pend，如果是block pend缓呛，可設(shè)置超時時間催享，如果超時時間為0，則代表永久pend哟绊。

? ? ? ? FreeRTOS的pend函數(shù)沒有opt字段睡陪，只有超時字段，如果它為0匿情，則表示不等待兰迫，為try pend，如果為其他值炬称，則它為超時時間汁果，如果它為最大值（portMAX_DELAY），并且配置文件中使能了suspend task的功能玲躯，則portMAX_DELAY表示永久等待据德，如果沒使能鳄乏，則表示portMAX_DELAY個ticks將作為超時時間。

? ? ? ? 可見FreeRTOS中棘利，在不使能task suspend的情況下橱野，是不允許有任務(wù)永久阻塞的（可能是為了應(yīng)用程序的安全性考慮）。

18善玫、FreeRTOS提供了TaskNotify機(jī)制水援，用它可以更輕便地實(shí)現(xiàn)：單對單或多對單的簡單同步和通信功能。在uC/OS-III中雖然沒有TaskNotify機(jī)制茅郎，但是提供了TaskSem和TaskQueue機(jī)制蜗元，可以完成同樣的效果。

（PS： 為了跨系統(tǒng)的可移植性系冗，最好不要使用這些特殊機(jī)制）

總結(jié)：FreeRTOS功能更豐富奕扣、更易用；uC/OS-III的實(shí)時性更好掌敬、效率更高惯豆、健壯性更好。

? ? ? ? 其實(shí)RTOS最主要的功能就是任務(wù)調(diào)度奔害，其它功能都可以自己開發(fā)楷兽，難度不大。單獨(dú)從任務(wù)調(diào)度器的角色出發(fā)去對比這兩個RTOS舀武，我覺得uC/OS-III更漂亮拄养、更優(yōu)秀离斩。

? ? ? ? uC/OS-III通過的安全認(rèn)證比FreeRTOS要多银舱，F(xiàn)reeRTOS的代碼書寫是不符合一些標(biāo)準(zhǔn)的。在FreeRTOS的基礎(chǔ)上建立了另外兩個RTOS：SafeRTOS跛梗、OpenRTOS寻馏，它們具有更好的安全性，通過了更多的檢驗(yàn)和標(biāo)準(zhǔn)核偿，但是與FreeRTOS不一樣诚欠，需要收費(fèi)。

? ? ? ? 在過去EETimes的RTOS市場占有率調(diào)查中漾岳，F(xiàn)reeRTOS常年穩(wěn)居第一轰绵，這與它完全免費(fèi)、開源社區(qū)比較活躍的特點(diǎn)有關(guān)尼荆。再加上FreeRTOS的創(chuàng)始團(tuán)隊(duì)現(xiàn)在與亞馬遜合作左腔，F(xiàn)reeRTOS的系統(tǒng)功能將更加豐富，將擁有更多商業(yè)合作伙伴捅儒，用戶數(shù)量群將繼續(xù)擴(kuò)大液样，目測FreeRTOS的發(fā)展前景會更好振亮。

————————————————

版權(quán)聲明：本文為CSDN博主「JiandaoStudio」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議鞭莽，轉(zhuǎn)載請附上原文出處鏈接及本聲明坊秸。

原文鏈接：https://blog.csdn.net/weixin_41213648/article/details/88249890