uos事件控制塊與任務同步

2022-07-05 15:42:13 字數 2304 閱讀 3739

ucos為了任務之間的通訊定義了訊號量,互斥性訊號量,訊息物件 訊息佇列等結構以及api,為了統一的管理這些同步,定義了乙個結構叫做時間控制塊os_event,如下

typedef struct os_event os_event;

oseventtype為事件型別,有訊號量型別,互斥性訊號量型別,訊息郵箱型別,訊息佇列型別和未定義型別五種

oseventptr訊息或者訊息佇列的指標

oseventcnt 訊號量計數器

oseventtbl 等待任務表

oseventgrp 等待事件的任務組

該結構我們稱之為時間控制體ecb,系統中擁有的全部ecb的數量為

os_ext  os_event          oseventtbl[os_max_events];

os_max_events是在系統配置檔案中指定的,也就是編譯時決定有幾個事件控制體

每個事件控制體內部都有oseventtbl這個陣列, os_event_tbl_size是乙個巨集定義,展開之後的定義為((os_lowest_prio) / 8u + 1u),和系統就緒表的大小一致

那麼正好和oseventgrp合作起來,用與系統就緒表的方法類似的標識方式作為等待事件的任務標識,具體的解析請檢視系統就緒表的說明文章,只介紹一點,當某個任務等待某個已經生成的特定事件的時候,就會在該事件對應的ecb中的oseventtbl中相應的位置1,並且這個元素對應的oseventgrp的位置也會置一,當系統在查詢等待該事件的任務的時候,就可以直接通過與任務就緒表相同的方式找到等待該事件的最高優先順序的任務.如下

y    = osunmaptbl[pevent->oseventgrp];             

x    = osunmaptbl[pevent->oseventtbl[y]];

prio = (int8u)((y << 3u) + x);   

這是os_eventtaskready函式的實現可以看到就是直接從表中得到的等待任務的優先順序.

其次是oseventptr,在系統初始化的時候,他並不是訊息或者訊息佇列的指標,而是作業系統借助oseventptr該元素將整個事件控制塊陣列都連線在了一起,類似於tcb的連線,形成了乙個鍊錶,我們叫做空事件控制塊鍊錶,如下

os_memclr((int8u *)&oseventtbl[0], sizeof(oseventtbl));

for (ix = 0u; ix < (os_max_events - 1u); ix++)

pevent1                         = &oseventtbl[ix];

pevent1->oseventtype            = os_event_type_unused;

pevent1->oseventptr             = (os_event *)0;

#if os_event_name_en > 0u

pevent1->oseventname            = (int8u *)(void *)"?";

#endif

oseventfreelist                 = &oseventtbl[0];

#else

oseventfreelist                 = &oseventtbl[0];     

oseventfreelist->oseventtype    = os_event_type_unused;

oseventfreelist->oseventptr     = (os_event *)0;  

這段**類似於tcb初始化鏈結的**,引入了乙個新的全域性變數oseventfreelist代表系統空閒事件控制塊的指標,連線好了之後,使用時方法如下

pevent = oseventfreelist;                             

if (oseventfreelist != (os_event *)0) else {

ptcb->ostcbstatpend = os_stat_pend_ok;

也就是說,timetick工作的時候在將ostcbdly遞減,當遞減到0的時候,檢測ostcbstat,如果這是乙個事件,那麼ptcb->ostcbstat  &= (int8u)~(int8u)os_stat_pend_any;這句話能夠讓任務成為ready狀態,同時ostcbstatpend設定為os_stat_pend_to,是的任務能夠在下面的排程中執行起來.

但是,這個請求並不是被刪除了,而是依舊存在於任務ecb中,當系統post訊息的時候,依舊會將訊息給之前等待的任務.

事件的基本排程過程就是如上所說,下面將講述如何具體的對各個訊號量進行呼叫和排程.

C OS 任務控制塊

c os 是通過任務控制塊來管理任務的。任務控制塊是乙個基於鍊錶的資料結構,任務控制塊主要用於記錄任務的堆疊棧頂指標 指向下乙個任務控制塊的指標 任務等待的延遲時間 任務的當前狀態標誌與任務的優先級別等一些與任務管理有關的屬性。當任務的cpu使用權被剝奪時,c os 用任務控制塊來儲存該任務的狀態,...

uC OS ll 任務 任務控制塊 任務控制鍊錶

第二章 2.1任務 又稱為執行緒 組成部分 任務程式 任務堆疊 任務控制塊 分類 使用者任務 解決應用問題 系統任務 為應用程式提供服務 uc os ll在管理任務時將每個任務作為乙個節點,鏈結成任務鍊錶,最多可對64個任務進行管理。狀態 典型地 每個任務都是乙個無限的迴圈。每個任務都處在以下5種狀...

ucos ii的任務控制塊

在作業系統初始化函式osinit執行之後,使用者可以呼叫ostaskcreate或者ostaskcreateext函式來建立使用者任務,因為這兩個函式是核心用來建立任務的,不允許使用者進行修改,因此被稱為系統服務。使用者任務的程式是以函式的形式遊使用者編寫,稱為使用者函式,和作業系統提供的服務劃分了...