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