當前位置:首頁 > 嵌入式 > 嵌入式軟件

  系統(tǒng)的選擇論證

  目前,一般警報發(fā)放系統(tǒng)是基于PC機/單片機技術的半雙工的點對多點天線專用遙控網。系統(tǒng)中控制中心由PC/工控機擔任,各執(zhí)行終端以單片機為核心的控制器來執(zhí)行控制功能。

從使用管理和建設角度看,有如下不足:基于PC機/工控機技術的控制中心單位體積大,設備成本較高,且由于承擔的任務相對簡單,故使用效率不高,而基于單片機技術的控制執(zhí)行終端能較好地完成解碼控制功能,但不能滿足警報發(fā)放技術的信息交互化改進和運行管理的需求,例如由單片機完成高質量,高效率的音頻編解碼,錄入和還原來實現(xiàn)信息交互化功能是一個比較棘手的問題。本文設計的目的是鑒于以上需求,采用硬軟件資源豐富且可裁減的數(shù)據(jù)處理能力強大且具備一般單片機控制功能的嵌入式技術,設計一種體積小,成本低,功能強,開發(fā)周期短的嵌入式中心控制器和終端控制器,以對原有警報發(fā)放系統(tǒng)進行改進。

  系統(tǒng)整體介紹

  改進的系統(tǒng)由一個控制中心和多個終端構成??刂浦行暮徒K端之間使用無線數(shù)傳模塊來構成無線數(shù)據(jù)通路。每個終端配置唯一的地址,當發(fā)放警報時,控制中心既可以以群發(fā)的方式發(fā)放警報內容,又可以通過指定終端地址,以點對點的方式向某一指定的終端主機發(fā)放指定的警報內容。

  終端控制器的音頻輸出端口和功放相連。當終端接收到屬于本機的警報指令后,根據(jù)不同的警報內容,調用不同的音頻文件,最后由音頻輸出單元和功放發(fā)放。

  為保證控制器的可靠性,需要定時進行檢測。檢測時主控中心以串行點名的方式對每個終端進行查詢。檢測的內容包括中心和終端的無線數(shù)據(jù)通路和音頻發(fā)放設備的工作情況。為了能正確了解終端設備的工作情況,在終端音頻輸入接口配備麥克風,用于采集發(fā)放的警報聲音,采集的聲音壓縮文件再通過無線網絡返回給主控中心,再在主控中心進行處理,分析終端的整套設備工作正常與否。

  一般來說嵌入式控制器是針對某一特定功能來設計的,它可被認為是一種具有特定功能的專用計算機。在本系統(tǒng)中,控制中心和終端控制器需要實現(xiàn)的主要任務都是數(shù)據(jù)傳輸和音頻的處理,所以在硬件資源選擇上,中心和終端可以使用同一套硬件設備。在系統(tǒng)組網時,只需在中心控制器和終端控制器上安裝不同的應用軟件即可完成系統(tǒng)要求。所以在設計開發(fā)中,一旦實現(xiàn)了控制中心的功能,也就是基本上完成了終端的設計任務。

系統(tǒng)硬件軟件資源的選擇

  系統(tǒng)選擇

  為了能方便的實現(xiàn)音頻的處理功能,加快系統(tǒng)的開發(fā)時間,選擇Windows CE作為控制器的操作系統(tǒng)。雖然Windows CE是一個軟實時的操作系統(tǒng),但是完全可以滿足本系統(tǒng)隊實時性的要求。同時Windows CE具有出色的圖形用戶界面,強大的多媒體功能,良好的通信能力。界面友好的嵌入式平臺工具Platform Builder為Windows CE的制定提供了方便。具有和Visual C++基本相同特性的應用程序開發(fā)工具Embedded Visual C++又為熟悉Windows編程的開發(fā)人員提供了捷徑。所以使用具有功能完備的API函數(shù)庫的Windows CE操作系統(tǒng),能使系統(tǒng)顯示出很大的優(yōu)越性。

  硬件結構

  目前已有多款CPU內核支持WinCE操作系統(tǒng),例如ARM、x86、MIPS、PowerPC、SH等。目前市場上采用MIPS和ARM架構的CPU占據(jù)了主導地位。本系統(tǒng)控制中心的CPU選擇Intel @XScale PXA255微控制處理器它遵從ARM 5V.TE體系構架,運行速度高達400MHz,Intel超流水線技術和獨特的動態(tài)功率管理技術,使它兼有高性能與低功耗的特點。為了達到嵌入Win CE操作系統(tǒng)的要求,系統(tǒng)配置64M SDRAM和32M Flash。系統(tǒng)還配置LCD顯示系統(tǒng)和觸摸屏。音頻控制器采用TI公司的TSC2301 Audio Codec芯片,該芯片支持AC’97標準20位立體聲編/解碼、支持可編程采樣率、輸入輸出增益和數(shù)字音響處理功能,同時集成觸摸屏控制功能。它也是本系統(tǒng)硬件的重要組成部分?;诖谕ㄐ诺臒o線數(shù)傳模塊在實際應用中已經很成熟,在市場上也有多種可供選擇的產品。本文對此不作詳細介紹。以下是系統(tǒng)硬件結構圖。

  Windows CE操作系統(tǒng)和應用程序

  系統(tǒng)的制定

  每一個Windows CE操作系統(tǒng)都是基于固定的硬件平臺來運行的。一個完整的Windows CE操作系統(tǒng)的基本內容包括以下幾個方面:

  1. Bootloader,用于加載Windows CE操作系統(tǒng)的程序;

  2. CPU初始代碼,基于特定的CPU系列;

  3. 驅動程序,包括鍵盤、鼠標、聲卡、COM等等,不同的硬件設備可能有不同的設置,驅動程序分別由Windows CE和硬件廠商提供;

  4. 用戶界面接口;

  5. 完成特定功能的應用程序。

  WinCE的制定是在Platform Builder下完成的,在此過程中需要選擇特定的開發(fā)板支持包BSP和相應的應用程序和服務組件,在選擇過程中為了節(jié)約硬件資源,使內核在能到達要求的前提下盡可能的小,需要盡量精簡應用程序和組件。

  自己編寫應用程序后,為了使應用程序也能成為鏡像系統(tǒng)的一部分,可以在Platform Builder下創(chuàng)建自己的CEC文件,使其成為新的特性并添加到需制定的系統(tǒng)特性目錄中去。

  制定完成的系統(tǒng)經過編譯后即可生成系統(tǒng)內核鏡像,同時還能生成一個Eboot文件。首先通過JTAG下載Eboot文件,再通過以太網下載系統(tǒng)鏡像文件,在這基礎上便可以完成對系統(tǒng)同的調試和固化。

  應用程序

  應程序主要是繪制人機交互界面,實現(xiàn)串口通信功能,并具有聲音的采集、編碼和播放功能。

  應用程序是在Embedded Visual C++的環(huán)境下編輯的。Win CE同桌面Windows系統(tǒng)一樣也是一個圖形界面的操作系統(tǒng)他可以幫助我們設計出豐富的圖形界面,Win CE提供了功能強大的圖形設備接口(GDI),利用GDI函數(shù)可以方便地繪制出點、線、矩形、多邊形、橢圓、位圖、以及文本等,同時和Visual C++一樣embedded Visual C++也提供了許多常用的控件,所以繪制人機交互界面的工作相對簡單。

  Windows CE的串行口通信程序

  在Visual C++中實現(xiàn)串口通信可以簡單地使用MSCOMM控件,但是在Embedded Visual C++中沒有此控件,所以串口的實現(xiàn)相對復雜。但是Win CE提供了豐富的API函數(shù)庫,在EVC的編輯環(huán)境中可以使用API函數(shù)來實現(xiàn)嵌入式系統(tǒng)控制器和無線數(shù)傳模塊的通信。具體過程是首先對串口進行初始化,其中包括使用CreateFile函數(shù)打開存在且沒有被占用的串口資源,設置設備的屬性例如波特率,數(shù)據(jù)位數(shù),校驗方式等。然后設置串口的讀寫時間,指定端口監(jiān)測的事件集。在串口的讀寫過程中,因為寫是可以控制的,而讀的時候無法確定數(shù)據(jù)什么時候能收到,所以可以在程序的主線程中寫數(shù)據(jù),同時創(chuàng)建一個輔助線程專門用來讀數(shù)據(jù),當有數(shù)據(jù)需要發(fā)送時,使用WriteFile函數(shù)向已打開的串口寫需要發(fā)送數(shù)據(jù)。而在輔助線程中,用WaitCommEvent來檢測線路狀態(tài),當檢測到收到一個字符的事件發(fā)生時調用ReadFile函數(shù)對串口進行讀操作。讀取數(shù)據(jù)后,為了觸發(fā)事件響應以完成數(shù)據(jù)處理,可以在輔助線程中使用PostMessageBox函數(shù)向應用程序主窗體類郵遞一個自定義消息,這樣就可以在主線程中完成消息響應過程。

  值得注意的是Win CE操作系統(tǒng)是一種UNICODE環(huán)境它只支持UNICODE的應用程序和控件,這也是為什么同樣是32位機,具有基本類似的API函數(shù),很多在Windows下能運行的控件或類在WINCE環(huán)境中無法正常工作的原因。所以在進行串口數(shù)據(jù)發(fā)送的時候需要把數(shù)據(jù)由UNICODE字符串轉換為ANSI字符串,可以使用API函數(shù),WideCharToMulitByte進行轉換。

  另外WINCE操作系統(tǒng)中不支持重疊I/O模式,所以在打開串口的時候需要選擇以非重疊I/O方式打開,但是在同步方式下如果有一個通訊API在操作,另一個會被阻塞,直到上一個操作完成,所以當讀數(shù)據(jù)的線程停留在WaitCommEvent的時候,WritFile就無法繼續(xù)執(zhí)行。為了解決此問題需要在調用WritFile函數(shù)之前使用TerminateThread函數(shù)先終止寫線程,在發(fā)送完數(shù)據(jù)后再次創(chuàng)建同樣的寫線程用來等待數(shù)據(jù)接收事件。因為無線數(shù)傳模塊就是被設計成使用半雙工方式進行數(shù)據(jù)傳輸?shù)?,所以使用非重疊方式是合理的。

  系統(tǒng)進行警報發(fā)放時,由控制中心向終端發(fā)送數(shù)據(jù)包,數(shù)據(jù)包被定義為如下格式:

  終端接收到數(shù)據(jù)頭后,判斷設備地址是否為本機地址,如果是則讀取命令,根據(jù)命令字,發(fā)送不同的警報,如果地址不是本機地址則丟棄數(shù)據(jù)包。

  Windows CE中聲音播放程序的實現(xiàn)

  系統(tǒng)的在檢測時需要系統(tǒng)在終端進行聲音播放和錄入,再通過無線網絡把錄入的聲音文件傳送到控制中心。在應用程序中,聲音的錄入和播放使用波形音頻編程接口來實現(xiàn),通過這個接口可以對音頻以脈沖編碼調制(pulse code modulation,PCM)的方式進行壓縮編碼,并能使應用程序精確地控制波形音頻的輸入輸出設備。

  聲音的錄制過程如下:

  1. 使用waveInOpen函數(shù)打開一個音頻輸入設備;

  2. 使用WAVEHDR結構體分配錄制聲音時所需的內存,然后調用waveInPrepareHeader函數(shù)準備一個音頻輸入的數(shù)據(jù)頭;

  3. 調用waveInAddBuff函數(shù)為音頻輸入設備準備一個緩存數(shù)據(jù)塊;

  4. 使用waveInStart函數(shù)開始錄制音頻;

  5. 錄音結束時使用waveIn UnprepareHeader函數(shù)釋放音頻輸入緩存區(qū),并調用waveInClose函數(shù)關閉音頻設備。

  音頻的播放過程如下:

  1. 使用waveOutOpen函數(shù)打開一個音頻輸出設備;

  2. 使用WAVEHDR結構體分配錄制聲音時所需的內存,然后調用waveOutPrepareHeader函數(shù)準備一個音頻輸出的數(shù)據(jù)頭;

  3. 使用waveOutWrite函數(shù)發(fā)送數(shù)據(jù)塊到音頻輸出設備;

  4. 錄音結束時使用waveIn UnprepareHeader函數(shù)釋放音頻輸入緩存區(qū),并調用waveInClose函數(shù)關閉音頻設備。

  相對來說音頻地錄入比輸出更為復雜一些。將模擬的(連續(xù)的)聲音波形數(shù)字元化(離散化)的過程,主要包括采樣和量化兩個方面。數(shù)字音頻的質量也主要取決于:采樣頻率和量化位數(shù)這兩個重要參數(shù)。此外,聲道的數(shù)目、相應的音頻設備也是影響音頻質量的原因。在PCM語音壓縮編碼中:

  數(shù)據(jù)量=(采樣頻率×量化位數(shù))/8(字節(jié)數(shù)) ×聲道數(shù)目

  應用程序錄制的Wave文件中也同樣有幾個重要的參數(shù)來定義聲音數(shù)據(jù)格式,它們是:采樣方式、采樣位數(shù)、采樣頻率和聲道數(shù)。一般采樣頻率有8kHz、11kHz、22kHz和44kHz,采樣頻率越高,聲音的保真性就越好,但同時也就使音頻數(shù)據(jù)的存儲量增大了。在本設計中采集聲音只是為了檢測設備的運行情況,所以對聲音的質量要求不是很高,同時為了減輕網絡負擔,提高檢測速度,設定數(shù)據(jù)格式為8kHz采樣頻率、8位量化、單聲道。通過實驗發(fā)現(xiàn),采樣得到音質有所下降,但是可以十分清晰地分辨警報類型的。假設我們測試設備的時間為三秒鐘,那么數(shù)據(jù)量為8000×8÷8×1×3=24KB,在串行口波特率為76800bps時,加上數(shù)據(jù)包的包頭、包長,大約在3~4秒的時間能完成一個終端設備的檢測。

結語

  本設計完成了對遙控遙測警報系統(tǒng)中心控制器的硬件結構的設計,并在嵌入式硬件平臺的基礎上,開發(fā)了控制中心和終端的應用程序。新的系統(tǒng)更好的滿足了用戶的,同時控制器體積變小了,可靠性增加了。不過,由于系統(tǒng)中無線通信模塊無法達到太高的波特率,導致系統(tǒng)檢測時間比較長,在這一點有待進一步改進。
  
  參考文獻:

  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 周毓林 寧楊 陸貴強 付林林.Windows CE. Net 內核制定及應用開發(fā).電子工業(yè)出版社,2005

  4 田東風.Windows CE應用程序設計. 機械工業(yè)出版社.2003年

  5 龔建偉. Visual C++/Turbo C串口通信編程實踐.電子工業(yè)出版社,2004

本站聲明: 本文章由作者或相關機構授權發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點,本站亦不保證或承諾內容真實性等。需要轉載請聯(lián)系該專欄作者,如若文章內容侵犯您的權益,請及時聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或將催生出更大的獨角獸公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉型技術解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術公司SODA.Auto推出其旗艦產品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時1.5...

關鍵字: 汽車 人工智能 智能驅動 BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務能7×24不間斷運行,同時企業(yè)卻面臨越來越多業(yè)務中斷的風險,如企業(yè)系統(tǒng)復雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務連續(xù)性,提升韌性,成...

關鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報道,騰訊和網易近期正在縮減他們對日本游戲市場的投資。

關鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產業(yè)博覽會開幕式在貴陽舉行,華為董事、質量流程IT總裁陶景文發(fā)表了演講。

關鍵字: 華為 12nm EDA 半導體

8月28日消息,在2024中國國際大數(shù)據(jù)產業(yè)博覽會上,華為常務董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權最終是由生態(tài)的繁榮決定的。

關鍵字: 華為 12nm 手機 衛(wèi)星通信

要點: 有效應對環(huán)境變化,經營業(yè)績穩(wěn)中有升 落實提質增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務引領增長 以科技創(chuàng)新為引領,提升企業(yè)核心競爭力 堅持高質量發(fā)展策略,塑強核心競爭優(yōu)勢...

關鍵字: 通信 BSP 電信運營商 數(shù)字經濟

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺與中國電影電視技術學會聯(lián)合牽頭組建的NVI技術創(chuàng)新聯(lián)盟在BIRTV2024超高清全產業(yè)鏈發(fā)展研討會上宣布正式成立。 活動現(xiàn)場 NVI技術創(chuàng)新聯(lián)...

關鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會上,軟通動力信息技術(集團)股份有限公司(以下簡稱"軟通動力")與長三角投資(上海)有限...

關鍵字: BSP 信息技術
關閉
關閉