|
目前，一般警報發(fā)放系統是基于PC機/單片機技術(shù)的半雙工的點(diǎn)對多點(diǎn)天線(xiàn)專(zhuān)用遙控網(wǎng)。系統中控制中心由PC/工控機擔任，各執行終端以單片機為核心的控制器來(lái)執行控制功能。從使用管理和建設角度看，有如下不足：基于PC機/工控機技術(shù)的控制中心單位體積大，設備成本較高，且由于承擔的任務(wù)相對簡(jiǎn)單，故使用效率不高，而基于單片機技術(shù)的控制執行終端能較好地完成解碼控制功能，但不能滿(mǎn)足警報發(fā)放技術(shù)的信息交互化改進(jìn)和運行管理的需求，例如由單片機完成高質(zhì)量，高效率的音頻編解碼，錄入和還原來(lái)實(shí)現信息交互化功能是一個(gè)比較棘手的問(wèn)題。本文設計的目的是鑒于以上需求，采用硬軟件資源豐富且可裁減的數據處理能力強大且具備一般單片機控制功能的嵌入式技術(shù)，設計一種體積小，成本低，功能強，開(kāi)發(fā)周期短的嵌入式中心控制器和終端控制器，以對原有警報發(fā)放系統進(jìn)行改進(jìn)。 一、系統整體介紹 改進(jìn)的系統由一個(gè)控制中心和多個(gè)終端構成�？刂浦行暮徒K端之間使用無(wú)線(xiàn)數傳模塊來(lái)構成無(wú)線(xiàn)數據通路。每個(gè)終端配置唯一的地址，當發(fā)放警報時(shí)，控制中心既可以以群發(fā)的方式發(fā)放警報內容，又可以通過(guò)指定終端地址，以點(diǎn)對點(diǎn)的方式向某一指定的終端主機發(fā)放指定的警報內容。 終端控制器的音頻輸出端口和功放相連。當終端接收到屬于本機的警報指令后，根據不同的警報內容，調用不同的音頻文件，最后由音頻輸出單元和功放發(fā)放。 為保證控制器的可靠性，需要定時(shí)進(jìn)行檢測。檢測時(shí)主控中心以串行點(diǎn)名的方式對每個(gè)終端進(jìn)行查詢(xún)。檢測的內容包括中心和終端的無(wú)線(xiàn)數據通路和音頻發(fā)放設備的工作情況。為了能正確了解終端設備的工作情況，在終端音頻輸入接口配備麥克風(fēng)，用于采集發(fā)放的警報聲音，采集的聲音壓縮文件再通過(guò)無(wú)線(xiàn)網(wǎng)絡(luò )返回給主控中心，再在主控中心進(jìn)行處理，分析終端的整套設備工作正常與否。 一般來(lái)說(shuō)嵌入式控制器是針對某一特定功能來(lái)設計的，它可被認為是一種具有特定功能的專(zhuān)用計算機。在本系統中，控制中心和終端控制器需要實(shí)現的主要任務(wù)都是數據傳輸和音頻的處理，所以在硬件資源選擇上，中心和終端可以使用同一套硬件設備。在系統組網(wǎng)時(shí)，只需在中心控制器和終端控制器上安裝不同的應用軟件即可完成系統要求。所以在設計開(kāi)發(fā)中，一旦實(shí)現了控制中心的功能，也就是基本上完成了終端的設計任務(wù)。 二、系統硬件軟件資源的選擇 1 系統選擇 為了能方便的實(shí)現音頻的處理功能，加快系統的開(kāi)發(fā)時(shí)間，選擇Windows CE作為控制器的操作系統。雖然Windows CE是一個(gè)軟實(shí)時(shí)的操作系統，但是完全可以滿(mǎn)足本系統隊實(shí)時(shí)性的要求。同時(shí)Windows CE具有出色的圖形用戶(hù)界面，強大的多媒體功能，良好的通信能力。界面友好的嵌入式平臺工具Platform Builder為Windows CE的制定提供了方便。具有和Visual C++基本相同特性的應用程序開(kāi)發(fā)工具Embedded Visual C++又為熟悉Windows編程的開(kāi)發(fā)人員提供了捷徑。所以使用具有功能完備的API函數庫的Windows CE操作系統，能使系統顯示出很大的優(yōu)越性。 2 硬件結構 目前已有多款CPU內核支持WinCE操作系統，例如ARM、x86、MIPS、PowerPC、SH等。目前市場(chǎng)上采用MIPS和ARM架構的CPU占據了主導地位。本系統控制中心的CPU選擇Intel @XScale PXA255微控制處理器它遵從ARM 5V.TE體系構架，運行速度高達400MHz，Intel超流水線(xiàn)技術(shù)和獨特的動(dòng)態(tài)功率管理技術(shù)，使它兼有高性能與低功耗的特點(diǎn)。為了達到嵌入Win CE操作系統的要求，系統配置64M SDRAM和32M Flash。系統還配置LCD顯示系統和觸摸屏。音頻控制器采用TI公司的TSC2301 Audio Codec芯片，該芯片支持AC’97標準20位立體聲編/解碼、支持可編程采樣率、輸入輸出增益和數字音響處理功能，同時(shí)集成觸摸屏控制功能。它也是本系統硬件的重要組成部分�；诖谕ㄐ诺臒o(wú)線(xiàn)數傳模塊在實(shí)際應用中已經(jīng)很成熟，在市場(chǎng)上也有多種可供選擇的產(chǎn)品。本文對此不作詳細介紹。以下是系統硬件結構圖。 三、Windows CE操作系統和應用程序 1 系統的制定 每一個(gè)Windows CE操作系統都是基于固定的硬件平臺來(lái)運行的。一個(gè)完整的Windows CE操作系統的基本內容包括以下幾個(gè)方面： 1）. Bootloader，用于加載Windows CE操作系統的程序； 2）. CPU初始代碼，基于特定的CPU系列； 3）. 驅動(dòng)程序，包括鍵盤(pán)、鼠標、聲卡、COM等等，不同的硬件設備可能有不同的設置，驅動(dòng)程序分別由Windows CE和硬件廠(chǎng)商提供； 4）. 完成特定功能的應用程序。 WinCE的制定是在Platform Builder下完成的，在此過(guò)程中需要選擇特定的開(kāi)發(fā)板支持包BSP和相應的應用程序和服務(wù)組件，在選擇過(guò)程中為了節約硬件資源，使內核在能到達要求的前提下盡可能的小，需要盡量精簡(jiǎn)應用程序和組件。 自己編寫(xiě)應用程序后，為了使應用程序也能成為鏡像系統的一部分，可以在Platform Builder下創(chuàng )建自己的CEC文件，使其成為新的特性并添加到需制定的系統特性目錄中去。 制定完成的系統經(jīng)過(guò)編譯后即可生成系統內核鏡像，同時(shí)還能生成一個(gè)Eboot文件。首先通過(guò)JTAG下載Eboot文件，再通過(guò)以太網(wǎng)下載系統鏡像文件，在這基礎上便可以完成對系統同的調試和固化。 四、應用程序 應程序主要是繪制人機交互界面，實(shí)現串口通信功能，并具有聲音的采集、編碼和播放功能。 應用程序是在Embedded Visual C++的環(huán)境下編輯的。Win CE同桌面Windows系統一樣也是一個(gè)圖形界面的操作系統他可以幫助我們設計出豐富的圖形界面，Win CE提供了功能強大的圖形設備接口（GDI)，利用GDI函數可以方便地繪制出點(diǎn)、線(xiàn)、矩形、多邊形、橢圓、位圖、以及文本等，同時(shí)和Visual C++一樣embedded Visual C++也提供了許多常用的控件，所以繪制人機交互界面的工作相對簡(jiǎn)單。 1 Windows CE的串行口通信程序 在Visual C++中實(shí)現串口通信可以簡(jiǎn)單地使用MSCOMM控件，但是在Embedded Visual C++中沒(méi)有此控件，所以串口的實(shí)現相對復雜。但是Win CE提供了豐富的API函數庫，在EVC的編輯環(huán)境中可以使用API函數來(lái)實(shí)現嵌入式系統控制器和無(wú)線(xiàn)數傳模塊的通信。具體過(guò)程是首先對串口進(jìn)行初始化，其中包括使用CreateFile函數打開(kāi)存在且沒(méi)有被占用的串口資源，設置設備的屬性例如波特率，數據位數，校驗方式等。然后設置串口的讀寫(xiě)時(shí)間，指定端口監測的事件集。在串口的讀寫(xiě)過(guò)程中，因為寫(xiě)是可以控制的，而讀的時(shí)候無(wú)法確定數據什么時(shí)候能收到，所以可以在程序的主線(xiàn)程中寫(xiě)數據，同時(shí)創(chuàng )建一個(gè)輔助線(xiàn)程專(zhuān)門(mén)用來(lái)讀數據，當有數據需要發(fā)送時(shí)，使用WriteFile函數向已打開(kāi)的串口寫(xiě)需要發(fā)送數據。而在輔助線(xiàn)程中，用WaitCommEvent來(lái)檢測線(xiàn)路狀態(tài)，當檢測到收到一個(gè)字符的事件發(fā)生時(shí)調用ReadFile函數對串口進(jìn)行讀操作。讀取數據后，為了觸發(fā)事件響應以完成數據處理，可以在輔助線(xiàn)程中使用PostMessageBox函數向應用程序主窗體類(lèi)郵遞一個(gè)自定義消息，這樣就可以在主線(xiàn)程中完成消息響應過(guò)程。 值得注意的是Win CE操作系統是一種UNICODE環(huán)境它只支持UNICODE的應用程序和控件，這也是為什么同樣是32位機，具有基本類(lèi)似的API函數，很多在Windows下能運行的控件或類(lèi)在WINCE環(huán)境中無(wú)法正常工作的原因。所以在進(jìn)行串口數據發(fā)送的時(shí)候需要把數據由UNICODE字符串轉換為ANSI字符串，可以使用API函數，WideCharToMulitByte進(jìn)行轉換。 另外WINCE操作系統中不支持重疊I/O模式，所以在打開(kāi)串口的時(shí)候需要選擇以非重疊I/O方式打開(kāi)，但是在同步方式下如果有一個(gè)通訊API在操作，另一個(gè)會(huì )被阻塞，直到上一個(gè)操作完成，所以當讀數據的線(xiàn)程停留在WaitCommEvent的時(shí)候，WritFile就無(wú)法繼續執行。為了解決此問(wèn)題需要在調用WritFile函數之前使用TerminateThread函數先終止寫(xiě)線(xiàn)程，在發(fā)送完數據后再次創(chuàng )建同樣的寫(xiě)線(xiàn)程用來(lái)等待數據接收事件。因為無(wú)線(xiàn)數傳模塊就是被設計成使用半雙工方式進(jìn)行數據傳輸的，所以使用非重疊方式是合理的。 系統進(jìn)行警報發(fā)放時(shí)，由控制中心向終端發(fā)送數據包，數據包被定義為如下格式： 終端接收到數據頭后，判斷設備地址是否為本機地址，如果是則讀取命令，根據命令字，發(fā)送不同的警報，如果地址不是本機地址則丟棄數據包。 2 Windows CE中聲音播放程序的實(shí)現 系統的在檢測時(shí)需要系統在終端進(jìn)行聲音播放和錄入，再通過(guò)無(wú)線(xiàn)網(wǎng)絡(luò )把錄入的聲音文件傳送到控制中心。在應用程序中，聲音的錄入和播放使用波形音頻編程接口來(lái)實(shí)現，通過(guò)這個(gè)接口可以對音頻以脈沖編碼調制(pulse code modulation，PCM)的方式進(jìn)行壓縮編碼，并能使應用程序精確地控制波形音頻的輸入輸出設備。 聲音的錄制過(guò)程如下： 1）. 使用waveInOpen函數打開(kāi)一個(gè)音頻輸入設備； 2）. 使用WAVEHDR結構體分配錄制聲音時(shí)所需的內存，然后調用waveInPrepareHeader函數準備一個(gè)音頻輸入的數據頭； 3）. 錄音結束時(shí)使用waveIn UnprepareHeader函數釋放音頻輸入緩存區，并調用waveInClose函數關(guān)閉音頻設備。 音頻的播放過(guò)程如下： 1）. 使用waveOutOpen函數打開(kāi)一個(gè)音頻輸出設備； 2）. 使用WAVEHDR結構體分配錄制聲音時(shí)所需的內存，然后調用waveOutPrepareHeader函數準備一個(gè)音頻輸出的數據頭； 3）. 使用waveOutWrite函數發(fā)送數據塊到音頻輸出設備； 4）. 錄音結束時(shí)使用waveIn UnprepareHeader函數釋放音頻輸入緩存區，并調用waveInClose函數關(guān)閉音頻設備。 相對來(lái)說(shuō)音頻地錄入比輸出更為復雜一些。將模擬的（連續的)聲音波形數字元化（離散化)的過(guò)程，主要包括采樣和量化兩個(gè)方面。數字音頻的質(zhì)量也主要取決于：采樣頻率和量化位數這兩個(gè)重要參數。此外，聲道的數目、相應的音頻設備也是影響音頻質(zhì)量的原因。在PCM語(yǔ)音壓縮編碼中： 數據量=(采樣頻率×量化位數)/8(字節數) ×聲道數目 應用程序錄制的Wave文件中也同樣有幾個(gè)重要的參數來(lái)定義聲音數據格式，它們是：采樣方式、采樣位數、采樣頻率和聲道數。一般采樣頻率有8kHz、11kHz、22kHz和44kHz，采樣頻率越高，聲音的保真性就越好，但同時(shí)也就使音頻數據的存儲量增大了。在本設計中采集聲音只是為了檢測設備的運行情況，所以對聲音的質(zhì)量要求不是很高，同時(shí)為了減輕網(wǎng)絡(luò )負擔，提高檢測速度，設定數據格式為8kHz采樣頻率、8位量化、單聲道。通過(guò)實(shí)驗發(fā)現，采樣得到音質(zhì)有所下降，但是可以十分清晰地分辨警報類(lèi)型的。假設我們測試設備的時(shí)間為三秒鐘，那么數據量為8000×8÷8×1×3=24KB，在串行口波特率為76800bps時(shí)，加上數據包的包頭、包長(cháng)，大約在3~4秒的時(shí)間能完成一個(gè)終端設備的檢測。 五、結語(yǔ) 本設計完成了對遙控遙測警報系統中心控制器的硬件結構的設計，并在嵌入式硬件平臺的基礎上，開(kāi)發(fā)了控制中心和終端的應用程序。新的系統更好的滿(mǎn)足了用戶(hù)的，同時(shí)控制器體積變小了，可靠性增加了。不過(guò)，由于系統中無(wú)線(xiàn)通信模塊無(wú)法達到太高的波特率，導致系統檢測時(shí)間比較長(cháng)，在這一點(diǎn)有待進(jìn)一步改進(jìn)。 |
