第一篇關于軟件工程論文：
關鍵詞：高速串口；設計模式。
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 andoverlapped functions to implement reading and writing operation.Multithread technique was used and synchron設ation was discussed.For theapplication of transfer image streams compressed by JPEG with serial communication,the design model was optim設ed.The test of transfer-ring image data with s設e 640*480,frame frequency 12Hz,compression ratio 12.5proves that the proposed design model meets the needs ofengineering application.
Keywords:high-speed serial communication;design model.
0引言。
在工業測控應用領域，PC機與下位機主要采用以RS232、RS422為電氣標準的串行接口方式。由于串行接口方式的需求依然存在，目前出現了兩種普遍應用的串行接口卡。一類是多串口接口卡，這類接口卡一般采用跳線方式來兼容RS232和RS422兩種標準；另一類則是USB轉串口接口卡，這類接口卡與PC機采用USB接口方式因而具有熱拔插特性，但在PC機中被映射為串口設備，這一特點使得上位機程序可完全按照串口設備進行設計。
隨著測控領域對數據傳輸帶寬的要求不斷增加，串行接口卡呈現出高碼率的特點，其波特率甚至高達8M.本文針對高碼率串口的特點，提出一種上位機軟件設計模式，解決復雜任務環境下由于碼率高而引起的接收緩沖區溢出問題。針對使用串口傳輸圖像數據這一具有特殊要求的應用場合，對該設計模式進行了改進，測試結果表明該設計模式具有普遍 的 應 用價值。
1 MSComm控件的應用局限性。
MSComm控件是微軟采用ActiveX技術設計的一種應用非常普遍的串口控件，該控件采用事件方式通知應用程序串口設備已接收到一定數量的數據。對于PC機配備的標準串口收發器而言，其波特率一般不超過256000,亦即每秒數據吞吐量小于32kB.MSComm控件的接口函數允許設置的最大接收緩沖區為32kB（MSComm提供的設置接收緩沖區的參數為signed short型），表明在傳輸帶寬完全被占用且波特率為256000的條件下，應用程序讀取串口的最大可允許延時不超過1s,否則會造成接收緩沖區溢出而丟失數據[1].
對于小規模的應用程序而言，1s的延時要求很容易滿足，一般不會出現接收緩沖區溢出的情況。對于高速串口，其波特率一般為2 M至4 M,亦即每秒數據吞吐量為0.25 MB至0.5MB,對于32kB的接收緩沖區而言，可允許的最大讀取延時為64ms至128ms,對于波特率為8 M的串口卡而言，最大讀取延時僅為32ms.
在采用MSComm控件進行高速串口的上位機軟件設計時，一般在主窗口中響應串口事件，不具備太大的靈活性[2].主程序中一些具有可觀耗時的任務或主窗口的屏幕刷新均有可能導致讀取延時超過128ms.此外，在該臺計算機中若同時運行著另一CPU使用率較高的應用軟件，也可能導致響應串口事件不及時。因此，MSComm控件在高速串口的上位機軟件設計中具有很大局限性。
2基于Windows API的串口軟件設計。
微軟Windows平臺將PC機的所有外圍設備均映射為文件，因而對其讀寫等操作均與讀寫硬盤上的實際文件相同。對文件的讀寫操作，Windows API提供了非重疊I/O和重疊I/O兩種方式。調用一個讀或寫文件的API函數時，在重疊I/O方式下，無論讀或寫操作是否完成，該API函數立即返回；在非重疊I/O方式下，直到讀或寫操作完成時，該API函數才返回。在多線程應用程序中，重疊I/O方式具有更高的效率，在讀寫操作不能立即返回時，讀寫操作會自動轉入后臺運行[3].
在采用Windows API進行串口上位機軟件設計時，主要涉及的API函數為ReadFile、WaitForSingleObject、GetOver-lappedResult和ClearCommError.其中，ReadFile函數用于讀取串口，WaitForSingleObject用于等待重疊I/O事件被激活，GetOverlappedResult用于獲取重疊I/O執行結果，ClearCom-mError則用于清除各種串口錯誤同時返回串口狀態?；具壿嬃鞒倘鐖D1所示。
采用重疊I/O方式讀取串口緩沖區時，在讀取到的數據還未達到由用戶設定的數量要求時，Wait ForSingleObject將會一直等待，若在子線程中則該線程會處于掛起狀態。為防止陷入長期等待，WaitForSingleObject允許設置超時返回。寫串口操作與該邏輯流程基本一致，這里不詳述[4].
3多線程的設計模式。
3.1多線程設計模型。
一般而言，在讀取串口數據后，需要對這些數據進行分包、解算、存儲等操作。在高速串口上位機軟件設計中，若將讀取串口數據和數據處理任務安排在一個子線程中執行，當數據處理任務復雜繁瑣、耗時可觀時，則極易出現讀取串口不及時而導致數據丟失的現象。因此，在高速串口應用軟件設計中，必須將讀取串 口數據和數據處理分別采用兩個 子 線 程實現。
如圖2所示為一種可行的多線程設計模型。在該模型中，在內存開辟了A片與B片兩塊緩存區，讀取串口數據子線程通過寫指針ptrWrite將從串口讀取的數據存入緩存區，數據處理子線程則通過讀指針ptrRead從緩存區讀取串口數據進行處理。為保證數據的一致性，讀指針ptrRead與寫指針ptr-Write不能同時指向同一片緩存區。同時，在讀指針ptrRead所指向的緩存區串口數據被處理完成后應交換讀指針ptrRead與寫指針ptrWrite所指向的緩存區。
在一些特殊應用場合如采用高速串口傳輸圖像數據，如若設計為當寫指針ptrWrite指向的緩存區被寫滿后才交換讀寫指針，則會出現圖像數據流傳輸不均勻的缺陷，在視覺上則表現為圖像場景快慢不均。因此，采用當數據處理子線程完成數據處理任務后立即交換讀寫指針的設計方案更具普適性。
若當A片與B片緩存區均設置為5MB,在傳輸帶寬被完全占用的條件下，對于波特率為4 M的高速串口，每秒產生0.5MB的數據，此時數據處理子線程讀取緩存區的最大延時可達10s.
3.2 同步控制邏輯。
在圖2中，交換讀指針ptrRead與寫指針ptrWrite指向的緩存區涉及到兩個子線程的相關變量，因此必須考慮這些變量的一致性問題，亦即線程的同步問題。Windows為線程同步提供了關鍵區、互斥鎖、信號量和事件對象等方式。
《高速串口的軟件設計模式研究》
關鍵詞：高速串口；設計模式。
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 andoverlapped functions to implement reading and writing operation.Multithread technique was used and synchron設ation was discussed.For theapplication of transfer image streams compressed by JPEG with serial communication,the design model was optim設ed.The test of transfer-ring image data with s設e 640*480,frame frequency 12Hz,compression ratio 12.5proves that the proposed design model meets the needs ofengineering application.
Keywords:high-speed serial communication;design model.
0引言。
在工業測控應用領域，PC機與下位機主要采用以RS232、RS422為電氣標準的串行接口方式。由于串行接口方式的需求依然存在，目前出現了兩種普遍應用的串行接口卡。一類是多串口接口卡，這類接口卡一般采用跳線方式來兼容RS232和RS422兩種標準；另一類則是USB轉串口接口卡，這類接口卡與PC機采用USB接口方式因而具有熱拔插特性，但在PC機中被映射為串口設備，這一特點使得上位機程序可完全按照串口設備進行設計。
隨著測控領域對數據傳輸帶寬的要求不斷增加，串行接口卡呈現出高碼率的特點，其波特率甚至高達8M.本文針對高碼率串口的特點，提出一種上位機軟件設計模式，解決復雜任務環境下由于碼率高而引起的接收緩沖區溢出問題。針對使用串口傳輸圖像數據這一具有特殊要求的應用場合，對該設計模式進行了改進，測試結果表明該設計模式具有普遍 的 應 用價值。
1 MSComm控件的應用局限性。
MSComm控件是微軟采用ActiveX技術設計的一種應用非常普遍的串口控件，該控件采用事件方式通知應用程序串口設備已接收到一定數量的數據。對于PC機配備的標準串口收發器而言，其波特率一般不超過256000,亦即每秒數據吞吐量小于32kB.MSComm控件的接口函數允許設置的最大接收緩沖區為32kB（MSComm提供的設置接收緩沖區的參數為signed short型），表明在傳輸帶寬完全被占用且波特率為256000的條件下，應用程序讀取串口的最大可允許延時不超過1s,否則會造成接收緩沖區溢出而丟失數據[1].
對于小規模的應用程序而言，1s的延時要求很容易滿足，一般不會出現接收緩沖區溢出的情況。對于高速串口，其波特率一般為2 M至4 M,亦即每秒數據吞吐量為0.25 MB至0.5MB,對于32kB的接收緩沖區而言，可允許的最大讀取延時為64ms至128ms,對于波特率為8 M的串口卡而言，最大讀取延時僅為32ms.
在采用MSComm控件進行高速串口的上位機軟件設計時，一般在主窗口中響應串口事件，不具備太大的靈活性[2].主程序中一些具有可觀耗時的任務或主窗口的屏幕刷新均有可能導致讀取延時超過128ms.此外，在該臺計算機中若同時運行著另一CPU使用率較高的應用軟件，也可能導致響應串口事件不及時。因此，MSComm控件在高速串口的上位機軟件設計中具有很大局限性。
2基于Windows API的串口軟件設計。
微軟Windows平臺將PC機的所有外圍設備均映射為文件，因而對其讀寫等操作均與讀寫硬盤上的實際文件相同。對文件的讀寫操作，Windows API提供了非重疊I/O和重疊I/O兩種方式。調用一個讀或寫文件的API函數時，在重疊I/O方式下，無論讀或寫操作是否完成，該API函數立即返回；在非重疊I/O方式下，直到讀或寫操作完成時，該API函數才返回。在多線程應用程序中，重疊I/O方式具有更高的效率，在讀寫操作不能立即返回時，讀寫操作會自動轉入后臺運行[3].
在采用Windows API進行串口上位機軟件設計時，主要涉及的API函數為ReadFile、WaitForSingleObject、GetOver-lappedResult和ClearCommError.其中，ReadFile函數用于讀取串口，WaitForSingleObject用于等待重疊I/O事件被激活，GetOverlappedResult用于獲取重疊I/O執行結果，ClearCom-mError則用于清除各種串口錯誤同時返回串口狀態?；具壿嬃鞒倘鐖D1所示。
采用重疊I/O方式讀取串口緩沖區時，在讀取到的數據還未達到由用戶設定的數量要求時，Wait ForSingleObject將會一直等待，若在子線程中則該線程會處于掛起狀態。為防止陷入長期等待，WaitForSingleObject允許設置超時返回。寫串口操作與該邏輯流程基本一致，這里不詳述[4].
3多線程的設計模式。
3.1多線程設計模型。
一般而言，在讀取串口數據后，需要對這些數據進行分包、解算、存儲等操作。在高速串口上位機軟件設計中，若將讀取串口數據和數據處理任務安排在一個子線程中執行，當數據處理任務復雜繁瑣、耗時可觀時，則極易出現讀取串口不及時而導致數據丟失的現象。因此，在高速串口應用軟件設計中，必須將讀取串 口數據和數據處理分別采用兩個 子 線 程實現。
如圖2所示為一種可行的多線程設計模型。在該模型中，在內存開辟了A片與B片兩塊緩存區，讀取串口數據子線程通過寫指針ptrWrite將從串口讀取的數據存入緩存區，數據處理子線程則通過讀指針ptrRead從緩存區讀取串口數據進行處理。為保證數據的一致性，讀指針ptrRead與寫指針ptr-Write不能同時指向同一片緩存區。同時，在讀指針ptrRead所指向的緩存區串口數據被處理完成后應交換讀指針ptrRead與寫指針ptrWrite所指向的緩存區。
在一些特殊應用場合如采用高速串口傳輸圖像數據，如若設計為當寫指針ptrWrite指向的緩存區被寫滿后才交換讀寫指針，則會出現圖像數據流傳輸不均勻的缺陷，在視覺上則表現為圖像場景快慢不均。因此，采用當數據處理子線程完成數據處理任務后立即交換讀寫指針的設計方案更具普適性。
若當A片與B片緩存區均設置為5MB,在傳輸帶寬被完全占用的條件下，對于波特率為4 M的高速串口，每秒產生0.5MB的數據，此時數據處理子線程讀取緩存區的最大延時可達10s.
3.2 同步控制邏輯。
在圖2中，交換讀指針ptrRead與寫指針ptrWrite指向的緩存區涉及到兩個子線程的相關變量，因此必須考慮這些變量的一致性問題，亦即線程的同步問題。Windows為線程同步提供了關鍵區、互斥鎖、信號量和事件對象等方式。
