自從翻譯了ucos-iii 用戶手冊到現在已將近半年了，時光飛逝，如白駒過隙。唯有珍惜時間，高效學習，熱愛生活，心胸寬廣，將來才能爲國家做貢獻。我也一直爲以上目標而努力着。 抽空整理了一些重要的知識點，希望大家喜歡，多多交流哦，尤其是浙江和江蘇的ucos、ucgui、linux 愛好者，希望能與你們多多交流，互相學習。 我的QQ：522430192 1、其中最有用的功能應該是時間片輪轉法（ roundrobin), 這個是 uC/OS-II 中不支持的，但是現在已經是 uC/OS-III 的一個功能了 2、uC/OS-III 被設計用於 32 位處理器， 但是它也能在 16 位或 8 位處理器中很好地工作。 3、一共有 2 種類型的實時系統：軟實時系統和硬實時系統。硬實時系統中，運算超時是不允許發生的，運算超時會導致嚴重後果。但是在軟實時系統中 ， 超時不會導致嚴重後果 4、前後臺系統：包含一個無限循環的模塊實現需要的操作（後臺）。中斷處理程序實現異步事件（前臺）。前臺也叫做中斷級，後臺也叫作任務級。 5、臨界操作應該在任務級中被執行，不可避免地必須在中斷處理程序中執行也要確保是在很短的時間內完成。 因爲這會導致 ISR 佔用更長的時間。 通常的， ISR 中使能相關的信息而在後臺程序中執行相應的操作。 6、ucos-iii 中的任務（也叫做線程） 是一段簡單的程序， 運行時完全地佔用 CPU 。在單 CPU 中，任何時候只有 1 個任務被執行。 7、內核的責任是管理任務，協調和切換多個任務依次享用 CPU 。讓我們感覺是多個 CPU 在同時運行，也有利於處理模塊化的應用 它也負責管理任務間的交流， 系統資源的管理（內存 和I/O ）等。 8、uC/OS-III 是一個搶佔式內核， 這意味着 uC/OS-III 總是執行最 重要的就緒任務 9、ISR 響應中斷請求設備， 但是 ISR 只做非常少的工作。 ISR 應該標記或發送消息到一個高優先級的任務， 讓中斷能夠快速處理完畢 10、系統中加入內核需要額外的支出，因爲內核提供服務時需要時間 去處理。內核佔用 CPU 的時間介於 2% 到 4% 之間。 因爲 uC/OS-III 是一個軟件，添加到目標系統中需要額外的 ROM 和 RAM 。 11、。 uC/OS-III 內核需要 1K 到 4K 之間的 RAM ， 加上每個任務自己所需的堆棧空間。 至少有 4K 大小 RAM 的處理器纔有可能成功移植 uC/OS-III 。 12、： uC/OS-III 允許多個任務擁有相同的優先級。 當多個相同優先級的任務就緒時， 並且這個優先級是目前最高的uC/OS-III 會分 配用戶定義的時間片給每個任務去運行。 每個任務可以定義不同的時間片 。 13、uC/OS-III 保護臨界段可以通過鎖定調度器代替關中斷。 因此關中斷的時間會非常少。這樣就使 uC/OS-III 可以響應一些非常快的中斷源了。 14、 uC/OS-III 允許用戶在運行時配置內核。特別的，所有的內核對象如任務、堆棧、信號量、事件標誌組、消息隊列、 消息、 互斥信號量、 內存分區、 軟件定時器等都是在運行時分配的 , 以免在編譯時的過度分配。 15、uC/OS-III 對任務數量、任務大小、優先級數量無限制。每一個任務需要有自己的堆棧空間。實際上， 任務的數量和大小限制於處理器能提供的內存大小。 16、uC/OS-III 支持任何數量的任務、信號量、 互斥信號量、 事件標誌組、 消息隊列、 軟件定時器、 內存分區。 用戶在運行時分配所有的內核對象。 17、互斥信號量用於資源管理。它是一個內置優先級的特殊類型信號量， 用於消除優先級反轉。 互斥信號量可以被嵌套，因此，任務可 申請同一個互斥信號量多達 250 次。當然， 互斥信號量的佔有者需要釋放同等次數。 18、： uC/OS-III 允許任務停止自身或者停止另外的任務。 停止一個任務意味着這個任務將不再執行直到被其他的任務復。 停止可以被嵌套到 250 級。 換句話說， 一個任務可以停止另外的任務多達 250 次。 當然， 這個任務必須被恢復同等次數纔有資格再次獲得 CPU 。 19、可以定義任意數量的一次性的、週期性的、或者兩者兼有的軟件定時器。 定時器是倒計時的， 執行用戶定義的行爲一直到計數減爲 0 。 每一個定時器可以有自己的行爲， 如果一個定時器是週期性的，計數減爲 0 時會自動重裝計數值並執行用戶定義的行爲。 20、： uC/OS-III 允許任務等待多個事件的發生。等待中的任務在所有事件發生後被喚醒 21、 uC/OS-III 允許 ISR 或者任務直接地發送信號量給其它任務。 這樣就避免了必須產生一箇中間級內核對象如一個信號量或者事件標誌組只爲了標記一個任務。提高了內核性能。 22、：每一個任務可以擁有用戶可定義的任務寄存器，不同於 CPU 寄存器。uC/OS-III 能檢測指針是否爲 NULL 、 在 ISR 中調用的 任務級服務是否允許、 參數在允許範圍內、 配置選項的有效性、 函數的執行結果等。每一個 uC/OS-III 的 API 函數返回一個對應於函數調用結果的錯誤代號 23： uC/OS-III 有內置性能測量功能。 能測量每一個任務的執行時間 , 每個任務的堆棧使用情況， 任務的執行次數， CPU 的使用情況， ISR 到任務的切換時間 , 任務到任務的切換時間， 列表中的對象的峯值數，關中斷、鎖調度器平均時間等。 24 、uC/OS-III 被設計於能夠根 CPU 的架構被優化 uC/OS-III 所用的大部分數據類型能夠被改變， 以更好地適應 CPU 固有的字大小。 優先級調度法則可以通過編寫一些彙編語言而獲益於一些 特 殊 的 指令如位設置、位清除、計數器清零指令（ CLZ ）、find-first-one(FF1) 指令 25、uC/OS-III 中所有的掛起服務都可以有時間限制， 預防死鎖。 26、uC/OS-III 有時基任務， 時基 ISR 觸發時基任務。 uC/OS-III 使27、uC/OS-III 使用了哈希列表結構， 可以大大減少處理延時和任務超時所產生的開支。 28、uC/OS-III 允許程序員定義 hook 函數。hook 函數允許用戶擴展 uC/OS-III 的功能。 29、爲了測量時間， uC/OS-III 需要一個 16 位或者 32 位的時時間戳計數器。 30、 每個 uC/OS-III 的內核對象有一個相關聯的名字。 這樣 就能很容易的識別出對象所指定的作用。對象的名字長度沒有限制，但是必須以空字符結束。 31、每個任務需要創建自己的堆棧。 堆棧的數據類型 CPU_STK 。堆棧可以被靜態地分配或者通過 malloc() 動態地分配。若任務將不會被刪除，堆棧將一直被使用。 32、在大部分處理器中， 中斷在啓動時是關閉的。 無論如何， 在啓動時關閉所有的外設中斷是最安全的。 33、uC/OS-III 須創建空閒任務 OS_IdleTask （）， 當沒有其他任務運行時就運行空閒任務。根 據 配 置 文 件 中 所 uC/OS-III 會 創 建 統 務OS_StatTask() 、 定 時 器任務 OS_TmrTask() 、 中 斷隊 列 處 理任務OS_IntQTask() 。 34、 OSTaskCreate() 的第四個參數， 第一次被調用時OSTaskCreate() 接收這個變量， 傳遞給所創建的任務中的唯一參數"p_arg"。該參數可以是任意類型的指針。 35、參數值越小優先級越高。 可以設置優先級數值爲 1 到 OS_CFG_PRIO_MAX-2 。 要避免使用優先級 #0 和優先級 OS_CFG_PRIO_MAX-1 。 因 爲 這些是爲 uC/OS-III 保留的。 36、任務的堆棧大 ( 以 CPU_STK 爲數據類型而不是字節 ) 。 例如， 如果要分配 1KB 大小的堆棧空間，因爲 CPU_STK 是 32 位的，所以這個其值爲 256. 37、）所有的 uC/OS-III 任務需要被設置爲無限循環。 38、互斥信號量（ mutex ）是一個內核對象，用於保護共享資源。 任務要訪問共享資源就必須先獲得 mutex 。mutex 的擁有者使用完這個資源後就必須釋放這個 mutex 。 39、消息隊列是一個內核對象， ISR 或任務可以直接發送消息到另一個任務。 發送者制定一個消息並將其發送到目標任務的消息 隊列。 目標任務等待消息的到達。 40、定義消息隊列可接受消息的個數。 這個值必須大於 0 。如果 消息者發送消息數超過了消息接收任務的承受能力。那麼消息將會被丟失。可以通過增加消息隊列的大小或者提供消息接收任務的優先級提升其承受能力。 41、uC/OS-III 定義了一個進入臨界段的宏和兩個出臨界段的宏（退出臨界段後是否調用調度器）。 42、測得消息是什麼時候被髮送的， 用戶就能測得任務接收這 個消息所用的時間。 讀取現在的時間戳並減去消息被髮送時的時 戳。需注意的是， 消息被髮送時， 等待消息的任務可能不會立即接收到消息，因爲 ISR 或更高優先級的任務可能搶佔了當前任務。顯然，測出的時間還包括了測量時消耗的額外時間。 然而減掉測量時所耗時間就是實際上的時間。 43、時間戳的控制單元位於 CPU_TS 中。 例如， 如果 CPU 速率爲 1MHz ， 時間戳的速率爲 1MHz 。 那麼CPU_TS 的分辨率爲 1 微秒 44、當任務第一次執行時， 會傳入一個變量 "p_arg" 。這是一個指向 void 的指針。 用於變量的地址、 結構體地址、 或者函數的地址等。 如果需要，可以創建多個相同的任務，使用相同的代碼（相同任務體），而產生有不同的運行結果。 45、只運行一次的任務結束時必須通過調用 OSTaskDel() 刪除自己。 這樣可以使系統中的任務數減少。 46、一個任務可以創建其它任務（ 調 OSTaskCreate() ）、 停止或者恢復其它 ( 調用 OSTaskSuspned() 和 OSTaskResume()) 、 提交信號量到其它任務、 發送消息到其它任務、 提供共享資源等。 換句話說， 任務不是隻被限制於“等待事件”。 47、在嵌入式系統中動態地分配堆棧是被允許的，但是，一旦堆棧被動態分配，它就不能被回收。 換句話說， 對於有些不需要被刪除的任務， 動態分配它們的堆棧是一種很好的解決方法。 48、可以人工地計算出任務需要的堆棧空間大小，逐級嵌套所有可能 被調用的函數， 添加被調用函數中所有的參數， 添加上下文切換時的CPU 寄存器空間， 添加切換到中斷時所需的 CPU 寄存器空間，添加處理 ISRs 所需的堆棧空間。 把上述的全部相加， 得到的值定義爲最小的需求空間。 因爲我們不可能計算出精確的堆棧空間。 通常是再乘以 1.5 以確保任務的安全運行。 49、另一種防止堆棧溢出的方法是分配的空間遠大於可能需要的。 首先， 當任務創建時其堆棧被清零。 程序運行一段時間後，通過一個低優先級任務， 計算該任務整個堆棧中值爲 0 的內存大小。 這是一種非常有效的方法。 注意的是， 程序需用運行很長的時間以讓堆棧達到其需要的最大值。 50、從用戶的觀點來看，任務可以是有 5 種狀態，休眠狀態，就緒狀態，運行狀態，掛起狀態，中斷狀態 。 51、調用 OSTaskSuspend() 會任務無條件地停止運行。 有些時候調用 OSTaskSuspend() 不是爲了等待某個事件的發生，而是等待另一個任務調用 OSTaskResume() 函數恢復這個任務。 52、任務控制塊是被 uC/OS-III 用於維護任務的一個結構體。 每個任務都必須有自的己 TCB 。TCB 中的一些變量可以根據具體應用進行裁剪。用戶程序不應該訪問這些變量（尤其不能更改它們） 53、有些處理器有硬件寄存器可以自動地檢測並確保堆棧不發生溢出， 如果處理器沒有這些硬件施，ucos-iii 的堆棧檢測可以用軟件模擬。 然而， 軟件模擬不如硬件可靠。 54、在 uC/OS-III 初始化的時候，它會創建至少 2 個內部的任務 (OS_IdleTask() 和 OS_TickTask()) ， 3 個可選擇的任務（ OS_StatTask() ，OS_TmrTaks() ， OS_IntQTask() ）。這些可選擇的任務在編譯時由OS_CFG.H 中的配置決定。 55、當 CPU 中沒有其它就緒任務運行時，空閒會被運行。空閒任務是一個無限循環的不會等待任何事件的任務。空閒任務的每次循環，都會調用 OSIdleTaskHook() 函數，這個函數提供給用戶擴展應用，如讓處理器進入低功耗模式等。 56、） 使用硬件定時器並被設置爲以 10 到 1000Hz 之間的頻率 產生時基中斷，時基中斷並不是一定要用 CPU 產生， 事實上， 它可以從其他的具有較精確的週期性時間源中獲得，比如電源線（ 50-60Hz ）等。 57、當時基任務執行時，它會遍歷掛起隊列中所有等待期滿的任務或等待事件超時的任務。 它會就緒時基列表中的那些期滿、超時的任務。使用輪轉法遍歷隊列（此隊列爲二維數組的形式）大大減少了遍歷隊列所佔用CPU 的時間。 58、統計任務能夠統計總的 CPU 使用率, 每個任務的 CPU 使用率，每個任務的堆棧使用量。 59 軟件定時器通常需要的頻率可由用戶設置， 通過軟件將時基分頻。 換句話說如果時基速率爲 1000Hz, 但是想要的定時器速率爲 10Hz, 軟件定時器任務會每 100 個時基被標記一次。時基任務的優先級要高於定時器任務，定時器任務的優先級需要於統計任務 60、當一個任務創建了一個具有相同優先級的任務，這個新任務會被 添加到該優先級隊列的尾部（因爲具有相同優先級情況下， 沒有理由讓新任務先運行）。然而，當一個任務創建了一個具有不同優先級的任務時，這個新的任務就會放到對應優先級列表中的首部。注意：正在運行的任務也被放在就緒列表中。 61 會發生調度的調度點：任務被標記或發送消息給另一個任務 、任務調用 OSTimeDly() 或 OSTimeDlyHMSM()、任務所等待的事件發生或超時、任務被取消掛起 、新任務被創建 、任務被刪除 、內核對象被刪除 、任務改變自身的優先級或其它任務的優先級 、任務通過調用OSTaskSuspend() 停止自身、任務調用OSTaskResume() 恢復其它停止了的任務、退出中斷服務程序 、通過調用 OSSchedUnlock() 調度器被解鎖、調用OSSchedRoundRobinYield() 任務放棄了分配給它的時間片、用戶調用OSSched() 62、任務提交一個事件後調用調度器。 當然， 任務可以一次性提交多個事件， 但在最後一個事件提交後才調用調度器。 63、uC/OS-III 有 2 種調度方式： OSSched() 被用於任務級。 OSIntExit()被用於中斷級。由於中斷產生時已經將任務 A 的狀態保存在任務 A 的堆棧中，所以 ISR 返回時無需再保存任務 A 的狀態，而是直接載入任務 B 的 CPU 寄存器到硬件CPU 寄存器中即可 64、當 uC/OS-III 轉向執行另一個任務的時候，它保存了當前任務的 CPU 寄存器到堆棧。並從新任務堆棧中 相關內容載入CPU 寄存器。這個過程叫做上下文切換。上下文切換需要一些開支。 CPU 的寄存器越多， 開支越大。 上下文切換的時間基本取決於有多少個 CPU 寄存器需要被存儲和載人。保存狀態寄存器和程序指針寄存器到當前 的任務堆棧。保存的順序與中斷髮生時 CPU 保存寄存器的順序相同。 65、CPU 處理中斷有兩種模式： 1 所有的中斷指向同一個 ISR2 每個中斷指向各自的 ISR 。） ISR 的工作完成後， 用戶必須調用 OSIntExit() 告訴 uC/OS-III 中斷服務程序已經完成。 66、uC/OS-III 有兩種方法處理來自於中斷的時間； 直接提交和延遲提交。其區別在於如何處置中斷中所產生的事件。延遲提交的方式爲事件不是直接發送給任務， 而是先發送到中斷隊列。 然後中斷處理任務（其優先級爲0）被就緒，這樣，事件的提交便可在任務級完成，從而減少了ISR 處理的時間。 67、uC/OS-III 必須有系統時基是普遍的誤解。 事實上， 很多低功耗應用中沒有系統時基，因爲需額外的能量用於維護時基源。換句話說 ，將能量用於維護時基源是不合理的。因爲 uC/OS-III 是一個可搶佔式內核， 一個事件可以喚醒進入低功耗模式處理器（按鍵或其它事件）沒有時基意味着用戶不能再對任務進行延時或超時設置。 用戶在研發低功耗產品時可以考慮這個特性。 68、任務在掛起隊列中是根據優先級分類的。 高優先級任務被 放置在隊列的頭部，低優先級任務被放置在隊列的尾部。 69、任務不是直接鏈接到掛起隊列中， 而是通過叫OS_PEND_DATA 的結構體作爲媒介。 這個媒介在任務被掛起時分配到任務堆棧的。掛起隊列中的對應指針指向該結構體。 70、延時函數OSTimeDly()，任務調用這個函數後就會被掛起直到期滿。以時基爲單位，但需注意，當任務在時基中斷將要到來時被掛起，那麼實際的延時時基會少 1 個時基。這個函數可以有設置爲三種模式：相對延時模式，週期性延時模式，絕對延時模式（用於對時間要求很高的應用）。 71、uC/OS-III 定 時 器 的 分 辨 率 決 定 於 時 基 頻率。定時器可以被設置爲 3 種模式：一次性定時模式， 無初始定時週期模式，有初始定時週期模式 。如果定時器被停止， 那其定時值也將被停止， 直到定時器被恢復時，定時器值繼續被遞減。不能在定時器的執行代碼中等待事件發生。否則定時器任務會被掛起，導致定時器任務崩潰。 72、uC/OS-III 可能要維護上百個定時器。 使用定時器列表會大大降低更新定時器列表所佔用的 CPU 時間。 定時器列表類似於時基列表，以二維數組的形式存儲記錄。 73、uC/OS-III 提供關中斷方式、鎖調度器方式、、信號量方式、mutex方式保護共享資源。只有任務才允許使用信號量，ISR 是不允許的。用信號量保護共享資源不會導致中斷延遲。當任務在執行信號量所保護的共享資源時，ISR 或高優先級任務可以搶佔該任務。 74、信號量經常被過度使用。很多情況下，訪問一個簡短的共享資源時不推薦使用信號量，請求和釋放信號量會消耗CPU 時間。通過關/ 開中斷能更有效地執行這些操作。信號量會導致一種嚴重的問題：優先級反轉。 75、優先級反轉是實時系統中的一個常見問題，僅存在於基於優先級的搶佔式內核中。uC/OS-III 支持一種特殊類型的二值信號量叫做mutex，用於解決優先級反轉問題。 76、死鎖，就是兩個任務互相等待對方所佔用的資源的情況。除一般的防死鎖方式外，uC/OS-II 還可以在申請信號量或mutex 時允許設置其期限，這樣能防止死鎖，但是同樣的死鎖可能稍後再次出現。 77、uC/OS-III 中用於同步的兩種機制：信號量和事件標誌組。兩個任務間可以用一個信號量實現單向同步，用兩個信號量實現雙向同步。當任務要與多個事件同步時可以使用事件標誌。若其中的任意一 個事件發生時任務被就緒，叫做邏輯或(OR)。若所有的事件都發生時任務被就緒，叫做邏輯與（AND）。 78、有些情況下任務或ISR 與另一個任務間進行通信，這種信息交換叫做作業間的通信。可以有兩種方法實現這種通信：全局變量、發送消息。需注意的是：任務與ISR 通信只能通過全局變量。如果全局變量被ISR 改變，任務將不會知道全局變量被改變，除非該任務檢測該變量或者ISR 標記任務告知該變量被改變。 79、消息可以被髮送到媒介—消息隊列中，也可以直接發送給任務，因爲uC/OS-III 中每個任務都有其內建的消息隊列。如果多個任務等待這個消息時建議將該消息發送到外部的消息隊列。當只有一個任務等待該消息時建議直接將消息發送給任務。 80、消息中包含一個指向數據的指針、該數據的大小、時間戳變量。該指針可以指向數據區域甚至是一個函數。當然，消息的發送方和消息的接收方都應該知道消息所包含的意義。 81、消息隊列是先入先出模式（FIFO）。然而，uC/OS-III 也可以將其設置爲後入先出模式（LIFO）。若任務或ISR 發送緊急消息給另一個任務時，後入先出模式是非常有用的，在這種情況下，該緊急消息繞過消息隊列中的其他消息。 82、任務A 發送多個消息給任務B，如果更高優先級的任務搶佔了任務B，那麼任務A 所存放在消息隊列中的數據就可能被溢出。解決這個問題的一種方法是在處理中添加流量控制：所有任務在發送消息給任務B 之前必須獲得信號量。任務B 消息隊列的空餘量爲多少，信號量計數值就爲多少。 83、任務可以等待多個內核對象。然而，uC/OS-III 只允許任務同時等待多個信號量或消息隊列。換句話說，不能同時等待多個事件標誌組或mutex。但這將花費uC/OS-III 較多時間去處理。 84、可以通過使用編譯器提供的函數malloc()和free()動態地分配和釋放內存快。然而，在嵌入式實時系統中使用malloc()和free()可能是非常危險的。因爲它可能會導致很多內存碎片。 85、ucos-iii 可以創建多個大小不同的內存分區，一個內存分區可被設置爲多個大小相同的任務塊，用於存儲臨時性的數據。根據需求設置，但內存塊被分配後必須返回給它所在的內存分區，這種管理方式僅會導致內存塊塊內的碎片。從而減少了內存碎片。
轉自 http://cache.baiducontent.com/c?m=9f65cb4a8c8507ed4fece763105392230e54f73561868b4968d4e419ce3b4603506695bd24211107d4c6776416af3e06acaf6866725e60e1948fd9179cac925974d37c&p=9d64dc0385cc43eb08e2977f0f7a9d&newp=8a61c01f85cc43b51bbd9b7d0c14c9231610db2151d2d2136597&user=baidu&fm=sc&query=ucos+iii&qid=c2145963000009da&p1=6