摘  要： 通過分析傳真通信規程，提出了基于NiosII嵌入式傳真通信的方案，并在QuartusII和NiosII IDE環境下開發設計。FPGA開發板與外圍Modem電路組成的傳真系統，可以實現普通傳真機的傳真通信。測試結果表明，該設計增加了整個傳真系統的靈活性與高效性，實現了軟硬件協同的設計，有效地縮短了開發周期，在傳真通信領域具有較好的應用前景。
關鍵詞： 傳真通信；T.30建議書；Modem；NiosII

　　傳真機作為圖文通信設備得到了廣泛應用。為了進行正常通信，需要在通信過程中進行一些“操作”，或者由機器自動執行某些操作，發送方和接收方要進行“磋商”。接收/發送雙方要經過發出表示信號、命令信號、響應信號和證實信號這一過程，這是一個不斷“操作”和“確認”的漸進過程。這個通信規程就是ITU-T在T.30建議中作的規定，T.30建議書作為傳真機在公用電話交換網上的傳輸規程，對公用電話交換網上傳真業務的發展起到了決定性的作用。
　　目前傳真通信的產品開發主要是基于Conexant等公司的專用傳真芯片，對系統二次開發。本文從替代傳統專用芯片的角度，提出一種新的基于NiosII傳真系統方案，即軟硬件協同開發的流程，分析并設計實現傳真通信。
1 傳真通信規程分析
1.1 傳真過程描述
　　T.30建議規定了通信規程的適用范圍、所用術語的解釋、傳真呼叫描述、傳真用的單音信號方式和二進制信號方式[1]。圖1為傳真階段過程圖。

　　(1)階段A：呼叫建立，連通傳真通信雙方傳輸線，使傳真機接入線路。撥號和應答雙方均可由人工或自動兩種操作完成。
　　(2)階段B：報文前過程，報文傳輸的準備階段，包括性能識別和選擇條件命令及接收條件確認。命令部分包括性能命令、訓練、同步及可選的非標準設備命令、終端識別命令、查詢(發送)命令和回聲抑制器解除。
　　(3)階段C：報文中過程，由信息傳輸過程和報文傳輸組成。信息傳輸過程與報文傳輸同時進行，并控制傳輸信號完整性，如傳輸同步、差錯檢測及糾錯和線路管理。若沒有差錯檢測和糾錯處理，則該階段只傳輸報文數據。
　　(4)階段D：報文后過程，傳真雙方在完成傳輸一頁報文后進行該過程。包含消息結束信號、確認信號、多頁信號和傳真結束過程信號。如果信息傳輸完畢，則直接進入E階段。
　　(5)階段E：呼叫釋放，可以手動或自動進行。在信息傳輸完畢或上述各階段操作異常時，雙方分別進入該階段，將傳真機與線路脫離。
1.2 傳真二進制碼信號結構
　　傳真過程用的二進制信號，以300 b/s的速率傳送，這是三類機二進制代碼過程數據傳輸的標準速率。二進制代碼的傳真控制過程都使用HDLC幀結構。一個HDLC幀結構由先導序列、標志序列、地址字段、控制字段、信息字段、幀校驗序列組成。
　　由于采用的調制解調器為TM-EC5658V Data/Voice/Fax Modem，它完成幀校驗和幀封裝工作，所以數字終端設備DTE與調制解調器通信過程中的HDLC幀結構如圖2所示。

　　(1)地址字段：表示該鏈路上發送或接收該幀的地址。提供多點連接安排中的指定終端的標識。在傳真通信中，由于公用電話交換網中只進行點對點的通信，故限定為單一信號格式。
　　(2)控制字段：該字段8 bit數據，用來提供末幀及非末幀的標志。格式為1100 x000，過程中的非末幀，x=0，末幀，x=1，這樣可以區別末幀和非末幀。末幀是指為期待從對方站發來響應之前所發送的最后一幀。
　　(3)HDLC信息字段：T.30建議書中HDLC信息字段被劃分為傳真控制字段和傳真信息字段兩部分。傳真控制字段由8 bit或16 bit構成，二進制碼表示各種命令或響應信號，可以提供28=256種控制信號。傳真信息字段的作用是進一步說明傳真控制字段的內容，提供各種標識、選擇、控制參數等信息。傳真信息字段是以8 bit為一組的數據信息來說明傳真過程。
　　(4)幀校驗序列，幀校驗序列為16 bit位寬數據，用于檢測傳輸中可能產生的差錯。DTE向Modem發送幀數據時不需要幀校驗序列，Modem完成幀校驗。Modem向DTE傳送幀數據時，附帶有幀校驗數據。
1.3 傳真通信流程分析
　　主叫端主動發出一次傳真呼叫，其既可以發送也可以接收傳真文件。一般情況下，當一方有文件需要發送時，可作為主叫端發送傳真文件。在輪詢狀態下，主叫端檢測被叫端是否有文件需要傳送。當主叫端和被叫端均為全自動操作時，主叫端先將傳真機接入電路，檢測到撥號音后撥號，啟動計時并向線路發送主叫單音信號，在設置本端傳真模式后進入階段B。
　　階段B要完成對通信雙方的標識，包括收發操作的確認、兼容性識別以及傳輸速率的確定。具體過程如下：
　　(1)被叫端將其性能指標(如支持的頁面大小、傳輸速率等)封裝在DIS(Digital Identification Signal)中，通知主叫端發送。
　　(2)主叫端根據被叫端性能指標做兼容性判斷。若本地無文件發送而對方有文件發送，則作為接收機發送DTC(Digital Transmistion Command)信號;若本地有文件發送且對方機器兼容，則發送DCS(Digital Command Signal)通知接收端本次傳真過程所采用的傳輸參數，并發送協商速率下的訓練序列。
　　(3)接收端正確接收到訓練后發送CFR（Confirmation To Receive）信號，否則發送FTT（Failure To Train）信號，發送端更新DCS相應字段并重發降速訓練序列，直至接收到CFR。
　　在收發雙方確定連接所能夠支持的最大速率傳輸速率下傳輸報文。非糾錯模式的報文在階段C一次性全部傳輸完畢，其報文后命令有三種，分別為多頁信號MPS（MultiPage Signal）、傳真過程結束信號EOP（End Of Procedure）和報文結束信號EOM(End Of Message)。正確接收報文后接收端發送MCF(Message Confirmation)信號。發送端收到MCF后，進入E階段，并發送DCN（Disconnect）信號，雙方拆鏈路。
1.4 調制解調器通信原理分析
　　Modem集成標準RS-232接口，通過RS-232接口的TxD和RxD兩條信號線完成DCE(Data Communication Equipment)和DTE(Data Terminal Equipment）的數據交換和控制信號交換。DTE發送AT命令到DCE，即Modem。Modem執行命令后通過RxD返回結果給DTE。圖3是Modem通信的示意圖。Modem每執行一條AT指令，都要返回當前的狀態；傳真過程中向Modem串口發送AT指令和HDLC幀數據。
 由于Modem的性能不同，對應不同的工作模式，Class 1服務類別DCE提供為支持G3傳真操作所需要的服務水平。DTE通過AT指令向Modem傳遞命令和參數。Modem執行AT命令的結果就是修改Modem寄存器的值，即設置Modem操作狀態。通過設置Modem的服務類型后，撥號進入傳真流程。

2 傳真規程設計實現
2.1 傳真系統設計
　　系統開發工具選擇QuartusII和NiosII IDE環境，結合SoPC技術，軟硬件協同設計開發。器件選擇Altera公司的Cyclone系列EPEC20F400C開發板，使用QuartusII中SoPC Builder對硬件系統進行定義，完成硬核開發的集成過程。根據設計需要對CPU進行定制，包括CPU的數據和指令緩存的大小、CPU寄存器數量等[4]。除了NiosII之外,還需要將外圍設備的IP添加進來。本設計就是將在前面提到的各種NiosII自帶的各種IP核(UART控制器、定時器等)添加進來，其余自定義的邏輯器件接口同CPU的連接只需在SoPC Builder中將對應的接口模塊添加進來即可。
　　NiosII核與調制解調器通信是通過UART控制器實現的。原來的UART直接選用Altera公司提供的標準UART組件，通信時通過寄存器單字節收發，每個字節都會有中斷觸發。為了方便軟件編程，Altera提供硬件抽象層HAL(Hardware Abstract Level)系統庫驅動程序，該驅動程序是一個集成到HAL系統中的HAL字符模式設備驅動程序，代替訪問UART寄存器，編程者直接使用HAL的API和ANSI C標準庫函數訪問UART。此時，UART相當于字符設備文件，可以像打開文件、讀寫文件一樣操作UART設備。
　　對UART的操作與對文件的操作一樣。打開UART設備后，向調制解調器發送的AT指令和HDLC幀數據以寫文件的方式寫入UART設備，UART把數據發送至調制解調器的串口，命令執行對應的操作。調制解調器通過串口把結果值和HDLC幀數據返回到UART設備，程序以讀文件的方式從UART設備讀取數據，并判斷執行下一步對應的操作。系統框圖如圖4所示。

2.2 程序流程設計
　　傳真發送過程就是對Modem不斷操作的過程，通過Modem完成數據的收發及信號的握手。DTE向調制解調器發送命令，調制解調器DCE對命令做出響應，完成該命令的操作，并返回命令執行的結果碼。
　　對調制解調器發送的命令是AT指令，命令形式化為“AT+命令值”，例如“AT+FRH=3”，表示命令Modem準備以300 b/s的速率接收數據。根據T.30建議書的要求，發送的TCF信號是連續1.5 s的“0”序列，設計過程中通過反復實驗，用軟件連續發送一定的字節內比特位為0的數據，可達到通信要求。在接收TCF信號時，把接收到的0比特數據存入緩沖區，然后判斷是否滿足在當前通信速率下的連續0比特數據量。在報文傳輸階段，發送的數據為處理后(掃描、二值化、編碼)二進制數據，根據ITU-T T.4標準，傳輸的數據可以采用MH/MR/MMR編碼，并且每行的編碼數據發送時間不能少于20 ms[5]。所以編碼數據傳輸時要對數據量小的一行編碼進行0 bit填充，這部分在軟件設計時實現。報文數據以字節為單位將8 bit數據高低位順序顛倒，再傳送給UART。報文數據傳送完之后需添加發送結束標記<DLE><ETX>，告訴Modem報文數據結束。
　　同樣，接收傳真時，T.30建議書對判斷連續1.5 s的“0”沒有具體要求，這里采用緩沖區數據判斷，把接收的“0”存入緩沖單元，判斷“0”的個數來決定當前的通信速率是否滿足。在接收到報文數據后，需要把結束標記從數據中濾出，存入緩沖區，再傳送給譯碼打印系統或存儲Tiff文件。限于篇幅，僅給出如圖5所示的發送單頁傳真樣張軟件實現流程圖。

3 驗證與調試
　　在NiosII IDE開發環境下完成設計代碼，將Nios硬核和軟件程序下載到FPGA開發板上，在線調試。最后在開發板上運行該程序，實現與遠端普通傳真機的傳真業務通信。所選擇的遠端普通傳真機為光電傳真機OEF319系列傳真機和Pansonnic系列傳真機。測試主要內容為：
　　(1)發送傳真。在PC機上將符合ITU標準的測試樣張Tiff文件中的傳真數據存儲到文件，運行NiosII環境時暫存到緩沖區，執行傳真通信，將傳真數據發送出去。遠端傳真機打印出數據和樣張對比，文字清晰可讀。
　　(2)接收傳真。和遠端傳真機通信，接收對方發來的傳真數據并緩存。由于沒有打印設備，不能有效對比接收數據和樣張。把本次接收的數據緩存，作為發送傳真的測試數據，基本保證了傳真測試。采用這樣的測試策略，接收傳真的功能基本實現。在后面深入研究中，可以將打印設備添加到FPGA開發板的系統中，這樣就完善了傳真系統。
　　經測試對比分析，傳真流程合理，與商用傳真機正常通信。但傳真附加功能和整個傳真系統還有待于進一步完善。 本文深入分析了T.30傳真通信建議書，基于NiosII軟件集成開發環境實現了傳真通信規程，并將軟件下載到Altera公司系列開發板上。通過測試驗證，實現了和普通商用傳真機的傳真通信。基于NiosII軟核的傳真通信規程的實現，為嵌入式傳真機提供了一種新的設計開發策略，為傳真機產品升級和提高性能提供了參考；對打破國外傳真機芯片及產品的壟斷，實現中國傳真機自主知識產權及產業化，都具有重要的現實意義。
參考文獻
[1] ITU-T Recommendation T.30.Procedures for document  facsi-mile transmission in the general switched telephone network[S].2005.
[2] 劉立柱.網絡傳真通信原理與技術[M].北京：國防工業出版社，2006.
[3] 牛小立，劉立柱.GSM網絡傳真通信技術研究[J].無線通信技術，2004(1)：41-43.
[4] 蔡偉綱.NiosII軟件構架解析[M].西安：西安電子科技大學出版社，2007.
[5] ITU-T Recommendation T.4.Standardization of Group 3 facsimile terminals for document transmission [S].2003.