Visual Studio中串行通信方法實時性能測試

摘要：為合理、高效地應用Visual Stuclio中的串口通信方法，利用Win32 API函數QueryPerformanCeCounter和QueryPerformanceFrequecy設計出能比較精確測試、分析基于Visual Basic中的ActiveX控件、Visual C++中的ActiveX控件和Win32 API函數的3種Visual Stuclio平臺上串行通信方法的實時性能測試系統。該系統的硬件由4臺配置基本相同的PC和連接它們的RS-232C接口線構成，軟件包括串行數據發送模塊、基于以上方法的串行數據接收模塊及相關分析模塊。實驗結果表明：API方法的通信響應速度比vc控件法、VB控件法分別快約175%、220%，數據接收速度分別快約8倍、9倍。

關鍵詞：串行通信；ActiveX控件；API函數；實時性

文獻標志碼：A

文章編號：1674-5124（2015）02-0124-05

引 言

Visual Studio中的串行通信一般指在VisualC++、Visual Basic，集成開發環境中實現的串行通信。在Visual Basic集成開發環境中通常借助ActiveX控件完成串行通信，在Visual C++中通常采用ActiveX控件或者API技術進行串行通信；本文將它們分別簡稱為串行通信的VB控件法、VC控件法、API法。人們就如何利用這些方法進行有效通信已展開了廣泛的應用研究[4-6]，分析和比較這些方法的實時性有助于合理、高效地選用它們。廖施等曾采用Win32 API函數GetSystemTime初探了VC控件法、API法串行通信的響應快慢。為精確、全面了解這些方法的實時性，本文擬展開深入研究。

l.PC時間的精確獲取

Visual Studio中串行通信方法的實時性體現在兩個方面：通信響應的實時性即對到達串口的數據的響應快慢，以及從串口緩沖區接收數據的快慢。顯然，獲取PC時間的精度越高，測試這兩項性能指標就越精確。通常采用GecSyscemTime、GecTickCount等Win32 API函數比較精確地獲得計算機時間[7-8]，其準確度均為毫秒級別，然而，毫秒級的分辨率不足以測試串行數據的接收速度。

Win32 API函數QueryPerformanceCounter以滴答數記錄目前系統從最近一次開機起至當前的運行時間。滴答的頻率可通過QueryPerformanceFrequency函數獲取。系統的運行時間可表示為滴答數與滴答頻率之積。

為了解該方式獲得系統時間的精度，在Visual C++開發環境中設計了一個測試軟件，該軟件先借助函數QueryPerformanceFrequency獲得滴答頻率，接著循環通過函數GetSystemTime、QueryPerformanceCounler依次獲取當前系統時間、系統運行滴答數的循環體，循環2000次，然后分析兩種方式獲得的前后連續兩次循環的時間及間隔。時間間隔分別為當前的系統時間與上次循環的系統時間之差、當前系統運行滴答數與上次循環時的系統運行滴答數之差再除以滴答頻率。循環時間表示從循環開始到當前所消耗的時間，在數值上等于之前循環時間間隔之和。該軟件在一臺主頻為3GHz、操作系統為Windows XP的PC上運行，測得的一次結果前990次循環情況如表l所示。其中，N、ts、△ts、tSA、Cs、Δtc、tCA分別表示循環次數、系統時間、由系統時間差獲得的循環間隔時間、循環時間、系統運行滴答數、由滴答數獲得的循環間隔時間、循環時間，為方便比較，表中Δtc、ΔtA項只精確到小數點后3位，也就是精確到微秒。

實驗中獲得的滴答頻率為2999690000Hz。從表l中的tSA、tCA項可以看出：這兩種方式獲得的循環時間大體一致，不同點在于基于滴答方式獲得的時間可精確到微秒，以GecSyslemTime獲得的時間最多精確到毫秒。而表1中的At。項顯示，系統時間是以15ms或16ms跳變的，即其分辨率為15ms或16ms。當串行通信的響應時間、數據接收時間遠大于15ms或16ms時，利用該方式測試串行通信的實時性能才比較準確、可靠。通過該方式獲得的串行通信響應時間，API法比VC控件法快15ms或16mS，恰好為該方式的時間分辨率，其無法測試出串行通信數據接收的實時性，因此不太可靠。表1中的Δtc項表明，滴答方式以微秒的精度記錄著系統的運行時間。Δtc項各數據不相等或不近似相等是因Windows系統的多任務工作模式引起的。因此，為精確、可靠地分析Visual Stuclio中串行通信方法的實時性能，本文將采用以滴答數記錄系統運行時間的方式來獲取PC時間。

2.測試系統設計

如圖l所示，PCo、PC，、PC2、PC34臺PC機經過RS-232接口進行串行通信。其中，PCo為數據發送端，其余為數據接收端。PC，、PC2、PC3的RS-232接口線型號、長度相同，它們并行接入PCo的RS-232接口。

在Visual Basic環境中開發出了數據串行發送軟件?；赩C控件法、VB控件法、API法實現的數據串行接收通信軟件分別運行在PC，、PC2、PC3上，對于到達串口的數據，它們分別以消息響應、事件驅動、消息響應的方式予以串行通信響應，在響應處理中接收這些數據。前兩者的響應函數可直接借助于微軟基礎類庫（MFC）自動生成，API法的響應消息則由用戶定制，手動添加響應函數。前兩者的串行接收事件或消息由系統產生，API法則通過用戶啟動的串口監視線程產生。串行通信響應時間為從數據到達串口至串行接收軟件開始響應的時間。由于電信號在導線中以近似于光速傳送，且PCo與PC，、PC2、PC3間的RS-232接口線長度一般小于15m，數據從PCo串口發出至各串口的時間可忽略，故串行通信響應時間可近似為數據從PCo串口發出至串行接收軟件開始響應的這段時間。若PCO～PC3上的Windows系統同時開始運行，則PC，、PC2、PC3上各串行通信的響應時間等于它們在響應函數開始處與PCo發送數據結束處的系統運行時間之差。這些響應時間直接體現VC控件法、VB控件法、API法的串行通信響應快慢。

VB控件法、VC控件法均通過MFC中的CM-SComm類型的通信控件對象實現數據的串行接收。在Visual Basic，環境中，CMSComm對象通過其屬性Output、Input分別進行數據的串行發送、接收。在Visual C++環境中，通過其屬性Getlnput串行接收數據。利用API法實現的數據接收軟件則通過API函數ReadFile接收串行數據。通信響應處理中，控件CMSComm對象利用其屬性Input、Getlnput，API函數利用ReadFile接收串行數據的前后分別以滴答方式獲得接收數據前后操作系統的運行時間。接收串行數據前后系統的運行時間差則分別為VB控件法、VC控件法、API法實現串行通信的數據接收時間，直接反應出這些方法串行接收數據的速度。

3.實驗

實驗中，PCo-PC3的配置相同，操作系統為2002版的Microsoft windows xp professional，CPU為3.OOGHz的Intel（R） Pentium（R），1.00GB的內存，160GB的硬盤。各PC采用3m長的RS-232C接口，總線經過PC上的DB-9類型串口連接起來。實驗時只使用了RS-232C接口總線的RXD、TXD、GND 3根線，并行接收方的RXD、TXD線分別與發送方的TXD、RXD線相連。實驗中通信串口選為COM1、波特率為9600bit/s、8位數據位、1位停止位、無奇偶校驗。另外，為降低Windows系統的多任務特性對測試串口通信實時性精度的影響，實驗中借助Windows系統上的任務管理器將各臺PC上Windows進程限制為操作系統正常運行所需的相同的23個。

實現PCO～PC3上各Windows系統同時開始運行非常困難。在進行串行通信實時性能測試前，本文先對PCO～PC3上各Windows系統的運行時間進行標定。

3.1 系統運行時間標定

PCO～PC3上各Windows系統運行時間可通過網絡方式一致化它們的格林威治時間而實現標定，但因Windows系統的多任務性等原因，該方式不精確。本文采用如圖2所示的系統對各PC的Windows系統運行時間進行標定。

標定時，PC上運行串行數據發送軟件，PCo～PC3上均運行上述基于API法的串行數據接收軟件。由于PCO～PC3的配置相同（包括軟、硬件），而串行數據又同時到達PCo～PC3各串口，故PCO～PC3上的串行通信軟件可視為同時響應，以滴答方式記錄響應時PCO～PC3上各操作系統的運行時間，即可完成這些系統運行時間的標定。

實驗中通過QueryPerformanc，eFrequency函數獲得PCO～PC3的滴答頻率分別為：2999740000.2999700000，2999710000，2999730000Hz，以滴答方式獲得的其中連續10次各Windows系統運行時間標定實驗結果如表2所示。表中，Ⅳ為實驗序號，前4個分別表示串行通信響應時PCo、PC，、PC2、PC3上Windows系統的運行時間，后3個分別為PC，、PC2、PC3上Windows系統運行時間與PCo上Windows系統運行時間的差值。分析可知，Δto1、Δt02、Δt03的平均值分別為376595，727357，l215916μS，標準方差分別為1.3，1.9，2.3μS。它們的波動性因Windows系統的多任務特性所致，其高精密性表明了實驗的正確性、可靠性。

3.2 響應實時性測試

標定了上述PC機上操作系統運行時間，在各PC機不關機、不重新啟動的情況下（否則，各PC上的系統運行時間將發生變化而需重新標定），進行通信響應實時性的測試。此時，將PCO～PC3按照圖1所示的結構通過RS-232C接口總線連接起來。利用VB控件實現的數據發送軟件及基于VC控件法、VB控件法、API法實現的數據串行接收軟件分別運行在PCo、PC，、PC2、PC3上。以滴答方式記錄各PC上操作系統時間的一組連續10次實驗結果，如表3所示。

表中，Ⅳ為實驗序號，第1個為數據發送結束時PCo上Windows系統的運行時間，接著3個分別表示串行通信響應時PCi、PC2、PC3上Windows系統的運行時間，后3個分別VC控件法、VB控件法、API法通信的響應時間，在數值上分別等于tll-tlo-Ato，、ti2-t10-Δt02、t13-t10-Δt03。分析可知，Δtl1、Δt12、Δtl3的平均值分別為5954，7019，2163μs，標準方差分別為2.8，2.9，3.0μs。由此可知，API法通信響應最快，VC控件法次之，VB控件法通信響應最慢。本文進行了多次同樣的實驗，實驗結果表現出來的特征和上述一致。

3.3 接收數據實時性測試

類似于串行通信響應實時性測試，本文進行了接收串行數據的實時性測試，以滴答方式記錄接收數據前后操作系統的運行時間，二者的差即為接收串行數據所消耗的時間。

每一組測試均發送2000個隨機的浮點型數據，每個浮點4個字節，共8000個字節。實驗中發現，基于VC控件法、VB控件法、API法實現的數據串行接收通信軟件每次均能接收8個字節即2個浮點型數據，這樣，每組測試可以實現連續1000次接收8個字節所消耗時間的測試。本文做了多組實驗，其測試結果近似相同，其中一組的測試結果如圖3所示。

由圖可知，3種方法實現的串行數據接收軟件在接收數據時，其接收數據所用時間與接收的字節數呈線性關系，API方法的數據接收速度明顯快于VC控件法、VB控件法，后兩者的數據接收速度比較接近，VB控件法最慢。統計這1000個測試結果知，每接收8個字節，VC控件法、VB控件法、API方法消耗的平均時間分別為48.7，53.8，5.04μs，標準方差分別為2.3，2.37，0.217μs。

在上述通信實時性能測試實驗中，無論是哪種方法，多次實驗獲得的響應時間、數據接收時間并沒有一個是恒定不變的，而是在一定范圍內波動，這主要是由Windows系統的多任務特性造成的。但它們的標準方差均≤3μs，說明操作系統的多任務特性對測試的影響很小，測試結果比較精確、可靠。

上述實驗表明，API法通信的實時性明顯強于VC控件法和VB控件法，VC控件法次之，VB控件法通信的實時性最差。在通信響應速度方面，API法比VC控件法、VB控件法分別快約175%、220%，在接收數據方面，API法比VC控件法、VB控件法分別快約8倍、9倍。API法通信快于控件法的根本原因在于前者直接通過API函數實現通信，而后者首先需要Comm.drv的解釋，串口設備驅動程序再利用相關的API函數進行通信。在Visual C++中生成的可執行文件，可在Windows系統中直接運行，而在VisualBasic，中生成的執行文件，在Windows系統中需要解釋器的不斷解釋才能一步步地運行，這導致了VC控件法通信的實時性快于VB控件法。

4.結束語

在探索測量PC上Windows操作系統時間方法的過程中分析了GetSystemTime、QueryPerformanc，e-Councer兩個Win32 API函數獲取系統時間的精度，抬m前者的分辨率為15 ms，后者結合QueryPerfor-manc，eFrequency函數可精確到微秒，并選擇以這種滴答方式測量VC控件法、VB控件法、API法3種Vi-sual Studio中常用串行通信方法的實時性能。設計了由串行發送數據的一臺PC、并行接收串行數據的3臺PC構成的串行通信實時性能測試系統，構建了由串行發送數據的一臺PC，并行接收串行數據的用于測試的上述4臺PC組成的標定系統以標定它們操作系統的運行時間。在完成測試用PC上系統運行時間的標定實驗后，展開了3種串行通信方法的響應實時性能、接收數據實時性能的測試工作。實驗結果表明，在本文實驗條件下，API法的通信響應時間和每接收8個字節的串行數據所消耗的平均時間分別為2163，5.04μS，比VC控件法、VB控件法的響應快約175%、220%，接收數據快約8倍、9倍。

工程上實現API法串行通信相對于控件法要復雜些，在Visual Basic，中軟件界面的設計比Visual C++中要容易得多。即VC控件法、VB控件法、API法串行通信的實時性能與其工程實現的難易程度是有些矛盾的：API法串行通信的實時性最好，但界面美化難度大、實現復雜，而VB控件法則恰恰相反。