高速串口的軟件設(shè)計(jì)模式研究

1、高速串口的軟件設(shè)計(jì)模式研究關(guān)鍵詞：高速串口；設(shè)計(jì)模式。Abstract:The high-speed serial communication works with a mass of data streams.The buffer overflows in result of reading delayed insituation of time-limited tasks.The paper proposed a software design model to solve the problem.The design model used Windows API andoverlappe

2、d functions to implement reading and writing operation.Multithread technique was used and synchron 設(shè) ation was discussed.For theapplication of transfer image streams compressed by JPEG with serial communication,the design model was optim 設(shè) ed.The test of transfer-ring image data with s 設(shè) e 640*480,f

3、rame frequency 12Hz,compression ratio 12.5proves that the proposed design model meets the needs ofengineering application.Keywords:high-speed serial communication;design model.0引言。在工業(yè)測(cè)控應(yīng)用領(lǐng)域，PC機(jī)與下位機(jī)主要采用以 RS232、RS422為電氣標(biāo)準(zhǔn)的 串行接口方式。由于串行接口方式的需求依然存在，目前出現(xiàn)了兩種普遍應(yīng)用的串 行接口卡。一類是多串口接口卡，這類接口卡一般采用跳線方式來兼容RS232和RS422

4、兩種標(biāo)準(zhǔn)；另一類則是 USB轉(zhuǎn)串口接口卡，這類接口卡與PC機(jī)采用USB接口方式因而具有熱拔插特性，但在 PC機(jī)中被映射為串口設(shè)備，這一特點(diǎn)使得上位 機(jī)程序可完全按照串口設(shè)備進(jìn)行設(shè)計(jì)。隨著測(cè)控領(lǐng)域?qū)?shù)據(jù)傳輸帶寬的要求不斷增加，串行接口卡呈現(xiàn)出高碼率的特 點(diǎn)，其波特率甚至高達(dá)8M.本文針對(duì)高碼率串口的特點(diǎn)，提出一種上位機(jī)軟件設(shè)計(jì) 模式，解決復(fù)雜任務(wù)環(huán)境下由于碼率高而引起的接收緩沖區(qū)溢出問題。針對(duì)使用串 口傳輸圖像數(shù)據(jù)這一具有特殊要求的應(yīng)用場(chǎng)合，對(duì)該設(shè)計(jì)模式進(jìn)行了改進(jìn)，測(cè)試結(jié) 果表明該設(shè)計(jì)模式具有普遍的 應(yīng) 用價(jià)值。1 MSComm控件的應(yīng)用局限性。MSComm控件是微軟采用ActiveX技術(shù)設(shè)計(jì)的

5、一種應(yīng)用非常普遍的串口控件， 該控件采用事件方式通知應(yīng)用程序串口設(shè)備已接收到一定數(shù)量的數(shù)據(jù)。對(duì)于PC機(jī)配備的標(biāo)準(zhǔn)串口收發(fā)器而言，其波特率一般不超過256000,亦即每秒數(shù)據(jù)吞吐量小于32kB.MSComm控件的接口函數(shù)允許設(shè)置的最大接收緩沖區(qū)為32kB （MSComm提供的設(shè)置接收緩沖區(qū)的參數(shù)為 signed short型），表明在傳輸帶寬完全被占用且 波特率為256000的條件下，應(yīng)用程序讀取串口的最大可允許延時(shí)不超過1s,否則會(huì)造成接收緩沖區(qū)溢出而丟失數(shù)據(jù)1.對(duì)于小規(guī)模的應(yīng)用程序而言，1s的延時(shí)要求很容易滿足，一般不會(huì)出現(xiàn)接收緩 沖區(qū)溢出的情況。對(duì)于高速串口，其波特率一般為2 M至4 M,

6、亦即每秒數(shù)據(jù)吞吐量為0.25 MB至0.5MB,對(duì)于32kB的接收緩沖區(qū)而言，可允許的最大讀取延時(shí)為 64ms至128ms,對(duì)于波特率為8 M的串口卡而言，最大讀取延時(shí)僅為32ms.在采用MSComm控件進(jìn)行高速串口的上位機(jī)軟件設(shè)計(jì)時(shí)，一般在主窗口中響 應(yīng)串口事件，不具備太大的靈活性2.主程序中一些具有可觀耗時(shí)的任務(wù)或主窗口 的屏幕刷新均有可能導(dǎo)致讀取延時(shí)超過128ms.此外，在該臺(tái)計(jì)算機(jī)中若同時(shí)運(yùn)行著另一 CPU使用率較高的應(yīng)用軟件，也可能導(dǎo)致響應(yīng)串口事件不及時(shí)。 因此，MSComm 控件在高速串口的上位機(jī)軟件設(shè)計(jì)中具有很大局限性。2基于 Windows API 的串口軟件設(shè)計(jì)。微軟Wind

7、ows平臺(tái)將PC機(jī)的所有外圍設(shè)備均映射為文件，因而對(duì)其讀寫等操作均與讀寫硬盤上的實(shí)際文件相同。對(duì)文件的讀寫操作，Windows API提供了非重疊I/O和重疊I/O兩種方式。調(diào)用一個(gè)讀或?qū)懳募?API函數(shù)時(shí)，在重疊I/O方式 下，無論讀或?qū)懖僮魇欠裢瓿桑?API函數(shù)立即返回；在非重疊I/O方式下，直到 讀或?qū)懖僮魍瓿蓵r(shí)，該 API函數(shù)才返回。在多線程應(yīng)用程序中，重疊 I/O方式具有 更高的效率，在讀寫操作不能立即返回時(shí)，讀寫操作會(huì)自動(dòng)轉(zhuǎn)入后臺(tái)運(yùn)行3.在采用Windows API進(jìn)行串口上位機(jī)軟件設(shè)計(jì)時(shí)，主要涉及的API函數(shù)為ReadFile、WaitForSingleObject、GetO

8、ver-lappedResult 和 ClearCommError.其中， ReadFile函數(shù)用于讀取串口， WaitForSingleObject用于等待重疊I/O事件被激活，GetOverlappedResult用于獲取重疊I/O執(zhí)行結(jié)果，ClearCom-mError則用于清除各種串口錯(cuò)誤同時(shí)返回串口狀態(tài)?；具壿嬃鞒倘鐖D1所示清除用11怖父采用重疊I/O方式讀取串口緩沖區(qū)時(shí)，在讀取到的數(shù)據(jù)還未達(dá)到由用戶設(shè)定的數(shù)量要求時(shí)，Wait ForSingleObject將會(huì)一直等待，若在子線程中則該線程會(huì)處于掛起狀態(tài)。為防止陷入長(zhǎng)期等待，WaitForSingleObject允許設(shè)置超時(shí)返回。

9、寫串口操作與該邏輯流程基本一致，這里不詳述4.3多線程的設(shè)計(jì)模式。多線程設(shè)計(jì)模型。一般而言，在讀取串口數(shù)據(jù)后，需要對(duì)這些數(shù)據(jù)進(jìn)行分包、解算、存儲(chǔ)等操作。 在高速串口上位機(jī)軟件設(shè)計(jì)中，若將讀取串口數(shù)據(jù)和數(shù)據(jù)處理任務(wù)安排在一個(gè)子線 程中執(zhí)行，當(dāng)數(shù)據(jù)處理任務(wù)復(fù)雜繁瑣、耗時(shí)可觀時(shí)，則極易出現(xiàn)讀取串口不及時(shí)而 導(dǎo)致數(shù)據(jù)丟失的現(xiàn)象。因此，在高速串口應(yīng)用軟件設(shè)計(jì)中，必須將讀取串 口數(shù)據(jù)和數(shù)據(jù)處理分別采用兩個(gè) 子線程實(shí)現(xiàn)。如圖2所示為一種可行的多線程設(shè)計(jì)模型。在該模型中，在內(nèi)存開辟了A片與B片兩塊緩存區(qū)，讀取串口數(shù)據(jù)子線程通過寫指針ptrWrite將從串口讀取的數(shù)據(jù)存入緩存區(qū)，數(shù)據(jù)處理子線程則通過讀指針 pt

10、rRead從緩存區(qū)讀取串口數(shù)據(jù)進(jìn)行處理。 為保證數(shù)據(jù)的一致性，讀指針ptrRead與寫指針ptr-Write不能同時(shí)指向同一片緩存 區(qū)。同時(shí)，在讀指針ptrRead所指向的緩存區(qū)串口數(shù)據(jù)被處理完成后應(yīng)交換讀指針 ptrRead與寫指針ptrWrite所指向的緩存區(qū)。圖2多線程設(shè)計(jì)模型在一些特殊應(yīng)用場(chǎng)合如采用高速串口傳輸圖像數(shù)據(jù)，如若設(shè)計(jì)為當(dāng)寫指針ptrWrite指向的緩存區(qū)被寫滿后才交換讀寫指針，則會(huì)出現(xiàn)圖像數(shù)據(jù)流傳輸不均勻 的缺陷，在視覺上則表現(xiàn)為圖像場(chǎng)景快慢不均。因此，采用當(dāng)數(shù)據(jù)處理子線程完成 數(shù)據(jù)處理任務(wù)后立即交換讀寫指針的設(shè)計(jì)方案更具普適性。若當(dāng)A片與B片緩存區(qū)均設(shè)置為5MB,在傳輸帶

11、寬被完全占用的條件下，對(duì)于 波特率為4 M的高速串口，每秒產(chǎn)生0.5MB的數(shù)據(jù)，此時(shí)數(shù)據(jù)處理子線程讀取緩存 區(qū)的最大延時(shí)可達(dá)10s.同步控制邏輯。在圖2中，交換讀指針ptrRead與寫指針ptrWrite指向的緩存區(qū)涉及到兩個(gè)子線程的相關(guān)變量，因此必須考慮這些變量的一致性問題，亦即線程的同步問題。Windows為線程同步提供了關(guān)鍵區(qū)、互斥鎖、信號(hào)量和事件對(duì)象等方式。如圖3所示為采用關(guān)鍵區(qū)和同步事件對(duì)象實(shí)現(xiàn)的同步控制邏輯流程，其中EXCHANGE_ENABLE為讀寫指針是否可交換標(biāo)志。對(duì)于數(shù)據(jù)處理子線程，該線程一直處于掛起狀態(tài)直到同步事件對(duì)象被激活，激活后利用ptrRead指針讀取緩存區(qū)數(shù)據(jù)進(jìn)行

12、后續(xù)處理，之后復(fù)位同步事件對(duì)象并置EXCHANGE_ENABLE為TRUE狀態(tài)。對(duì)于讀取串口子線程，首先檢查EXCHANGE_ENABLE標(biāo)志，若可交換則交換讀寫指 針指向的緩存區(qū)，之后置 EXCHANGE_ENABLE為FALSE狀態(tài)并激活同步事件對(duì)象。此外，為保證邏輯流程的數(shù)據(jù)一致性，兩個(gè)線程中與同步控制相關(guān)的流程必須放在 關(guān)鍵區(qū)中執(zhí)行5.工事區(qū)軸史到用 ptrb itt也4小區(qū)TtUE徒就中口 r線物6田姓師廣悅程n 3同步控制邏我康界4模式的編碼實(shí)現(xiàn)與測(cè)試模式的編碼實(shí)現(xiàn)。本模式以一個(gè)MFC規(guī)則動(dòng)態(tài)鏈接庫(kù)的方式實(shí)現(xiàn)，可以被其他應(yīng)用程序鏈接調(diào)用，提供的外部接口函數(shù)如表 1所示。喪】導(dǎo)出函數(shù)

13、列我導(dǎo)出-一功能CTRliki tiaJ CominSr v初始化中口CTRSetCom mScttings涉資出口琴數(shù)CTROpenComn)打開串U(TRSinriRdComniThrd啟動(dòng)中口添取線程CTRO ct RdCotnmThrciStfl t c次唳布口質(zhì)取線程狀態(tài)C RSiujjRdComtn l hnl停止用口讀取線程CTRCloscCommSrv關(guān)閉出口CTRDfleteS nr P：川刪除讀寫同分叁數(shù)CTRGrtCommDatB孰取出口數(shù)據(jù)rTRWn(nnm寫審口粒送數(shù)據(jù)）其中，CTRInitialCommSrv用于初始化串口服務(wù)，設(shè)置該串口是否采用重疊I/O方式，并返

14、回一個(gè)指向目的串口的句柄，CTRSetCommSettings利用該句柄設(shè)置波特率、數(shù)據(jù)位、停止位、校驗(yàn)方式等參數(shù)，CTROpenComm利用該句柄打開串口開始數(shù)據(jù)收發(fā)工作。CTRStartRdCommThrd啟動(dòng)串口數(shù)據(jù)接收線程，CTRGetCommData讀取已接收到的數(shù)據(jù)。CTR-WrtComm則通過串口向外發(fā)送數(shù)據(jù)測(cè)試及效果評(píng)估。在測(cè)試環(huán)境中，下位機(jī)通過高速串口傳輸JPEG標(biāo)準(zhǔn)的紅外圖像壓縮碼流，圖像尺寸為640*480，壓縮比為12.5，高速串口波特率為2.5M,傳輸帶寬幾乎全部被占用。讀取串口子線程讀取圖像壓縮碼流，數(shù)據(jù)處理子線程對(duì)壓縮碼流進(jìn)行解壓并顯 示圖像，單幅圖像解壓耗時(shí)約為

15、 40ms.如圖4所示為解壓出的紅外灰度圖像。()(b)圖4 粒輸紅外茨度圖像壓縮碼流及解壓泅狀在測(cè)試過程中，在每秒解壓圖像達(dá)12幀的狀態(tài)下，未出現(xiàn)數(shù)據(jù)丟失的情況, 圖像場(chǎng)景勻速。測(cè)試結(jié)果表明，提出的多線程設(shè)計(jì)模式解決了高速串口上位機(jī)軟件 設(shè)計(jì)中因串口緩沖區(qū)溢出導(dǎo)致的數(shù)據(jù)丟失問題，提出的同步控制邏輯解決了串口數(shù) 據(jù)接收與耗時(shí)可觀的后續(xù)數(shù)據(jù)處理任務(wù)之間的同步問題。5結(jié)語(yǔ)?？紤]到串口傳輸帶寬的占用率、后續(xù)數(shù)據(jù)處理任務(wù)的耗時(shí)程度，串口的上位機(jī) 軟件設(shè)計(jì)方法應(yīng)根據(jù)實(shí)際應(yīng)用環(huán)境來選擇。在低速串口和后續(xù)數(shù)據(jù)處理任務(wù)耗時(shí)較 少的情況下，采用微軟的 MSComm控件能減少代碼量、簡(jiǎn)化設(shè)計(jì)；對(duì)于后續(xù)數(shù)據(jù) 處理任務(wù)耗時(shí)較多的情況下， 無論高速串口還是低速串口， 應(yīng)采用多線程設(shè)計(jì)方式, 既能提高數(shù)據(jù)處理的實(shí)時(shí)性，又能降低讀取不及時(shí)而導(dǎo)致串口緩沖區(qū)溢出的風(fēng)險(xiǎn)。參考文獻(xiàn)：1王中訓(xùn)I,徐超?；?VC+6.0的多串口通信方法J.計(jì)算機(jī)應(yīng)用，2008,