線程方法在基于USB接口的激光粒度儀中的應用

   1系統原理結構與數據采集卡

    1.1系統原理與結構

            

    系統原理結構圖如圖1所示。由激光器發出的光束經空間濾波器擴束成平行單色光。當該平行光照射在測量區中的顆粒群時便產生光的衍射現象。衍射散射光的強度分布與測量區中被照射的顆粒直徑、顆粒數有關。衍射光被接收透鏡聚焦在半圓多元光電探測器上。此探測器將含有顆粒直徑和顆粒數信息的衍射光信號轉換成相應的電信號，經信號前置處理電路及USB數據采集卡轉換成數字信號送入PC機計算處理，得到顆粒的粒度分布和濃度情況。

            

    1.2數據采集卡簡介

    本系統采用某公司的USB2002型數據采集卡。主要性能指標如下：(a)模擬電壓輸入范圍：±5V，±10V；(b)A/D轉換分辨率：14Bit，32K字FIFO存儲器；(c)32路單端模擬信號輸入；16路雙端模擬信號輸入；(d)轉換速率：400kHz；(c)程控增益(×1、2、4、8)。

    2系統的軟件實現

    2.1線程

    線程指的是程序代碼的執行途徑外加一組操作系統分配的資源(堆棧、寄存器狀態等等)。線程一般分為用戶界面線程和工作者線程兩類，用戶界面線程可以創建窗口并處理發送給這些窗口的消息；工作者線程執行后臺任務，因其不接受用戶的直接輸入，所以不需要窗口和消息循環。線程的應用可以提高CPU的利用率，提高程序的響應能力，降低系統對數據采集速度的影響。

    2.2系統軟件實現

    2.2.1軟件組成

    程序主要由兩部分組成，一是數據采集部分，另一部分為數據處理部分(見圖2)。數據采集部分對USB數據采集卡進行系統初始化、數據讀取并存入數據緩沖區及釋放系統資源停止數據采集等工作。數據處理部分進行原始數據的存儲、數據計算、各個通道數據的數值和直方圖實時顯示以及獲取各通道中的最大值為采集卡程控增益的設置提供依據。由于后者進行的數據計算和圖形操作，需消耗CPU很多時間，在單線程的情況下將會阻塞主線程運行，出現采集數據溢出丟失的現象。

　　為此采用基于線程的多任務編程方法。

    2.2.2數據采集線程

    將數據采集部分定義為工作者線程(數據采集線程)。USB設備與AD轉換進度同步完全由硬件和驅動程序自動完成。用戶若要用程序方式實現連續數據采集，對其軟件實現就顯得極為容易。數據采集線程每次用ReadDeviceAD函數(USB采集卡接口函數)讀取AD數據時，設備驅動程序會按照AD轉換進度將AD數據一一放進用戶數據緩沖區；當完成該次所指定的采樣點數時，便會返回；當再次用這個函數讀取數據時，會接著上一次的位置傳遞數據到用戶數據緩沖區。高速數據采集要求每兩次調用ReadDeviceAD之間的時間間隔越短越好。由圖3數據采集線程流程圖可知，為保證每兩次ReadDeviceAD之間較小的時間間隔，應盡量減少USB設備AD初始化的次數。為此，采用了一次性設置增益的方法。即根據所采信號大小和對應的原增益計算出原始信號大小，然后根據信號應放大的數值換算出合適的增益進行一次設置。另外，設置了一個布爾控制變量(ParaChange)來記錄增益是否被剛剛改變，如果剛剛改變就跳過增益是否應該改變(ADPARA)的判斷直接讀取采集數據從而減少讀取采集數據時間間隔，以利于高速采集。圖3中Runstatus為數據采集線程運行控制布爾變量。

         

    2.2.3數據處理線程

    將數據處理部分定義為數據處理線程，以便處理圖形操作及數據處理等較耗時的工作。最初，數據處理線程不做任何工作，而是在Win32API函數WaitForSingleObject的作用下進入睡眠狀態(見圖2)，此時它不消耗CPU任何時間，可保證數據采集線程代碼有充分的運行機會。當數據采集線程取得指定長度的數據到用戶空間時，再用Win32API函數SetEvent將指定事件消息發送給數據處理線程，則數據處理線程即刻恢復運行狀態，迅速對這批數據進行處理。


    2.2.4數據緩沖隊列

          

　　數據處理線程可能處理花費CPU過多時間的工作，從而導致數據處理線程阻塞；而數據采集線程則在不停地采集數據，這樣數據處理線程很有可能因此而丟失數據采集線程發來的某一段數據。為避免這個問題，建立了數據緩沖隊列。即假設數據采集線程每一次從設備上取出8K數據，那么就創建一個緩沖隊列，在用戶程序中開辟一個兩維數組，如Buffe(Count??1，DataLen??1)，將DataLen視為數據采集線程每次采集的數據長度(DataLen必須等于采集通道數的整數倍)，從而保證采集數據與各通道的一一對應關系。另外，也要注意在USB采集卡每次增益改變時要保證數據采集線程和數據處理線程從第一個緩沖隊列的第一數據存儲和讀取。這可以保證采集數據與各通道的一一對應關系，以防止數據錯位。Count則為緩沖隊列的成員個數。應根據計算機物理內存大小和總體使用情況來設定。假如設成32，則這個緩沖隊列實際上就是數組Buffer(31，8191)的形式，共32個緩沖隊列(數組各維的基為0)。它跟一個普通的緩沖區，如一維數組差不多，唯一不同是，兩個線程首先要通過改變Count字段的值，即Count的索引值(ReadIndex或ProcIndex)來填充和引用某一段DataLen長度的數據緩沖區。需要注意的是，兩個線程不共用一個Count的索引值。具體情況(見圖4)是當數據采集線程在AD部件被初始化之后，首次采集數據時，則將自己的ReadIndex下標置為0，即用第一個緩沖區采集AD數據。當采集完后，則向數據處理線程發送消息，且兩個線程的公共變量Segments加1(Segments變量記錄當前時刻緩沖隊列中有多少個已被數據采集線程使用了，但是卻沒被數據處理線程處理掉的緩沖區數量。)然后再接著將ReadIndex偏移至1，再用第二個緩沖區采集數據。再將Segments加1，至到Readlndex等于32為止，然后再回到0位置，重新開始。而數據處理線程則在每次接受到消息時判斷有多少由于自己被堵塞而沒有被處理的緩沖區個數，然后逐一進行處理，最后再從Segments變量中減去在所接受到的當前事件下所處理的緩沖區個數。因此，即便是數據處理線程由于系統的偶爾繁忙而被堵塞，也很難使數據丟失。而且，通過這種方案，用戶還可以在數據采集線程中對Segments加以判斷，觀察其值是否大于32，如果大于，則緩沖區隊列肯定因數據處理線程的堵塞而被溢出；如果溢出則報警。因此，具有強大的容錯處理能力。