ucosiii知識點總結

1、1、其中最有用的功能應該是時間片輪轉法（ roundrobin), 這個是 uC/OS-II 中不支持的，但是現(xiàn)在已經是 uC/OS-III 的一個功能了 2、uC/OS-III 被設計用于 32 位處理器， 但是它也能在 16 位或 8 位處理器中很好地工作。3、一共有 2 種類型的實時系統(tǒng)：軟實時系統(tǒng)和硬實時系統(tǒng)。硬實時系統(tǒng)中，運算超時是不允許發(fā)生的，運算超時會導致嚴重后果。但是在軟實時系統(tǒng)中 ， 超時不會導致嚴重后果 4、前后臺系統(tǒng)：包含一個無限循環(huán)的模塊實現(xiàn)需要的操作（后臺）。中斷處理程序實現(xiàn)異步事件（前臺）。前臺也叫做中斷級，后臺也叫作任務級。 5、臨界操作應該在任務級中被執(zhí)行，不可

2、避免地必須在中斷處理程序中執(zhí)行也要確保是在很短的時間內完成。 因為這會導致 ISR 占用更長的時間。 通常的， ISR 中使能相關的信息而在后臺程序中執(zhí)行相應的操作。 6、ucos-iii中的任務（也叫做線程） 是一段簡單的程序， 運行時完全地占用 CPU 。在單 CPU 中，任何時候只有 1 個任務被執(zhí)行。 7、內核的責任是管理任務，協(xié)調和切換多個任務依次享用 CPU 。讓我們感覺是多個 CPU 在同時運行，也有利于處理模塊化的應用 它也負責管理任務間的交流， 系統(tǒng)資源的管理（內存 和I/O ）等。 8、uC/OS-III 是一個搶占式內核， 這意味著 uC/OS-III 總是執(zhí)行最重要的就

3、緒任務 9、ISR 響應中斷請求設備， 但是 ISR 只做非常少的工作。 ISR 應該標記或發(fā)送消息到一個高優(yōu)先級的任務， 讓中斷能夠快速處理完畢 10、系統(tǒng)中加入內核需要額外的支出，因為內核提供服務時需要時間去處理。內核占用 CPU 的時間介于 2% 到 4% 之間。 因為 uC/OS-III是一個軟件，添加到目標系統(tǒng)中需要額外的 ROM 和 RAM 。 11、。 uC/OS-III 內核需要 1K 到 4K 之間的 RAM ， 加上每個任務自己所需的堆?？臻g。 至少有 4K 大小 RAM 的處理器才有可能成功移植 uC/OS-III 。 12、： uC/OS-III 允許多個任務擁有相同的

4、優(yōu)先級。 當多個相同優(yōu)先級的任務就緒時， 并且這個優(yōu)先級是目前最高的uC/OS-III 會分配用戶定義的時間片給每個任務去運行。 每個任務可以定義不同的時間片 。13、uC/OS-III 保護臨界段可以通過鎖定調度器代替關中斷。 因此關中斷的時間會非常少。這樣就使 uC/OS-III 可以響應一些非?？斓闹袛嘣戳?。 14、 uC/OS-III 允許用戶在運行時配置內核。特別的，所有的內核對象如任務、堆棧、信號量、事件標志組、消息隊列、 消息、 互斥信號量、 內存分區(qū)、 軟件定時器等都是在運行時分配的 , 以免在編譯時的過度分配。 15、uC/OS-III 對任務數量、任務大小、優(yōu)先級數量無限制

5、。每一個任務需要有自己的堆?？臻g。實際上， 任務的數量和大小限制于處理器能提供的內存大小。 16、uC/OS-III 支持任何數量的任務、信號量、 互斥信號量、 事件標志組、 消息隊列、 軟件定時器、 內存分區(qū)。 用戶在運行時分配所有的內核對象。 17、互斥信號量用于資源管理。它是一個內置優(yōu)先級的特殊類型信號量， 用于消除優(yōu)先級反轉。 互斥信號量可以被嵌套，因此，任務可申請同一個互斥信號量多達 250 次。當然， 互斥信號量的占有者需要釋放同等次數。 18、： uC/OS-III 允許任務停止自身或者停止另外的任務。 停止一個任務意味著這個任務將不再執(zhí)行直到被其他的任務復。 停止可以被嵌套到

6、250 級。 換句話說， 一個任務可以停止另外的任務多達 250 次。 當然， 這個任務必須被恢復同等次數才有資格再次獲得 CPU 。 19、可以定義任意數量的一次性的、周期性的、或者兩者兼有的軟件定時器。 定時器是倒計時的， 執(zhí)行用戶定義的行為一直到計數減為 0 。 每一個定時器可以有自己的行為， 如果一個定時器是周期性的，計數減為 0 時會自動重裝計數值并執(zhí)行用戶定義的行為。 20、： uC/OS-III 允許任務等待多個事件的發(fā)生。等待中的任務在所有事件發(fā)生后被喚醒 21、 uC/OS-III 允許 ISR 或者任務直接地發(fā)送信號量給其它任務。 這樣就避免了必須產生一個中間級內核對象如一

7、個信號量或者事件標志組只為了標記一個任務。提高了內核性能。 22、：每一個任務可以擁有用戶可定義的任務寄存器，不同于 CPU 寄存器。uC/OS-III 能檢測指針是否為 NULL 、 在 ISR 中調用的任務級服務是否允許、 參數在允許范圍內、 配置選項的有效性、 函數的執(zhí)行結果等。每一個 uC/OS-III 的 API 函數返回一個對應于函數調用結果的錯誤代號 23： uC/OS-III 有內置性能測量功能。 能測量每一個任務的執(zhí)行時間 , 每個任務的堆棧使用情況， 任務的執(zhí)行次數， CPU的使用情況， ISR 到任務的切換時間 , 任務到任務的切換時間， 列表中的對象的峰值數，關中斷、鎖

8、調度器平均時間等。 24 、uC/OS-III 被設計于能夠根 CPU 的架構被優(yōu)化 uC/OS-III 所用的大部分數據類型能夠被改變， 以更好地適應 CPU 固有的字大小。 優(yōu)先級調度法則可以通過編寫一些匯編語言而獲益于一些 特 殊 的 指令如位設置、位清除、計數器清零指令（ CLZ ）、find-first-one(FF1) 指令25、uC/OS-III 中所有的掛起服務都可以有時間限制， 預防死鎖。26、uC/OS-III 有時基任務， 時基 ISR 觸發(fā)時基任務。 uC/OS-III 使27、uC/OS-III使用了哈希列表結構， 可以大大減少處理延時和任務超時所產生的開支。 28、

9、uC/OS-III 允許程序員定義 hook 函數。hook 函數允許用戶擴展 uC/OS-III 的功能。 29、為了測量時間， uC/OS-III 需要一個 16 位或者 32 位的時時間戳計數器。 30、 每個 uC/OS-III 的內核對象有一個相關聯(lián)的名字。 這樣就能很容易的識別出對象所指定的作用。對象的名字長度沒有限制，但是必須以空字符結束。 31、每個任務需要創(chuàng)建自己的堆棧。 堆棧的數據類型 CPU_STK 。堆?？梢员混o態(tài)地分配或者通過 malloc() 動態(tài)地分配。若任務將不會被刪除，堆棧將一直被使用。 32、在大部分處理器中， 中斷在啟動時是關閉的。 無論如何， 在啟動時關

10、閉所有的外設中斷是最安全的。 33、uC/OS-III 須創(chuàng)建空閑任務 OS_IdleTask （）， 當沒有其他任務運行時就運行空閑任務。根 據 配 置 文 件 中 所 uC/OS-III 會 創(chuàng) 建 統(tǒng) 務OS_StatTask() 、 定 時 器任務 OS_TmrTask() 、 中 斷隊 列 處 理任務OS_IntQTask() 。34、 OSTaskCreate() 的第四個參數， 第一次被調用時OSTaskCreate() 接收這個變量， 傳遞給所創(chuàng)建的任務中的唯一參數"p_arg"。該參數可以是任意類型的指針。 35、參數值越小優(yōu)先級越高。 可以設置優(yōu)先級數值

11、為 1 到 OS_CFG_PRIO_MAX-2 。 要避免使用優(yōu)先級 #0 和優(yōu)先級 OS_CFG_PRIO_MAX-1 。 因 為 這些是為 uC/OS-III保留的。36、任務的堆棧大 ( 以 CPU_STK 為數據類型而不是字節(jié) ) 。 例如， 如果要分配 1KB 大小的堆?？臻g，因為 CPU_STK 是 32 位的，所以這個其值為 256. 37、）所有的 uC/OS-III 任務需要被設置為無限循環(huán)。 38、互斥信號量（ mutex ）是一個內核對象，用于保護共享資源。 任務要訪問共享資源就必須先獲得 mutex 。mutex的擁有者使用完這個資源后就必須釋放這個 mutex 。 3

12、9、消息隊列是一個內核對象， ISR 或任務可以直接發(fā)送消息到另一個任務。 發(fā)送者制定一個消息并將其發(fā)送到目標任務的消息 隊列。 目標任務等待消息的到達。 40、定義消息隊列可接受消息的個數。 這個值必須大于 0 。如果消息者發(fā)送消息數超過了消息接收任務的承受能力。那么消息將會被丟失?？梢酝ㄟ^增加消息隊列的大小或者提供消息接收任務的優(yōu)先級提升其承受能力。 41、uC/OS-III 定義了一個進入臨界段的宏和兩個出臨界段的宏（退出臨界段后是否調用調度器）。 42、測得消息是什么時候被發(fā)送的， 用戶就能測得任務接收這個消息所用的時間。 讀取現(xiàn)在的時間戳并減去消息被發(fā)送時的時戳。需注意的是， 消息被

13、發(fā)送時， 等待消息的任務可能不會立即接收到消息，因為 ISR 或更高優(yōu)先級的任務可能搶占了當前任務。顯然，測出的時間還包括了測量時消耗的額外時間。 然而減掉測量時所耗時間就是實際上的時間。 43、時間戳的控制單元位于 CPU_TS 中。 例如， 如果 CPU 速率為 1MHz ， 時間戳的速率為 1MHz 。 那么CPU_TS 的分辨率為 1 微秒 44、當任務第一次執(zhí)行時， 會傳入一個變量 "p_arg" 。這是一個指向 void的指針。 用于變量的地址、 結構體地址、 或者函數的地址等。 如果需要，可以創(chuàng)建多個相同的任務，使用相同的代碼（相同任務體），而產生有不同的運行

14、結果。45、只運行一次的任務結束時必須通過調用 OSTaskDel() 刪除自己。 這樣可以使系統(tǒng)中的任務數減少。 46、一個任務可以創(chuàng)建其它任務（ 調 OSTaskCreate() ）、 停止或者恢復其它 ( 調用 OSTaskSuspned() 和 OSTaskResume() 、 提交信號量到其它任務、 發(fā)送消息到其它任務、 提供共享資源等。 換句話說， 任務不是只被限制于“等待事件”。 47、在嵌入式系統(tǒng)中動態(tài)地分配堆棧是被允許的，但是，一旦堆棧被動態(tài)分配，它就不能被回收。 換句話說， 對于有些不需要被刪除的任務， 動態(tài)分配它們的堆棧是一種很好的解決方法。48、可以人工地計算出任務需要

15、的堆?？臻g大小，逐級嵌套所有可能被調用的函數， 添加被調用函數中所有的參數， 添加上下文切換時的CPU 寄存器空間， 添加切換到中斷時所需的 CPU 寄存器空間，添加處理 ISRs 所需的堆?？臻g。 把上述的全部相加， 得到的值定義為最小的需求空間。 因為我們不可能計算出精確的堆棧空間。 通常是再乘以 1.5 以確保任務的安全運行。49、另一種防止堆棧溢出的方法是分配的空間遠大于可能需要的。 首先， 當任務創(chuàng)建時其堆棧被清零。 程序運行一段時間后，通過一個低優(yōu)先級任務， 計算該任務整個堆棧中值為 0 的內存大小。 這是一種非常有效的方法。 注意的是， 程序需用運行很長的時間以讓堆棧達到其需要的

16、最大值。 50、從用戶的觀點來看，任務可以是有 5 種狀態(tài)，休眠狀態(tài)，就緒狀態(tài)，運行狀態(tài)，掛起狀態(tài)，中斷狀態(tài) 。51、調用 OSTaskSuspend() 會任務無條件地停止運行。 有些時候調用 OSTaskSuspend() 不是為了等待某個事件的發(fā)生，而是等待另一個任務調用 OSTaskResume() 函數恢復這個任務。 52、任務控制塊是被 uC/OS-III 用于維護任務的一個結構體。 每個任務都必須有自的己 TCB 。TCB 中的一些變量可以根據具體應用進行裁剪。用戶程序不應該訪問這些變量（尤其不能更改它們） 53、有些處理器有硬件寄存器可以自動地檢測并確保堆棧不發(fā)生溢出， 如果處

17、理器沒有這些硬件施，ucos-iii的堆棧檢測可以用軟件模擬。 然而， 軟件模擬不如硬件可靠。54、在 uC/OS-III 初始化的時候，它會創(chuàng)建至少 2 個內部的任務 (OS_IdleTask() 和 OS_TickTask() ， 3 個可選擇的任務（ OS_StatTask() ，OS_TmrTaks() ， OS_IntQTask() ）。這些可選擇的任務在編譯時由OS_CFG.H 中的配置決定。 55、當 CPU 中沒有其它就緒任務運行時，空閑會被運行。空閑任務是一個無限循環(huán)的不會等待任何事件的任務?？臻e任務的每次循環(huán)，都會調用 OSIdleTaskHook() 函數，這個函數提供給

18、用戶擴展應用，如讓處理器進入低功耗模式等。56、） 使用硬件定時器并被設置為以 10 到 1000Hz 之間的頻率產生時基中斷，時基中斷并不是一定要用 CPU 產生， 事實上， 它可以從其他的具有較精確的周期性時間源中獲得，比如電源線（ 50-60Hz ）等。 57、當時基任務執(zhí)行時，它會遍歷掛起隊列中所有等待期滿的任務或等待事件超時的任務。 它會就緒時基列表中的那些期滿、超時的任務。使用輪轉法遍歷隊列（此隊列為二維數組的形式）大大減少了遍歷隊列所占用CPU的時間。58、統(tǒng)計任務能夠統(tǒng)計總的 CPU 使用率, 每個任務的 CPU使用率，每個任務的堆棧使用量。 59軟件定時器通常需要的頻率可由用

19、戶設置， 通過軟件將時基分頻。 換句話說如果時基速率為 1000Hz, 但是想要的定時器速率為 10Hz, 軟件定時器任務會每 100 個時基被標記一次。時基任務的優(yōu)先級要高于定時器任務，定時器任務的優(yōu)先級需要于統(tǒng)計任務 60、當一個任務創(chuàng)建了一個具有相同優(yōu)先級的任務，這個新任務會被添加到該優(yōu)先級隊列的尾部（因為具有相同優(yōu)先級情況下， 沒有理由讓新任務先運行）。然而，當一個任務創(chuàng)建了一個具有不同優(yōu)先級的任務時，這個新的任務就會放到對應優(yōu)先級列表中的首部。注意：正在運行的任務也被放在就緒列表中。 61會發(fā)生調度的調度點：任務被標記或發(fā)送消息給另一個任務 、任務調用 OSTimeDly() 或 O

20、STimeDlyHMSM()、任務所等待的事件發(fā)生或超時、任務被取消掛起 、新任務被創(chuàng)建 、任務被刪除 、內核對象被刪除 、任務改變自身的優(yōu)先級或其它任務的優(yōu)先級 、任務通過調用OSTaskSuspend() 停止自身、任務調用OSTaskResume() 恢復其它停止了的任務、退出中斷服務程序 、通過調用 OSSchedUnlock() 調度器被解鎖、調用OSSchedRoundRobinYield() 任務放棄了分配給它的時間片、用戶調用OSSched() 62、任務提交一個事件后調用調度器。 當然， 任務可以一次性提交多個事件， 但在最后一個事件提交后才調用調度器。 63、uC/OS-I

21、II 有 2 種調度方式： OSSched() 被用于任務級。 OSIntExit()被用于中斷級。由于中斷產生時已經將任務 A 的狀態(tài)保存在任務 A 的堆棧中，所以 ISR 返回時無需再保存任務 A 的狀態(tài)，而是直接載入任務 B 的 CPU 寄存器到硬件CPU 寄存器中即可 64、當 uC/OS-III 轉向執(zhí)行另一個任務的時候，它保存了當前任務的 CPU 寄存器到堆棧。并從新任務堆棧中 相關內容載入CPU 寄存器。這個過程叫做上下文切換。上下文切換需要一些開支。 CPU 的寄存器越多， 開支越大。 上下文切換的時間基本取決于有多少個 CPU 寄存器需要被存儲和載人。保存狀態(tài)寄存器和程序指針

22、寄存器到當前的任務堆棧。保存的順序與中斷發(fā)生時 CPU 保存寄存器的順序相同。65、CPU 處理中斷有兩種模式： 1 所有的中斷指向同一個 ISR2 每個中斷指向各自的 ISR 。） ISR 的工作完成后， 用戶必須調用 OSIntExit() 告訴 uC/OS-III中斷服務程序已經完成。66、uC/OS-III 有兩種方法處理來自于中斷的時間； 直接提交和延遲提交。其區(qū)別在于如何處置中斷中所產生的事件。延遲提交的方式為事件不是直接發(fā)送給任務， 而是先發(fā)送到中斷隊列。 然后中斷處理任務（其優(yōu)先級為0）被就緒，這樣，事件的提交便可在任務級完成，從而減少了ISR處理的時間。67、uC/OS-II

23、I 必須有系統(tǒng)時基是普遍的誤解。 事實上， 很多低功耗應用中沒有系統(tǒng)時基，因為需額外的能量用于維護時基源。換句話說 ，將能量用于維護時基源是不合理的。因為 uC/OS-III 是一個可搶占式內核， 一個事件可以喚醒進入低功耗模式處理器（按鍵或其它事件）沒有時基意味著用戶不能再對任務進行延時或超時設置。 用戶在研發(fā)低功耗產品時可以考慮這個特性。 68、任務在掛起隊列中是根據優(yōu)先級分類的。 高優(yōu)先級任務被放置在隊列的頭部，低優(yōu)先級任務被放置在隊列的尾部。 69、任務不是直接鏈接到掛起隊列中， 而是通過叫OS_PEND_DATA 的結構體作為媒介。 這個媒介在任務被掛起時分配到任務堆棧的。掛起隊列中

24、的對應指針指向該結構體。70、延時函數OSTimeDly()，任務調用這個函數后就會被掛起直到期滿。以時基為單位，但需注意，當任務在時基中斷將要到來時被掛起，那么實際的延時時基會少 1 個時基。這個函數可以有設置為三種模式：相對延時模式，周期性延時模式，絕對延時模式（用于對時間要求很高的應用）。 71、uC/OS-III 定 時 器 的 分 辨 率 決 定 于 時 基 頻率。定時器可以被設置為 3 種模式：一次性定時模式， 無初始定時周期模式，有初始定時周期模式 。如果定時器被停止， 那其定時值也將被停止， 直到定時器被恢復時，定時器值繼續(xù)被遞減。不能在定時器的執(zhí)行代碼中等待事件發(fā)生。否則定時

25、器任務會被掛起，導致定時器任務崩潰。 72、uC/OS-III 可能要維護上百個定時器。 使用定時器列表會大大降低更新定時器列表所占用的 CPU 時間。 定時器列表類似于時基列表，以二維數組的形式存儲記錄。73、uC/OS-III提供關中斷方式、鎖調度器方式、信號量方式、mutex方式保護共享資源。只有任務才允許使用信號量，ISR是不允許的。用信號量保護共享資源不會導致中斷延遲。當任務在執(zhí)行信號量所保護的共享資源時，ISR或高優(yōu)先級任務可以搶占該任務。74、信號量經常被過度使用。很多情況下，訪問一個簡短的共享資源時不推薦使用信號量，請求和釋放信號量會消耗CPU時間。通過關/開中斷能更有效地執(zhí)行

26、這些操作。信號量會導致一種嚴重的問題：優(yōu)先級反轉。75、優(yōu)先級反轉是實時系統(tǒng)中的一個常見問題，僅存在于基于優(yōu)先級的搶占式內核中。uC/OS-III支持一種特殊類型的二值信號量叫做mutex，用于解決優(yōu)先級反轉問題。76、死鎖，就是兩個任務互相等待對方所占用的資源的情況。除一般的防死鎖方式外，uC/OS-II還可以在申請信號量或mutex時允許設置其期限，這樣能防止死鎖，但是同樣的死鎖可能稍后再次出現(xiàn)。77、uC/OS-III中用于同步的兩種機制：信號量和事件標志組。兩個任務間可以用一個信號量實現(xiàn)單向同步，用兩個信號量實現(xiàn)雙向同步。當任務要與多個事件同步時可以使用事件標志。若其中的任意一個事件發(fā)生時任務被就緒，叫做邏輯或(OR)。若所有的事件都發(fā)生時任務被就緒，叫做邏輯與（AND）。78、有些情況下任務或ISR與另一個