一種基于嵌入式MODEM 最小系統的設計與應用

彭 鵬 章 波

（湖北交通職業技術學院，湖北武漢 430079）

隨著電子和通信技術的飛速發展，越來越多的工控和檢測設備被應用在現場，但隨之而來的程序升級和數據采集成為限制工控檢測設備大量應用在現場的一個重要因素。基于嵌入式MODEM 的應用有著極為廣闊的前景，與通用Modem 相比，嵌入式Modem 具有體積小、易維護、外圍電路簡單、成本低廉等優點，布線安裝僅僅需要普通電話線，連接簡單，可移動性好。同時，由于公用電話網的覆蓋范圍在空間范圍上的優越性，可以快速構建跨地區、跨區域的數據采集系統。相對于目前市場上的數據采集產品，大多數需要架設專門的工業以太網和現場總線網的情況，基于嵌入式MODEM 的應用無疑有著極大的優勢，并且它同Internet網的結合應用，更將這種優勢推動到了一個新的臺階。

由于篇幅所限，本文主要給出系統的整體設計思想和軟件詳細設計，并給出部分結果。

1 嵌入式MODEM 最小系統總體設計方案

1.1 系統的總體構想

由于嵌入式MODEM 多用于現場數據采集，安裝的現場環境有可能比較惡劣，因此在設計時需要充分考慮到各種干擾。此外采用外接電源的方式會增加系統硬件的體積和成本。

我們都知道，電話線路在掛機狀態下兩線間有－48V 的電壓，電流很小，但在摘機狀態下兩線間的電壓降到了－12V 左右，電流為20mA 左右，而嵌入式MODEM 最小系統大部分時間都處于待機狀態，只需要很小的電流就可以維持整個系統的工作。因此，本系統的工作電源可以考慮直接從PSTN線路上進行饋電，這樣一來就決定了系統的器件選型都必須基于低功耗進行考慮。主控CPU采用的是三菱公司的16位單片機M30620SFP，該單片機外部資源豐富，且功耗極低。

1.2 系統的硬件結構

系統硬件部分采用PSTN 線路饋電方式進行供電，由于很多地方的電話線路還是架空線纜，容易遭受雷擊的影響，因此需要在入口前端增加防雷電路，以增強系統的抗干擾能力。

系統的饋電，以及線路的摘掛機檢測和數據的傳輸都經過PSTN 線路，因此線路接口電路相對來說是本系統的最關鍵部分，也是難點部分。首先需要考慮到線路的饋電能力，還要考慮到極性檢測，振鈴檢測，此外，為了提高數據傳輸的穩定性，需對消側音電路重點進行調試。

為了方便和上位機進行通信，本系統中提供了232串口進行連接。由于232電平的高電平為－3V～－12V，低電平為＋3V～＋12V，不能直接和單片機的串口進行連接，因此需要電平轉換電路。此外，為了實現數據緩沖，需要增加存儲器，為了方便記錄某些數據的采集時間，系統還自帶了實時時鐘。所設計的嵌入式MODEM 最小硬件系統如圖1所示。

圖1 嵌入式MODEM 最小硬件系統

1.3 系統的軟件結構

本系統軟件實現分上呼和下傳兩個方面。上呼就是當下位機采集完數據后，定時將數據發送到處于遠方的主機服務器或由上位機通過命令來控制MODEM 進行數據上傳，這時就需要先呼叫服務器號碼，然后進行MODEM 協議的自動識別也就是握手處理，和服務器側建立連接后，通過相關的網絡協議將數據上傳到服務器。而下呼則是一個相反的過程，此時的下位機處于被叫狀態，主機服務器通過呼叫下位機號碼要求下位機將數據上傳。系統的軟件在此需要首先判斷是處于發起方還是處于應答方（MODEM 應用里的專業用語），然后實現鏈路層的自動握手處理，握手通過后，通過TCP／IP 協議實現數據通信。軟件總體設計框圖如圖2所示。

圖2 軟件總體設計框圖

2 系統軟件詳細設計

2.1 線路狀態處理程序

當嵌入式MODEM 處于閑置狀態時，最主要的就是進行線路狀態處理，此時主要進行上位機的AT 命令解析，并根據相應的命令來進行相關操作，或者收到服務器的呼叫進行振鈴提示后由上位機決定是否進行摘機處理。

圖3為線路狀態處理軟件框圖，ATA 為摘機應答，ATDT 后跟呼叫的號碼為撥號呼叫命令，詳細的命令請參考AT 命令集里的說明，在此不再贅敘。的通常狀態，上電復位后進入該狀態。在該狀態下主要完成下述功能：

圖3 線路狀態處理

檢測是否有主機命令下達；檢測是否有振鈴產生；分析主機命令，進行必要的設置；根據主機的摘機撥號命令進入主叫狀態；或在檢測到振鈴后反饋給主機后在主機命令控制下進入MODEM 協議握手處理。

圖3中，在收到主機摘機撥號的命令進入主叫狀態，在該狀態下主要完成下述功能：按照要求摘機；檢測線路狀態；檢測信號音，如果有忙音，反饋主機；如果撥號音正常，用DTMF撥號；撥號后檢測線路狀態，是否是回鈴音或忙音；如為忙音，通知主機并掛機；如回鈴音則等待線路是否出現反極信號，超時退出該狀態；有反極則進入MODEM 協議握手處理。

2.2 MODEM 握手處理

在嵌入式MODEM 里，采用的是V.32bis的協議，它的速率可以達到14.4KBPS，全雙工工作。由于CMX869對V.32BIS等協議已經進行了自動封裝，對MODEM 握手處理主要是對其相關寄存器進行設置和檢測。握手處理的程序如下：

2.3 TCP／IP協議

對TCP／IP 協議族的實現，采用的是從網上移植的uIP協議，uIP是一個適用于8／16位機上的小型嵌入式TCP／IP協議棧，簡單易用，資源占用少是它的設計特點。它去掉了許多全功能協議棧中不常用的功能，而保留網絡通信所必要的協議機制。其設計重點放在IP、ICMP和TCP協議的實現上，將這三個模塊合為一個有機的整體，而將UDP和ARP協議實現作為可選模塊。

為了節省資源占用，簡化應用接口，uIP在內部實現上作了特殊的處理。①注意各模塊的融合，減少處理函數的個數和調用次數，提高代碼復用率，以減少ROM 占用。②基于單一全局數組的收發數據緩沖區，不支持內存動態分配，由應用負責處理收發的數據。③基于事件驅動的應用程序接口，各并發連接采用輪循處理，僅當網絡事件發生時，由uIP 內核喚起應用程序處理。這樣，uIP用戶只須關注特定應用就可以了。傳統的TCP／IP實現一般要基于多任務處理環境，而大多數8位機系統不具備這個條件。④應用程序主動參與部分協議棧功能的實現（如TCP的重發機制，數據包分段和流量控制），由uIP 內核設置重發事件，應用程序重新生成數據提交發送，免去了大量內部緩存的占用。基于事件驅動的應用接口使得這些實現較為簡單。

（1）uIP的接口技術

uIP可以看作是一個代碼庫為系統提供確定的函數。圖1 展示了uIP，系統底層和應用程序之間的關系。uIP提供三個函數到系統底層，uip＿init（），uip＿input（），和uip＿periodic（）。應用程序必須提供一個回應函數給uIP。當網絡或定時事件發生時，調用回應函數。uIP 提供許多函數和堆棧交互。

圖4 uIP庫

（2）uIP應用接口

uIP使用一個基于編程模塊的事件，模塊是實現應用程序作為一個C 函數被uIP 調用的地方，uIP響應一定的事件。uIP 調用應用在，當接收數據時，當數據成功送達另一方中止連接時，當一個新的連接建立時，或者當數據需要重發時。應用程序也周期性地循環等待新數據。應用程序只提供一個回應函數；它提升了應用程序處理不同的網絡服務的不同的端口和連接的映射。

uIP與其它TCP／IP 棧不同的是，當正在重發工作，它需要應用程序的幫助。其它TCP／IP棧緩存傳輸數據在儲存器里，直到在連接的最后數據確應成功發送。如果數據需要重傳，堆棧在沒有通知應用程序下監視著重傳工作。通過這種方法，當要等待一個確應，數據必須緩存在儲存器里，如果產生一個重發，應用程序可以快速重新生成數據。為了減少儲存器的使用量，uIP 利用的論據是應用程序可以重新生成發送的數據和讓應用程序參加重發。

（3）uIP系統接口

從系統的立場看，uIP 由3 個C 函數uip＿init（），uip＿input（），和ip＿periodic（）。uip＿init（）函數用于初始化uIP 堆棧和在系統啟動期間調用。當網絡設備驅動器讀一個IP包到包緩存時，調用函數uip＿input（）。周期性運行是調用uip＿periodic（），代表的是一秒一次。調用uIP函數是系統的職責。

3 運行結果及分析

為了驗證系統的軟件，需要搭建一個硬件測試環境，采用兩臺PC 機，其中一臺PC 機通過串口和嵌入式MODEM 的串口連接，另一臺PC 機的串口和商用 MODEM （型號為 TM－EC5658V）的串口連接，兩個MODEM 的線路接口都各自接入一條內線電話線路（辦公電話需要加撥4才能撥號外線），軟件測試環境都是基于超級終端下進行，超級終端的通信波特率設置為19200bps，8位數據位，無效驗方式。

首先進行MODEM V.32bis協議下的數據傳輸。在商用MODEM 下發送AT 命令“AT＋MS＝V32B”，將商用MODEM 的通信協議固定為V.32BIS協議后，發送“ATD4，87403039”命令呼叫嵌入式MODEM 的線路號碼，呼叫建立后，嵌入式MODEM 線路上并聯的話機開始振鈴，并且每振鈴一次，嵌入式MODEM 將相應的振鈴信息發送到串口，如圖5所示，此時輸入摘機命令“ATA”進行摘機握手處理，嵌入式MODEM很快就和商用MODEM 握手成功，將相應的測試信息“CONNECT 19200”發送到串口，此時在商用MODEM 的超級終端界面上發送一串數據，嵌入式MODEM 能正確接收。然后采用MODEM的文件傳輸協議進行大文件傳輸，方法和上面一樣，唯一不同的是握手成功后，不是直接發送數據，而是在商用MODEM 的超級終端界面下選擇發送文件，采用Ymodem 協議發送文件進行大數據量傳輸，初步測試時，接收數據時有丟失字節的現象，針對該問題對軟件部分進行了完善，修改主要針對V.32BIS協議，因為在此協議下，線路靈敏度很高，經常會收到誤碼，所以在修改時，軟件部分將線路接收部分的優先級別提高，將數據緩沖區加大；同時將硬件接收電路部分的增益降低。進行幾百K 的文件傳輸時通訊正常。發送“＋＋＋＋＋＋＋＋”命令退出鏈接。

圖5 V.32bis協議下通訊測試

驗證TCP／IP 協議也是在上面的測試環境下進行的。通過接撥武漢熱線號碼，握手通過，軟件通過PPP協議發送用戶名和密碼，成功登錄網絡，測試界面如圖6所示。登錄成功后，顯示嵌入式MODEM 的IP地址為“202.110.140.70”。

圖6 TCP／IP協議測試界面

通過以上各項測試結果，嵌入式MODEM 的軟硬件設計基本上達到了預期設定的目標，該系統適用于遠程監控系統和工業測控系統，現場僅僅只需要有電話線路接入，就可以完成供電和通訊，特別適合于某些無人值守的現場使用，給遠程數據采集帶來了很大的方便。

4 結 語

本文對嵌入式MDOEM 的最小系統的實現進行了全面的介紹，對其相關硬件設計和軟件實現進行了詳細介紹，最終的最小系統的實現基本達到了預期設計，并且在軟硬件聯調過程和實際試驗時，對相關的硬件電路參數進行了改進，使得嵌入式MODEM 的工作性能更加穩定。

硬件調試部分的難點在于提高通信的穩定性，也就是硬件電路中的消側音和增益控制部分，對此部分電路先是在ORCAD 軟件下進行了仿真測試，并結合實際測試情況對其進行了完善，目前在嵌入式MODEM 和另一臺商用MODEM 之間進行MODEM 協議下的文件傳輸，通信正常，沒有出現誤碼現象。

對網絡協議部分軟件的實現，軟件程序的編寫都是基于三菱M16C60的編譯器NC30WA 下進行的，調試過程中也發現了三菱編譯器的一個BUG，就是注釋部分不能用“／＊…..＊／”進行注釋，而只能用“／／…..／／”來進行注釋。

1 陳連刊.嵌入式系統的設計與開發［M］.清華大學出版社，2005

2 謬湘科等.Linux管理與開發指南［M］.人民郵電出版社，1999