圖4為系統(tǒng)終端進行語音數(shù)據(jù)流收發(fā)和編解碼的軟件事件池示意圖。在本系統(tǒng)終端的軟件設計中，按鍵掃描模塊、CAN總線收發(fā)模塊、語音編解碼芯片CMX7261與LPC1768進行SPI數(shù)據(jù)通信等各種外部觸發(fā)都采用了中斷方式，減少了處理器的等待時間。在具體的軟件設計上，在CAN總線的收發(fā)控制中設定了兩級緩存，每級緩存都有對應的PUSH和POP兩個變量來實時地作為收發(fā)緩存填充的標志，語音數(shù)據(jù)流在收發(fā)過程中做到了非阻塞，提高了語音數(shù)據(jù)流的傳輸效率和語音編解碼效率。
當發(fā)生某一種特定的條件后，終端處理器并不是立馬去執(zhí)行相應的操作程序，而是產(chǎn)生相應的事件，初始化事件參數(shù)，放入軟件事件池中。語音終端的軟件設計由事件池作為系統(tǒng)軟件的協(xié)調(diào)者，簡化了軟件的開發(fā)流程，使得軟件開發(fā)層次清晰，效率高。
3．2 CAN總線應用層協(xié)議設計
CAN總線的底層硬件工作于OSI的數(shù)據(jù)鏈路層和物理層，CAN總線網(wǎng)絡通信協(xié)議僅解決了數(shù)據(jù)發(fā)送、接收、錯誤處理等底層硬件數(shù)據(jù)傳輸問題，對于應用層數(shù)據(jù)并沒有規(guī)定相應的解析協(xié)議，應用層協(xié)議需要開發(fā)人員自定義，主要應考慮以下三個方面：數(shù)據(jù)幀格式確定、總線資源的分配、發(fā)送接收數(shù)據(jù)幀的分配。
該系統(tǒng)中，CAN應用層協(xié)議需要由開發(fā)人員進行設之間進行安全穩(wěn)定通信的關鍵。所以，CAN總線技術，特別是CAN總線應用層協(xié)議是該系統(tǒng)設計中的一個關鍵點和難點。現(xiàn)在國內(nèi)外存在一些現(xiàn)有的CAN總線應用層協(xié)議標準(CANopen、CANbus)，本系統(tǒng)以這些應用層協(xié)議標準作為參考，結合本系統(tǒng)的功能設計出適用于該系統(tǒng)的CAN總線應用層通信協(xié)議。
本系統(tǒng)在CAN應用層協(xié)議的設計中，對于單個終端節(jié)點而言，在收到CAN總線語音數(shù)據(jù)的條件下(有CAN總線中斷)沒有發(fā)送語音的權利，即接收的優(yōu)先級比發(fā)送的優(yōu)先級高，這樣就很好地避免了一條總線上語音數(shù)據(jù)流的沖突問題。在同一時間，整條CAN總線上最多只能有一對節(jié)點在進行語音數(shù)據(jù)的傳輸。
地面調(diào)度上位機在整個系統(tǒng)中是處于優(yōu)先級最高的地位，當井下終端節(jié)點在進行廣播通話的過程中接收有調(diào)度上位機的語音數(shù)據(jù)后，發(fā)送終端應該及時作出判斷，關閉發(fā)送功能，轉為接收調(diào)度上位機的語音數(shù)據(jù)。
在CAN總線的各個終端之間在進行數(shù)據(jù)發(fā)送接收工作時，調(diào)度上位機的控制信息仍然可以在總線中進行傳輸，不影響終端的語音傳輸?shù)墓δ?。終端節(jié)點在接收到調(diào)度上位機的控制信息后，應在空閑時進行相應的操作和回應。

結語
本文給出了基于G．729A語音編解碼技術的煤礦井下語音傳輸系統(tǒng)構架、終端的軟硬件設計方案和CAN總線應用層協(xié)議設計方案，用事件池的軟件沒計思路實現(xiàn)了G．729A壓縮編碼的語音數(shù)據(jù)流在井下CAN總線的實時安全傳輸，實現(xiàn)了話音和高質(zhì)量語音信號在窄帶寬的CAN總線上實時傳輸?shù)墓δ?。本系統(tǒng)的方案新穎，成本低，實現(xiàn)簡單，對于煤礦井下語音傳輸系統(tǒng)的設計和開發(fā)有很好的借鑒意義。