UC/OS是一種免費公開源代碼、結構小巧、具有可剝奪實時內核的實時操作系統。其內核提供任務調度與管理、時間管理、任務間同步與通信、內存管理和中斷服務等功能。
UClinux是一種優秀的嵌入式Linux版本。uClinux是Micro-Conrol-Linux的縮寫。同標準Linux相比，它集成了標準Linux操作系統的穩定性、強大網絡功能和出色的文件系統等主要優點。但是由於沒有MMU（內存管理單元），其多任務的實現需要一定技巧。
萬事入門難，入門之後就好辦了
意義
隨着電子產品和設備的應用的複雜化和智能化，原來在電子產品中佔統治地位的單片機和較簡單的程序結構已經難以滿足要求。加之微處理器芯片本身性 能的大幅提高，對軟件的要求也隨之提高，而實時操作系統（Real Time Operation System，以下簡稱爲RTOS）很好滿足了這些需 求
原來一直用單片機，06年纔開始接觸ARM。開始一直是用前後臺的編程方法，順序執行，感覺也挺好，但是程序任務多了以後，調試比較麻煩。在網上查查資料，看大家都在用ucos，也就嘗試着用。
區別
以往是順序執行，中斷處理，狀態機
工作核心原理是：
讓最高優先級的任務處於運行狀態。
這需要操作系統在某個時間得運行任務調度的一個算法（操作系統提供了這個函數），她將自動完成調度運算並完成任務的切換。
調度操作在下面情況中將被運行：調用api函數（用戶主動調度），中斷（系統、用戶的）
Ucos
免費，VxWorks收費
ucos ii和大家所熟知的Linux等分時操作系統不同，它不支持時間片輪轉法。ucos ii是一個基於優先級的實時操作系統，每個任務的優 先級必須不同，分析它的源碼會發現，ucos ii把任務的優先級當做任務的標識來使用，如果優先級相同，任務將無法區分。進入就緒態的優先級最高的任務 首先得到CPU的使用權，只有等它交出CPU的使用權後，其他任務纔可以被執行。所以它只能說是多任務，不能說是多進程，至少不是我們所熟悉的那種多進 程。顯而易見，如果只考慮實時性，它當然比分時系統好，它可以保證重要任務總是優先佔有CPU。但是在系統中，重要任務畢竟是有限的，這就使得劃分其他任 務的優先權變成了一個讓人費神的問題。另外，有些任務交替執行反而對用戶更有利。例如，用單片機控制兩小塊顯示屏時，無論是編程者還是使用者肯定希望它們 同時工作，而不是顯示完一塊顯示屏的信息以後再顯示另一塊顯示屏的信息。這時候，要是ucos ii即支持優先級法又支持時間片輪轉法就更合適了。
在單片機系統中嵌入ucos ii將增強系統的可靠性，並使得調試程序變得簡單。以往傳統的單片機開發工作中經常遇到程序跑飛或是陷入死循環。可以 用看門狗解決程序跑飛問題，而對於後一種情況，尤其是其中牽扯到複雜數學計算的話，只有設置斷點，耗費大量時間來慢慢分析。如果在系統中嵌 入 ucos ii的話，事情就簡單多了。可以把整個程序分成許多任務，每個任務相對獨立，然後在每個任務中設置超時函數，時間用完以後，任務必須交 出 CPU的使用權。即使一個任務發生問題，也不會影響其他任務的運行。這樣既提高了系統的可靠性，同時也使得調試程序變得容易。
在單片機系統中嵌入ucos ii將增加系統的開銷。由於每建立一個任務，都要產生一個與之相對應的數據結構TCB，該數據結構要佔用很大一部分內存空間。所以在定義最大任務數時，一定要考慮實際情況的需要
和其他一些著名的嵌入式操作系統不同，ucos ii在單片機系統中的啓動過程比較簡單，不像有些操作系統那樣，需要把內核編譯成一個映像文件寫入 ROM中，上電覆位後，再從ROM中把文件加載到RAM中去，然後再運行應用程序。ucos ii的內核是和應用程序放在一起編譯成一個文件的，使用者只 需要把這個文件轉換成HEX格式，寫入ROM中就可以了，上電後，會像普通的單片機程序一樣運行。
當然，是否在單片機系統中嵌入ucos ii應視所開發的項目而定，對於一些簡單的、低成本的項目來說，就沒必要使用嵌入式操作系統了。
Ucos 51上都適合
μC/OS-Ⅱ是基於μC/OS的，μC/OS自1992年以來已經有好幾百個商業應用。μC/OS-Ⅱ與μC/OS的內核是一樣的，只不過提供了更多的功能。
也有人直接在PC上移植，參uCOS-II中文手冊：“筆者選擇 PC 做爲目標系統是由於以下幾個原因：首先也是最爲重要的，以PC做爲目標系統 比起以其他嵌入式環境，如評估板，仿真器等，更容易進行代碼的測試，不用不斷地燒寫 EPROM，不斷地向 EPROM 仿真器中下載程序等等。用戶只需 要簡單地編譯、鏈接和執行”
所需
ucos
pic18
51
要把uC/OS II成功地移植到某一處理器上.該處理器必須滿足以下要求：
處理器的C編譯器能產生可重入代碼。
用C語言就可以打開和關閉中斷。
處理器支持中斷，並且能產生定時中斷(通常在10至100Hz之間)。
處理器支持能夠容納一定量數據(可能是幾千字節)的硬件堆棧。
處理器有將堆棧指針和其它CPU寄存器讀出和存儲到堆棧或內存中的指令。
而Microchip PIC18F452的體系結構可以滿足移植uC/OS II的硬件需求.同時Microchip提供的C18編譯器也能滿足移植的需要。
一步步實踐
經過一番查找，我得到了5個版本。其中3個是用KEIL編譯的。本來我想直接把OS代碼嵌到應用程序中，但後來發現沒有一個可以直接使用。有的無法 用KEIL直接編譯，有的需要修改DLL在軟件仿真下使用。而我需要的是能在串口輸入輸出，不需要修改任何無關軟件，能在軟件仿真和硬件上運行的實時多任 務操作系統。沒有辦法，我只好硬着頭皮去改編。
沒那麼複雜啊
把那三個CPU文件移植後，照書本自檢測一下，開幾個任務就可以了。
我是第一天買了書，第二天移植到2132，第二天晚上跑了ADC和串口兩個任務。很EASY啊
關鍵要看你功夫到不到家
就在某一天，總之基本上沒看uCOS2那本書，只是隨便翻了翻，突然頓悟，原來就是這樣啊，就在那一刻，我會用uCOS2了，其實用一個移植好的uCOS2和用一個頭文件裏的程序沒多大區別
關鍵是你是否編過操作系統中用的最廣泛知識的程序
在Window上，推薦大家用RealView＋Proteus學習UCOS
在Linux下，推薦大家使用Skyeye學習
個人認爲自上向下的學習方法不錯，先看例子，看API，再在PC上先跑一跑，然後看移植方法，自己移植一個。然後在以後的應用中，感覺哪一塊重要，再去讀源碼！如果一上來直接讀源碼，你會發現，源碼確實很好懂，不過讀後感覺還是不太會用！！
uC/OS II在Microchip MCU上的移植
uC/OS II是一個完整的、可移植、可裁減、源碼公開的搶佔式實時多任務操作系統。因此程序開發人員可以在嵌入式系統的開發過程中.靈活地改寫其源代碼.以滿足用 戶特定的需求。PIC18F452是Microchip公司生產的單片機PICmicro家族中的中檔微處理器產品.是一款含有豐富片上資源的8位 MCU.廣泛應用在家用電器、醫療設備、工業控制等領域。因此uC/OS II在該處理器上的成功移植.將大大提高複雜應用系統的開發效率.增強系統的可靠性，降低開發成本，提高經濟效益。
1 uC/OS II移植方法
1.1 uC/OS II成功移植的條件
要把uC/OS II成功地移植到某一處理器上.該處理器必須滿足以下要求：
處理器的C編譯器能產生可重入代碼。
用C語言就可以打開和關閉中斷。
處理器支持中斷，並且能產生定時中斷(通常在10至100Hz之間)。
處理器支持能夠容納一定量數據(可能是幾千字節)的硬件堆棧。
處理器有將堆棧指針和其它CPU寄存器讀出和存儲到堆棧或內存中的指令。
而Microchip PIC18F452的體系結構可以滿足移植uC/OS II的硬件需求.同時Microchip提供的C18編譯器也能滿足移植的需要。
1.2 uC/OS II移植的相關工作
uC/OS II的移植工作主要涉及與處理器相關的以下內容：
與編譯器相關的數據類型聲明(OS_CPU.H)不同的處理器有不同的字長.所以必須定義一系列數據類型以確保移植的正確性。文件OS_CPU.H中聲明瞭10個相關數據類型。
改寫與任務管理相關的函數(OS_CPU_C.C)uC/OS II移植需要改寫6個與任務管理相關的函數.它們是：OSTaskStkInit()、OSTaskCreatHook()、 OSTaskDelHook()、OSTaskSwHook()、OSTaskStatHook()、OSTaskTickHook()
其中只需對OSTaskStkInit()編寫代碼，後5個函數必須聲明，但是內部並沒有代碼。OSTaskCreate()和OsTaskCreateExt()通過調用OSTaskStkInit()來初始化任務的堆棧結構。
編寫與任務切換相關的函數(OS_CPU_A.ASM)
uC/OS II的移植要求用戶編寫四個與處理器相關的彙編語言函數：OSStartHighRdy()、OSCtxSw()、OSIntCtxSw()、OSTickISR()。
如果用戶的編譯器支持插入彙編語言代碼，可將所有與處理器相關的代碼放到OS_CPU_C.C文件中，該文件便不再需要。
編寫中斷服務程序CPUhighInterruptHook() 數和CPUlwoInterruptHook()函數
2 uC/OS II在PIC18F452上的移植實現
2.1數據類型定義
在uC/OS II中，不使用c的short、int和long等數據類型。下面就是uC/OS II定義的一部分數據類型。
typedef unsigned char BOOLEAN;
typedef unsigned char INT8U;/*無符號8位整數 */
typedef signed char INT8S; /*有符號8位整數 */
typedef unsigned int INT16U; /*無符號16位整數 */
typedef signed int INT16S; /*有符號16位整數 */
……
2.2宏定義
包括開關中斷的宏定義，以及進行任務切換的宏定義。
#define OS_CRITICAL_METHOD 3
……
#if OS_CRITICAL_METHOD==3 /*關開中斷方式*/
#define OS_ENTER_CRITICAL() \
cpu_sr=INTCON & 0b11000000;\
INTCON &=(0b00111111|(RCON&0b10000000))
#define OS_ENTER_CRITICAL_HIGH() \
cpu_sr=INTCON & 0b11000000;\
INTCON &=0b00111111
#define OS_EXIT_CRITICAL() INTCON |=cpu_sr
#endif
……
void OSCtxSw(void);
#define OS_TASK_SW() OSCtxSw()
(1)開關中斷宏
與其他實時系統一樣，uC/OS II在進入系統臨界代碼區之前要關閉中斷，等到退出臨界區後再打開，從而保護核心數據不被多任務環境下的其他任務或中斷破壞。uC/OS II定義了兩個宏用來關閉/打開中斷：OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()。uC/OS II中提供三種開關中斷的方法。本移植中實現OS_ENTER_CRITICAL()用的是第3種方法，將CPU的狀態字寄存器保存到局部變量中。而 OS_EXIT_CRITICAL()從這個局部變量中恢復狀態寄存器。該移植中使用的局部變量爲OS_CPU_SR類型的cpu_sr。此方法還定義了
一個關中斷的宏OS_ENTER_CRITICAL_HIGH()，與OS_ENTER_CRITICAL()不同的是它不僅可以禁止低優先級中斷，而且 可以禁止高優先級中斷。後者只能禁止低優先級中斷。
(2)任務切換宏OS_TASK_SW()
上下文切換時可直接調用該宏，因爲在PIC18中是沒有軟中斷的。
2.3堆棧
uC/OS II是一個多任務的調度器，每個任務都有自己的堆棧。堆棧必須聲明爲OS_STK類型，並且由連續的內存空間組成。OS_STK數據類型和處理器的寄存器 長度是一致的，PIC18F452的寄存器長度爲8位，並定義堆棧由低地址向高地址增長，以便在調用任務建立函數OSTaskCreate()或 OSTaskCreateExt()時，告知堆棧是增長方向：
typedef INT8U OS_STK;/*棧類型(8位寬)*/
#define OS_STK_GROWTH 0 /*定義棧增長方向爲由低到高*/
2.4時鐘
PIC18F452有8種振盪器模式。設計中選用的是XT模式，故決定了時鐘頻率爲4Mhz。
2.5任務切換
由於uC/OS II是一個搶佔式的內核，所以它總是執行處於就緒態的優先級最高的任務。任務在執行時會調用uC/OS II提供的一個服務來等待時間過期，或者信號量的到來，或者另一個任務或中斷服務例程的消息的到來。當內核發現有優先級更高的任務處於就緒態時，便進行任 務間切換。其處理過程如下：
任務調用uC/OS II提供的OSTimeDly()服務;
OSTimeDly()將任務放到正在等待任務過期的一串任務裏面；
因爲任務不可能再被執行，系統會調用調度器(OSSched())找出下一個優先級最高的任務來運行；
上下文切換是通過調用OSCtxSw()來完成的。
OSCtxSw()是用內嵌彙編語言寫的，因爲它要直接操作PIC中的寄存器。
2.6中斷服務例程
根據uC/OS II的要求，用戶要編寫自己的中斷服務例程。所有的中斷是在CPUhighInterruptHook()函數和 CPUlowInterruptHook()函數中處理的.用戶只需要提供處理中斷的代碼。時鐘中斷中的必須是一個低優先級的中斷.並且需要定時調用 OSTimeTick()。
在CPUlowInterruptHook()函數處理完中斷服務子程序後，CPU相關代碼開始退出中斷。調用OSIntExit()使中斷嵌套層數遞 減，當嵌套層數爲0時，所有的中斷嵌套結束，系統通過調用OSSched()判斷CPU應該回到先前被中斷的任務，還是運行高優先級的任務。如果有一個高 優先級的任務，uC/OS II會通過任務切換使CPU運行此任務。
void CPUlowInterruptHook(void)
{
if(INTCONbits.TMROIF){ //檢查TMR0是否溢出
INTCONbits.TMR0IF=0; //清除中斷標誌
TMR0H=0xD8; //設置時間常數10 ms.(at 4MHz)
TMR0L=0xA0;
OSTimeTick(); //調用OS時鐘請求
}
/*此處插入用戶的中斷程序*/
}
#pragma interrupt CPUhighInterruptHook
void CPUhighInterruptHook(void)
{
/*此處插入高優先級中斷程序，但不能使用任何OS功能調用*/
}
3 用戶實時任務編寫
uC/OS II中的實時任務是在系統初始化(調用OSInit()和OSCtxSw())後，通過OSTaskCreateExt()調用創建的，實時任務創建完成 後，調用OpenTimer0()設置時鐘中斷，最後調用OSStart()，系統開始運行並進行任務調度。
爲了測試移植的結果，使用高奇ICD DEMO教學實驗板並利用板上資源創建TempTask()、LEDTask()及通過RS232實現的Shell任務。其中，Shell任務接收並執行 用戶的Shell命令.並通過LCDTask()任務顯示該命令.TempTask()則實現則週期性地採集與RA0－RA3相連接的溫度。由於PIC的 USART中只有2個字節的FIFO緩衝隊列，快速的通信過程中很容易丟失數據.故除了通信的實現採用中斷方式之外.還設計了一個30Byte的緩衝隊 列，存放接收到的數據，接收數據由設計在CPUlowInterruptHook()中的代碼完成，主要代碼如下：
while((PIE1bits.RCIE)&&(PIR1bits.RCIF))
{
c=RCREG;
t=q.rear+1;
if(t==MAX_LEN)//接收的數據存放到隊列中
t=0;
if(t==q.front)
break; //溢出
q.rear=t;
q.data[q.rear]=c;
}
4 結束語
目前正在進行的水質控制系統中採用PIC MCU作爲下位機負責數據採集、數據簡單處理、控制執行機構以及與上位機的通信。該項目中引人uC/OS II後.系統開發效率明顯提高。下一步考慮將其與已經設計完成的以太網控制器結合，實現嵌人式控制系統的TCP/IP互連。
UC/OS-II 在pic18上的移植（一）
由於學習µC/OS-II 時間比較短,很多問題還在不斷地摸索，我想將我在移植µC/OS-II到PIC18f8720中的一些經驗貢獻出來，讓大家分享，難 免錯誤的地方，歡迎拍磚。由於手頭任務時間較緊，我只有抽空湊一點大家一起交流。望走在前面的大蝦，多提寶貴意見。
爲什麼要RTOS（實時內核）？是不是覺得很時髦？這樣說，你要是搞一些代碼量很小，產品質量也不是很重要，也不需要所有的任務都按時完成，那還是傳統的 程序結構比較適用，因爲它不需要你花大量的時間去接觸內核這個當代軟件的專家技術。如果你的程序量很大，系統的任務繁重，像現在超過32K的code已很 常見，這時，就再也不是我們傳統說的30%時間寫程序，70%調試程序了，很可你花了大半年時間搞出來的程序自己都說不清結構，維護起來十分喫力，有時候 維護一個程序還不如重新寫一個快。我去年就這樣，3個月寫出來的東西，自己都把它否定了！搞得人很累。最近又一個東西需要管理4個步進電機、一個交流電
機，多路開關信號的輸入輸出，還要240x64的lcd，鍵盤。要求人機信息交換很多。最頭痛的還要這些電機同步協調工作。我水平很臭，搞了10來天就走 不動了，超過25k後沒有頭緒了。只好咬緊牙關看看RTOS（實時內核）的東西了。沒有一點基礎，也就沒有一點底自己到底行不行？但背水一戰，也只好硬着 頭試一下。它有什麼作用？雖然學起來十分艱難，但完全可以將整個工程分成若干個小塊，每一塊就只處理一個任務，比如說一個電機的工作或lcd如何顯示；各 個任務之間再想辦法通過專門的方法聯繫，讓你不再考慮程序的整體結構問題了。
用什麼RTOS？從一些資料中發現µC/OS-II很適合初學者，好，就是它。
µC/OS-II是一個源代碼公開專門針對MCU的一個佔先式實時內核，它的最大好處是可以放在你的源代碼中，一起編譯鏈接後在 mcu中運行，不像一些內核需要放在專門的boot代碼塊中。其次可以根據你的需要進行裁減——這些都可以在它的資料中看到。當然你離不開一下的幾個過 程，有些甚至很痛苦。
首先，你要有較好的C基礎，不然你看它的一些代碼就是坐飛機了！
其次，必須搞懂嵌入式系統的概念。
有這樣的前提，你就可以看看邵貝貝翻譯Jean J.Labrosse著的《嵌入式實時操作系統 µC/OS-II》，我花了20天時間專門看這本書，現在也就懂一點皮毛。我認爲第一步不要深究代碼的意思，只要知道這個函數做了些 什麼工作，就可以了，關鍵是要知道如何應用，必須搞懂的地方有：任務和事件的數據結構，優先級算法，中斷的處理方法。然後你就可以試着使用被前人移植過的 環境了。如果要自己去搞移植，沒有功底就絕對沒有把握。
去www.ucosii.com 上下載一個適合你的移植好了的代碼，着手編譯一下，最好是能夠在PICDEM 2 PLUS上運行。這個過程看來簡單，自己摸索也很費時日的~~~ 要注意的一些問題：
1、 不要指望在htsoft出的Picc18下編譯，由於它不支持代碼重載，你用的再熟練也只有拋掉！去關心難用的mcc18吧。還要注意linker腳本文 件的修改，我也沒有搞懂linker，參照下載文檔裏現成的18f452的樣子，刪掉對databank的劃分，在編譯命令裏選用大模式，就過去了。現在 也說不出原因。
2、 下載的文檔裏，沒有Kernel的代碼，你還得拷貝進去，注意千萬不要覆蓋已存在的源代碼。
3、 編譯通過了，你就成功了一半，我在PICDEM 2 PLUS 下調時發現根本就不能運行，今天花了一天時間，才找到問題，是xlcd.c裏面除了問題。只要看到任務能夠調動了，不管它，過。搞了3個任務，分別驅動3個led，很好都工作了。代碼如下：
***************************************************************/
#include "includes.h"
#include <timers.h>
#include <string.h>
#include <stdlib.h>
/************************************************************************/
#define Ldata PORTD
#define Lport TRISD
#define CCP1 PORTCbits.RC2
#define DIR1 PORTCbits.RC3
#define EN1 PORTCbits.RC4
OS_STK Task1Stk[100];
OS_STK Task2Stk[50];
OS_STK Task3Stk[50];
OS_STK Task4Stk[50];
void Task1(void *pdata);
void Task2(void *pdata);
void Task3(void *pdata);
void Task1(void *pdata)
{
OpenTimer0(TIMER_INT_ON & T0_16BIT & T0_SOURCE_INT & T0_PS_1_1);
WriteTimer0(-10000);
// Initialize statistics task
OSStatInit();
OSTaskCreate(Task2,(void *)0,Task2Stk,7);
for(;;)
{ CCP1=1;
OSTimeDly(0x20);
CCP1=0;
OSTimeDly(0x20);
}
}
void Task2(void *pdata)
{ OSTaskCreate(Task3,(void *)0,Task3Stk,6);
for(;;)
{ DIR1=1;
OSTimeDly(0x20);
DIR1=0;
OSTimeDly(0x20);
}
}
void Task3(void *pdata)
{ for(;;)
{ EN1=1;
OSTimeDly(0x20);
EN1=0;
OSTimeDly(0x20);
}
}
void Task4(void *pdata)
{
}
// initialization
void Initialize(void)
{
ADCON1=0x0F; // all ad conversion disable at this system
PORTA=0x00;
LATA=0x00;
TRISA=0x00;
PORTB=0b11110000;
LATB=0xF0;
TRISB=0xF0;
PORTC=0x00;
LATC=0x80;
TRISC=0x80;
Ldata=0xff;
Lport=0xff;
LATD=0XFF;
PORTF=0xFF;
LATF=0xFF;
TRISF=0xFF;
PORTG=0x00;
LATG=0x00;
TRISG=0x00;
PORTH=0x0F;
LATH=0x0F;
TRISH=0x0F;
PORTJ=0b11111111;
LATJ=0xFF;
TRISJ=0b11010101;
}
//main rouitine
void main(void)
{ Initialize();
OSInit();
OSTaskCreate(Task1,(void *)0,Task1Stk,5);
OSStart();
}
下一步就可以試一下身手了。以後的經驗看情況，繼續發給大家。
--------------
真正接觸uC/OS-II是3個月之前的事，在網上有許多關於uC/OS-II的文章，文章有對uC/OS-II的種種觀點和看法，總結起來有點大於缺 點，在資源相對豐富的單片機內使用uC/OS-II可以簡化應用程序設計，增強系統的穩健性，提高開發效率，便於多人協作等優點，最吸引我的地方就是關於 TCP/IP協議在uC/OS-II上的移植內容，於是決心在單片機上移植uC/OS-II。爲了這個目的我買了邵貝貝教授翻譯的那本書，花了72塊錢。
FreeRTOS
作爲一個輕量級的操作系統，FreeRTOS提供的功能包括：任務管理、時間管理、信號量、消息隊列、內存管理、記錄功能等，可基本滿足較小系統的需要。 FreeRTOS內核支持優先級調度算法，每個任務可根據重要程度的不同被賦予一定的優先級，CPU總是讓處於就緒態的、優先級最高的任務先運行。 FreeRT0S內核同時支持輪換調度算法，系統允許不同的任務使用相同的優先級，在沒有更高優先級任務就緒的情況下，同一優先級的任務共享CPU的使用 時間。
FreeRTOS的內核可根據用戶需要設置爲可剝奪型內核或不可剝奪型內核。當 FreeRTOS被設置爲可剝奪型內核時，處於就緒態的高優先級任務能剝奪低優先級任務的CPU使用權，這樣可保證系統滿足實時性的要求；當 FreeRTOS被設置爲不可剝奪型內核時，處於就緒態的高優先級任務只有等當前運行任務主動釋放CPU的使用權後才能獲得運行，這樣可提高CPU的運行 效率。
這是兩種RTOS, 現在粗略比較一下。
freeRTOS比uCOS II優勝的地方：
1。內核ROM和耗費RAM都比uCOS 小，特別是RAM。 這在單片機裏面是稀缺資源，uCOS至少要5K以上， 而freeOS用2~3K也可以跑的很好。
2。freeRTOS 可以用協程（Co-routine），減少RAM消耗（共用STACK）。uCOS只能用任務（TASK，每個任務有一個獨立的STACK）。
3。freeRTOS 可以有優先度一樣的任務，這些任務是按時間片來輪流處理，uCOSII 每個任務都只有一個獨一無二的優先級。因此，理論上講，freeRTOS 可以管理超過64個任務，而uCOS只能管理64個。
4。freeRTOS 是在商業上免費應用。uCOS在商業上的應用是要付錢的。
freeRTOS 不如uCOS的地方：
1。比uSOS簡單，任務間通訊freeRTOS只支持Queque， Semaphores， Mutex。 uCOS除這些外，還支持Flag, MailBox.
2。uCOS的支持比freeRTOS 多。除操作系統外，freeRTOS只支持TCPIP， uCOS則有大量外延支持，比如FS， USB， GUI， CAN等的支持
3。uCOS可靠性更高，而且耐優化，freeRTOS 在我設置成中等優化的時候，就會出問題。
***********************
期待大家的意見
我認爲這個是個硬傷：uCOSII 每個任務都只有一個獨一無二的優先級，而沒有按時間片來輪流處理的同級任務
如 我要在屏幕上同時顯示兩個任務的運行輸出狀況簡直沒法做
---
我認爲這個是個硬傷：uCOSII 每個任務都只有一個獨一無二的優先級，而沒有按時間片來輪流處理的同級任務
如 我要在屏幕上同時顯示兩個任務的運行輸出狀況簡直沒法做
這個我覺得正是uCOSII的優點呢.有了這條才能保證任務執行時間的確定性.正是uCOSII高可靠性保證之一.
時間片輪換實際上會影響系統的實時性.如果同級任務過多,還叫不叫實時系統我都懷疑.
至於同時顯示,時間要求不嚴格的情況下,uCOSII的例子裏(通過任務掛起)做得不是很好嗎?
--
如何開發出1種通用的RTOS，使得用戶易於使用，方便地裁剪到某系統中去，國外商用RTOS已經很好地解 決了這個問題。中國人設計的RTOS應更多地適於中國的國情，除了中文處理，中國有着廣泛的單片機的應用基礎。開發設計1種簡單、易用的RTOS開發環 境，以中國人可以接受的價格和更爲務實的技術支持手段推出，也許可以找到1種正常的市場回報途徑。RTOS產業是1個循序漸進的產業，任何急功近利的做法 都將導致功虧一簣。用戶熟悉1種RTOS需要1個相當的過程和廠家的支持，同時用戶也不願意輕易放棄1種RTOS。我們相信中國人自己開發設計的RTOS 一定會得到國人的認可，有着無限光明的前途。
--
freertos 不限制任務數，支持堆棧檢測中斷處理機制好，不像UCOS中斷還得自己寫入口程序支持優先級繼承,ucos只支持預設優先級來提升還有，我覺得freertos查找最高優先級就緒任務更快，沒有實測過。還有支持固定時鐘週期的延時方式。freertos更像一個真正完善的實時內核，只是外圍的東西少了點文件系統有fatfs TCP/IP 有uip，lwip，大部分的移植工作都是基於GCC的很方便