VxWorks下的多重定時(shí)器設(shè)計(jì)

VxWorks下的多重定時(shí)器設(shè)計(jì)

?? VxWorks是一種嵌入式實(shí)時(shí)操作系統(tǒng)(RTOS)，具有內(nèi)核小、可裁剪、實(shí)時(shí)性強(qiáng)等特點(diǎn)。VxWorks內(nèi)核(Wind)提供了共享內(nèi)存、信號量、消息隊(duì)列、套接字通信和定時(shí)器等多種機(jī)制。為了實(shí)現(xiàn)基于UDP網(wǎng)絡(luò)的可靠通信，本文利用VxWorks的多種任務(wù)間通信機(jī)制和看門狗定時(shí)器機(jī)制，設(shè)計(jì)了一種多重定時(shí)器模型，該模型可以確保數(shù)據(jù)包的可靠傳遞。

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

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

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

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

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

3．2 主要實(shí)現(xiàn)代碼
??? 一個(gè)三重定時(shí)器的主要實(shí)現(xiàn)代碼如下：

??? 以上程序中通過sysClkRateSet(100)將最小延時(shí)單位tick修改成10 ms，它是幾個(gè)定時(shí)時(shí)間(30 ms、40 ms、60ms)的最大公約數(shù)。通過抓包軟件Ethereal抓包，查看發(fā)送時(shí)間。以30 ms為例，抓包100次的平均定時(shí)時(shí)間在25 ms左右。出現(xiàn)這種情況的原因是，延時(shí)N個(gè)tick實(shí)際是延時(shí)(N-1)tick~N·tick。由于是等可能概率，則它的數(shù)學(xué)期望是(N+1／2)。對于tick為10 ms，30 ms即N=3，數(shù)學(xué)期望為25 ms。示意圖如圖4所示。

??? 延時(shí)精度為1／N秒，N越大越精確。于是調(diào)用函數(shù)synClkRateSet(500)，可以使定時(shí)的最大誤差不超過2 ms。但是如果時(shí)鐘頻率太高，會造成系統(tǒng)在時(shí)鐘中斷處理方面開銷太大，影響系統(tǒng)的任務(wù)調(diào)度，最好通過實(shí)驗(yàn)選用較為合適的時(shí)鐘頻率。這里選用sysClkRate-Set(200)。

結(jié) 語
??? 本文針對VxWorks下UDP網(wǎng)絡(luò)通信中的可靠傳輸問題，提出了一個(gè)支持重傳和定時(shí)等待確認(rèn)的協(xié)議，并利用VxWorks系統(tǒng)提供的信號量同步、消息隊(duì)列和看門狗定時(shí)器等多種機(jī)制，綜合設(shè)計(jì)了一種可擴(kuò)展的三重定時(shí)器。針對遇到的具體問題，筆者還進(jìn)行了一定的優(yōu)化處理。這種多重定時(shí)器模型已在筆者所研究的項(xiàng)目中得到利用，驗(yàn)證了其可行性和相對穩(wěn)定性。這種多重定時(shí)器模型并不完全適合所有環(huán)境，需要根據(jù)具體情況改進(jìn)和優(yōu)化。