吾日三省吾身：為人謀而不忠乎？與朋友交而不信乎？傳不習乎？ucosiii中有乙個模組可以向我們提供系統執行時的各種統計資訊，這極大地方便我們實現系統的白盒管理，但是我覺得只會把那幾個統計引數打出來看根本不叫白盒管理，我們應當清楚地知道每乙個引數值是怎麼被統計出來的。今天我就cpu執行速率這個統計引數進行了白盒**，我試圖搞清楚它的整個計算流程，但是事與願違，一直到現在，還是有一些現象與我想得不一樣（cpu在啟動瞬間，cpu使用率會非常高，之後才逐漸降低到平穩水平），這些現象看似合理（也的確合理），但我還是沒搞清楚為什麼會這樣。
我想，什麼會影響cpu的使用情況，無非就是任務，但我自己建立的任務只有乙個，剩下的都是系統任務，所以，我打算搞清楚每乙個系統任務，ucosiii一共有五個系統任務，它們分別在下面五個函式中初始化：os_intqtaskinit、os_idletaskinit、os_ticktaskinit、os_stattaskinit、os_tmrinit。空閒任務沒什麼好說的，統計任務和定時器任務以及中斷佇列管理任務都是可選的，可選就代表著不是核心的，我們只看核心。所以現在只剩下乙個tick任務，我們下面就去仔細看看。
之前聽說tick定時器是微控制器專門為作業系統提供的定時器，它能夠產生固定週期的中斷為作業系統提供時基，什麼是時基，顧名思義，時間的基準，作業系統中的絕大部分時間系統都是以這個中斷週期作為最小時間單位的。
這個定時器是由下面四個暫存器控制的
這個定時器是屬於cm3核心的乙個元件，我們一般用這個定時器作為時基，因為這樣做的話，當我們再相同核心的不同晶元之間做移植的時候就不用再去配置時基了。它是由四個暫存器控制的：控制及狀態暫存器、重裝載暫存器、當前計數值暫存器、校準暫存器。具體的配置方法和普通的定時器一樣。#defi ne nvic_stcsr ((volatile unsigned long *)(0xe000e010))#defi ne nvic_reload ((volatile unsigned long *)(0xe000e014))
#defi ne nvic_currval ((volatile unsigned long *)(0xe000e018))
#defi ne nvic_calval ((volatile unsigned long *)(0xe000e01c))
當它計數值滿的時候就會產生乙個中斷，這個中斷就會找到中斷向量表中的
這也是乙個cms繫結的中斷向量，它在0x0000_003c。dcd systick_handler ; systick handler如下便是其中斷服務函式，也就是當定時時間到了的時候就會執行這個函式
我們看到這個函式中並沒有處理任何的時鐘節拍事務，而是呼叫了另乙個函式ostimetick，難道會再這裡面處理時鐘節拍事務？我們來看看。//systick中斷服務函式,使用ucos時用到void
systick_handler
(void
)}
為了將注意了集中在主要矛盾上，我把一些可有可無的內容刪除了（起碼目前可有可無），現在只剩下兩個函式了，乙個是os_intqpost，乙個是ostasksempost，這兩個函式是幹什麼的呢？我們知道ucosiii有乙個系統任務叫是節拍任務，如下所示：void ostimetick (void
)
我們一眼就可以看到，這個系統任務正在等待訊號量的到來。void os_ticktask (void
*p_arg)}}
}
我們回到剛剛的兩個函式的理解上面，它們的作用其實就是向系統任務傳送訊號量，那麼為什麼要用兩個函式呢，其實我們可以看到，這裡採用了條件編譯，也就是一次只能使用乙個函式，第一種叫做延遲post，第二種叫做直接post，這兩種傳送訊號量的方式有什麼區別呢？這是我們下面要討論的重點。
外設產生中斷請求；
中斷服務程式開始執行，該中斷服務程式中可能會包含有傳送訊號量、訊息、事件標誌組等事件。那麼等待這個事件的任務的優先順序要麼比當前被中斷的任務高，要麼比其低；
如果中斷對應的事件使得某個比被中斷的任務優先順序低的任務進入就緒態，則中斷退出後仍恢復執行被中斷的任務；
如果中斷對應的事件使得某個比被中斷的任務優先順序更高的任務進入就緒態，則ucosiii將進行任務切換，中斷服務程式推出後就執行更高優先順序的任務；
如果使用直接發布模式的話，則ucosiii就必須關中斷以保護臨界段**，防止中斷處理程式訪問這些臨界段**。
直接發布模式下，從中斷發布訊息和訊號是直接在中斷服務程式中發布的。
針對直接發布模式，如果進行臨界段保護：ucosiii會對臨界段**採用關閉中斷的保護措施，這樣就會延長中斷的響應時間。雖然ucosiii已經採用了所有可能的措施來降低中斷關閉時間，但仍然有一些複雜的功能會使得中斷關閉相對較長的時間。
外設產生中斷請求；
中斷服務程式開始執行，該中斷服務程式中可能會包含有傳送訊號量、訊息、事件標誌組等事件。那麼等待這個事件的任務的優先順序要麼比當前被中斷的任務高，要麼比其低；
中斷服務程式通過呼叫系統的發布服務函式向任務發布訊息或訊號，在延遲發布模式下，這個過程不是直接進行發布操作，而是將這個發布函式呼叫和相應的引數寫入到專用佇列中，該佇列稱為中斷佇列。然後使中斷佇列處理任務進入就緒態，這個任務是ucosiii的內部任務，並且具有最高優先順序0；
中斷服務程式處理結束時，ucosiii切換執行中斷佇列處理任務，該任務從中斷佇列中提取出發布函式呼叫資訊，此時仍需要關閉中斷以防止中斷服務程式同時對中斷佇列進行訪問。中斷佇列處理任務提取出發布函式呼叫的資訊後重新開中斷，鎖定任務排程器，然後進行發布函式呼叫，相當於發布函式呼叫一直是在任務級**中進行的，
這樣本來應該在中斷中處理的**（發布函式呼叫）就被放到了任務級完成；中斷佇列處理任務將中斷佇列處理完，將自身掛起，並重新啟動任務排程來執行處於最高優先順序的就緒任務。如果原先被中斷的任務仍然是最高優先順序的就緒任務，則ucosiii恢復執行這個任務；
由於中斷佇列處理任務的發布操作使得更重要的任務進入就緒態，核心將切換到更高優先順序的任務執行。
延遲發布模式下，從中斷發布訊息和訊號是延遲發布的，就是將要發布的內容下入到乙個專用的佇列中，最後由中斷服務管理任務進行發布。
針對延遲發布模式，如果進行臨界段保護：在使用延遲發布模式額外增加的操作都是為了避免使用關中斷來保護臨界段**。延遲發布模式下，是通過任務排程來實現的（任務排程到中斷服務管理任務），那麼就需要鎖定任務排程來保護臨界段**。這些額外增加的操作僅包括將發布呼叫及其引數複製到中斷佇列中、從中斷佇列提取發布呼叫和相關引數以及一次額外的任務切換。
如果應用中存在非常快速的中斷請求源，則當ucosiii在直接發布模式下的中斷關閉時間不能滿足要求的時候，可以使用延遲發布模式來降低中斷關閉時間
以上是書中的翻譯內容，下面是我的精華總結：
延遲post就是為了解決直接post所導致的關中斷時間過長問題，那麼為什麼延遲post可以減少關中斷時間，因為延遲post是在任務級完成的，這意味著它有現場保護功能，所以可以被中斷，也就沒必要關中斷。注：聽說延遲發布要被去掉了，要出來更好的解決方法嗎？
明天我將對延遲發布進行原始碼級的介紹
keep studying，see you next time?
UCOSIII中系統時鐘的移植
freertos的 寫得真的像是一坨坨的 我一點看的慾望都沒有。相比之下，ucosiii的 寫得就好看多了，我看著看著就看回了ucosiii，今天我重點看了移植部分與滴答定時器有關的內容，下面我就來表達一下我是如何理解這個部分內容的，本篇文章主要分為如下兩個部分 systick 是一 個 24 位的...
UCOSIII中的節拍列表更新
我這裡直接通過 打注釋的方式來一步一步 這個函式的執行過程，最後會有乙個總結 void os ticklistupdate void else break 如果是因為帶超時監測的阻塞而被延時 case os task state pend timeout p tcb tickremain p tcb...
uC OS III系統的一些知識 1
2,建立乙個任務時，必須為該任務分配乙個任務控制塊 os tcb 3,osinit 會初始化系統中的內部變數以及資料結構，並會建立2 5個任務，uc os至少會建立2個系統任務 空閒任務os idletask 在其他任務都不就緒時執行 時鐘節拍任務 負責時間的管理。還可能建立統計任務os statt...