如圖2所示，收發端均需要管理兩組串口。對于接收端而言，當獲取來自CDMA網絡的數據后，MCU從串口1接收EM200的數據包，解包分析后將有效數據通過串口0發送給融合中心。如圖5所示，此時MCU只需處理串口1的接收中斷，串口0可以采取查詢方式發送。

　　在發送端，MCU從串口0接收來自探測站的數據，并將數據按AT指令TCP發送格式打包，經串口1發送給EM200。由于AT指令的操作是交互式的，在MCU發出下一條TCP指令給EM200前，必須確認已收到EM200之前AT指令執行后的應答響應，否則極可能導致發送失敗。由于需接收AT指令執行后的應答響應，串口1既要發送也要接收，再加上串口0的接收中斷，MCU需要同時處理兩組串口中斷，如圖6所示。

　　3.1 發送端面臨的問題

　　發送端面臨的最大問題是如何兼顧兩組串口的接收中斷，即當兩個串口同時接收到數據時，如何保證無丟失地全部接收。

　　雖然LPC2214的兩個16C550標準串口自帶16 BFIFO緩存，卻仍難以同時兼顧兩個串口的接收操作。

　　具體問題為，在兩個串口同時接收到超過其FIFO緩沖容量的連續數據時，MCU只能響應高優先級串口中斷，在低優級串口中斷被暫時屏蔽期間，低優先級中斷的串口會因自身FIFO緩存溢出導致數據丟失。

　　實際使用中，MCU一方面需要接收來自探測站的數據，另一方面還要接收EM200返回的之前AT指令執行后的應答響應。工作中TCP發送指令執行后的應答結果為“CRLF%TCPSEND：1，XCRLF”，其中CR和LF分別表示回車和換行，X代表發送指令中的有效數據個數，可能是1～1 024之間的任意數值，另外在1和X前面還分別有一個空格。應答結果共計18～21 B，超過了串口的16 B FIFO緩存容量，在中斷被屏蔽而得不到及時響應時，無疑會導致FIFO緩存溢出。

　　3.2 解決途徑

　　鑒于探測站發送的數據量和發送周期的不確定性，設計時必須考慮滿負荷的工作狀態，即連接探測站的串口0一直處于接收峰值的狀態。為確保無丟失地接收探測站數據，串口0中斷優先級必須高于串口1。在此前提下，問題可歸結為當串口1中斷被暫時屏蔽得不到及時響應時，如何完整接收超過串口1緩存容量的AT指令應答響應，解決途徑是擴大串口1的FIFO緩存。

　　由于TCP發送指令返回的應答響應在18～21 B之間，所以串口1的接收緩存必須大于等于21 B，需另選大容量緩存的專用串口芯片來替代LPC2214串口1。這里采用具備64 B FIFO緩存的并轉串芯片TL16C752B。值得注意的是雖然TL16C752B符合8080并行總線接口要求，但其寫操作時序與相當部分的MCU不匹配，而絕大多數MCU沒有調整此部分時序的功能，其中就包括此處選用的LPC2214。這就需要外加一片用作時序匹配的CPLD，此處選用了EPM240，該部分電路示意圖如圖7所示。

　　MCU以中斷方式經串口0接收探測站的數據，并將其按AT指令TCP發送命令格式傳至EM200模塊。EM200在完成當前TCP數據包發送處理后，將執行后的結果通過串口1返回給MCU，若MCU正忙于接收來自探測站的數據，則AT指令執行結果被壓入TL16C752B接收緩存，并通過中斷提示MCU此時串口1接收到數據，一旦MCU從串口0接收中斷釋放就立即轉去處理串口1接收中斷，足夠大的緩存保證了EM200響應結果能被完整接收。

　　4 軟件設計

　　4.1 轉發平臺的軟件設計

　　由于EM200僅支持TCP協議中的客戶端模式，而各個TCP客戶端之間是不能直接通信的。因此在收發系統中必須引入中間轉發平臺作為TCP服務器端，通過TCP服務器對收到的客戶端數據進行轉發處理從而間接實現在客戶端間的數據交換。TCP服務器端的軟件編寫較為容易，由于該軟件最終運行在公網的PC上，可以在VB環境下利用WinSock組件來實現。TCP服務器開啟兩組監聽端口分別監聽來自接收端和發送端的鏈接請求，當建立起與發送端和接收端的TCP鏈接后，將發送端鏈接收到的數據從接收端鏈接發送出去，如此完成轉發操作。

　　4.2 收發終端軟件設計

　　針對分布式無源探測網絡較高的實時性要求，若仍采用無限循環的前/后臺軟件架構是不合適的，而引入實時操作系統(RTOS)一方面可以提高整體的響應時間，另一方面可以將復雜的應用分解成多個相對獨立子功能模塊，降低了軟件編寫復雜程度。此處選擇μC/OS-Ⅱ，其較少的硬件資源開銷很適合ARM7這類MCU。