新聞中心

        EEPW首頁 > 嵌入式系統(tǒng) > 設計應用 > 基于VxWorks下的多重定時器設計

        基于VxWorks下的多重定時器設計

        作者: 時間:2011-11-22 來源:網絡 收藏

        是一種嵌入式實時操作系統(tǒng)(RTOS),具有內核小、可裁剪、實時性強等特點。內核(Wind)提供了共享內存、信號量、消息隊列、套接字通信和等多種機制。為了實現UDP網絡的可靠通信,本文利用的多種任務間通信機制和看門狗機制,了一種模型,該模型可以確保數據包的可靠傳遞。

        本文引用地址:http://www.104case.com/article/150034.htm


        1 VxWOrks的時鐘及定時器機制
        1.1 VxWorks延時函數
        VxWorks既提供了延時功能,也提供了時限約束功能。VxWorks系統(tǒng)有2種延時方式:一種是Wind內核提供的taskDelay()函數;另一種是POSIX函數nanosleep()。
        taskDelay()函數以tick作為延時單位,默認情況下1個tick為16.67 ms(1/60 s),可以通過調用sysClkRateSet()函數對tick進行重新設定。taskDelay()函數使調用該函數的任務在指定時間內主動放棄CPU,用于任務調度或等待某一外部事件。nanosleep()函數指定一個以s和ns為單位的睡眠或延時時間。其實,兩個延時函數的精度是相同的,都是以tick為時間基準。不同之處在于,taskDelay(0)有自身意義,用于相同優(yōu)先級任務間的任務調度,而nanosleep(0)是沒有意義的。
        1.2 VxWorks定時器機制
        VxWorks提供一種看門狗定時器機制(watchdogtimer),可以用來處理任務的時限約束。看門狗定時器作為系統(tǒng)時鐘中斷服務程序的一部分來維護,因此,看門狗定時器的回調函數以系統(tǒng)時鐘中斷級作為中斷服務程序執(zhí)行。看門狗定時器回調函數受到中斷服務程序的限制,不能調用可能引起阻塞的函數,比如試圖獲取信號量,調用malloc()和free()等創(chuàng)建和釋放內存函數或執(zhí)行I/O操作。
        POSIX定時器也可以處理任務時限。此外,VxWorks中一些函數具有時限控制的功能,semTake()、msgQSend()、msgQReceive()函數中都有設定時限控制的參數。超時參數NO_WAIT意味著立即返回,而WAIT_FOREVER意味著程序永不超時。


        2 定時器實現要求
        在VxWorks系統(tǒng)下,利用網絡套接字建立UDP協(xié)議的客戶端/服務器通信模式。由于UDP是無連接的協(xié)議,發(fā)送方并不清楚發(fā)出的數據包是否已經正確到達接收方,于是提出一種支持重傳和定時等待確認的協(xié)議。
        這個協(xié)議要求發(fā)送方發(fā)送的數據包與接收方回復的確認包具有對應的序列號,發(fā)送方和接收方都可以通過序列號來判斷是不是想要得到的數據包。序列號是循環(huán)的,考慮到如果序列號太小會出現折返情況產生混淆,所以序列號至少大于2。如果用1個字節(jié)來表示序列號,則可以設定序列號為256。
        發(fā)送方送出一個數據包后啟動一個定時器。這時可能會有4種情況發(fā)生:
        ①發(fā)送方接收到正確序號的確認包,則發(fā)送下一序列號的數據包。
        ②發(fā)送方接收到已經接收過的重復確認包,則丟棄該確認包繼續(xù)等待。如果在超時前收到了正確確認包,則發(fā)送下一序列號的數據包。
        ③定時器超時,沒有收到想要的確認包,則重新發(fā)送數據包,啟動下一定時器。
        ④設定的定時器超時后,沒有收到想要確認包,則通知網絡管理設備。
        接收方在收到所需序列號的數據包后,回復一個確認包給發(fā)送方。如果接收方回復的確認包后沒有正確到達發(fā)送方,則會引起發(fā)送方超時,重新發(fā)送原序列號數據包。接收方收到數據包后,需要檢查數據包序列號。如果是重復序列號數據包,則丟棄,但是依舊回復確認包給發(fā)送方,以免已發(fā)送確認包在發(fā)送過程中丟失。這里支持重傳和定時等待確認協(xié)議。具體要求是,在客戶端通過UDP協(xié)議發(fā)送數據包后啟動一個定時器,等待接收服務器端回復的ACK(acknowl-edgement)確認包。如果成功接收,則繼續(xù)發(fā)送下一序列號的數據包;如果超時后還沒有收到需要的確認包,則重新傳輸原序列號的數據包。圖1所示為數據包均按時、正確地接收的情況。

        一般情況下,假定啟動定時器30 ms內可以完成從發(fā)送數據包到接收ACK確認包的全過程,但是由于某些原因使得30 ms內無法收到確認包,則會重傳原數據包,并啟動一個稍長的40 ms定時器。如果40 ms還無法收到確認,則再次重傳原數據包,并啟動一個考慮到最差情況的60 ms定時器。如果依舊無法收到確認則不再發(fā)送,通知網絡管理設備。
        出現定時器超時情況有3種可能:發(fā)送方發(fā)送數據包過程中丟包;接收方發(fā)送確認包過程中丟包;從發(fā)送數據包到確認包到達發(fā)送方過程中,延時時間超過定時時間。造成超時有兩方面原因:一是,雙方終端在接收數據包時由于緩沖問題不能及時處理,使得終端出現延時接收數據包或丟包;二是,通信鏈路發(fā)生斷鏈情況,導致雙方無法進行通信。從圖2中可以看到,如果鏈路沒有斷開,則包含3種情況的三重定時器超時情況。


        3 多重定時器
        3.1 方案
        選用看門狗定時器機制來設計??撮T狗定時器操作較為簡單,只有4個函數,即wdCreate()、wdDelete()、wdStart()、wdCancel()。看門狗定時器與調用任務異步執(zhí)行,并不阻塞調用任務,所以看門狗定時器很適合多任務的非阻塞計時。
        當看門狗定時器啟動后,如果在規(guī)定的30 ms內收到了正確的確認包,就會將定時器取消掉,繼續(xù)發(fā)送下面的數據包。如果30 ms規(guī)定時間內沒有收到確認數據包ACK,則需要重新發(fā)送數據包,并啟動第2個40 ms的定時器。VxWorks中單CPU的任務間常用通信機制是消息隊列。當定時器到時后利用消息隊列向發(fā)送任務發(fā)送消息,通知發(fā)送任務重新發(fā)送數據包,啟動下一定時器。看門狗定時器的回調函數可以執(zhí)行msgQSend()這種向消息隊列發(fā)送消息的函數,我們通過msgQSend()函數向主任務發(fā)送時限已達消息。但是,將msgQSend()的延時參數設為wAIT_FOREVER時,消息隊列中一旦沒有了可用緩沖,則進入等待狀態(tài)。由于中斷服務程序優(yōu)先級高,而從消息隊列中接收消息的優(yōu)先級低,當有任務準備從消息隊列中取消息時,要等待中斷服務程序執(zhí)行完畢,則消息隊列始終處于已滿狀態(tài),造成系統(tǒng)死鎖。如果將msgQSend()函數中的延時參數改為NO_WAIT,則可避免一直等待向消息隊列發(fā)消息的情況,一旦消息隊列已滿就將該消息丟棄。但這樣一來,向接收端發(fā)送數據包任務接收不到定時器超時消息,不會重發(fā)原序列號數據包和啟動下一定時器,所以使用參數NO_WAIT也不可行。

        這里提出一種避免上述情況造成系統(tǒng)死鎖的方法,即使用信號量機制來使msgQSend()不在中斷服務程序中執(zhí)行。通過使用信號量的任務間同步機制來實現這個功能。釋放信號量函數semGive()不像msgQSend()那樣需要在消息隊列中等待,一旦執(zhí)行就可以馬上釋放信號量,從而避免了沖突。
        由于任務中事件發(fā)生有一定間隔,不必選用計數器信號量,所以選用最常用的二進制信號量。首先建立3個先進先出的二進制信號量,設定可調用信號量為空。然后在看門狗定時器的回調函數中使用semGive()函數來釋放信號量,重建一個任務在任務起始使用semTake()函數來獲取信號量。當獲得信號量后,通過msgQSend(,,,WAIT_FOREVER,)函數向消息隊列中發(fā)送超時消息,而且保證只要消息隊列有可用緩沖,就一定可以將消息送出。本文給出一個多重定時器的任務框架,如圖3所示。


        上一頁 1 2 下一頁

        評論


        相關推薦

        技術專區(qū)

        關閉
        主站蜘蛛池模板: 东丽区| 榆树市| 丰镇市| 乐至县| 麦盖提县| 三河市| 永和县| 托克逊县| 长泰县| 二连浩特市| 通州市| 禄劝| 灌阳县| 淅川县| 长治县| 新泰市| 吕梁市| 蒲江县| 涞源县| 鄂伦春自治旗| 大同县| 商河县| 天峨县| 清镇市| 华阴市| 玉树县| 延安市| 石林| 西乡县| 龙胜| 兰州市| 新宁县| 永州市| 舟山市| 福清市| 隆尧县| 富源县| 尤溪县| 阿勒泰市| 大荔县| 福鼎市|