嵌入式系統的遠程調試方法介紹

1 基本方法

　　圖1(a)是傳統的嵌入式調試方法：主機PC通過(guò)串口與從機嵌入式系統相連，接收從嵌入式系統發(fā)來(lái)的調試信息并向嵌入式系統發(fā)送調試指令，主機和從機之間只能有幾米或者幾十米的距離。圖1(b)是現在比較流行的遠程嵌入式調試方法：主機PC和從機嵌入式系統分別通過(guò)以太網(wǎng)連接到網(wǎng)絡(luò )上，主機通過(guò)諸如Telnet之類(lèi)的協(xié)議向嵌入式系統接收調試信息和發(fā)送指令。本文介紹的方法是將這兩者結合起來(lái)，位于遠端的嵌入式系統與其相鄰的PC2通過(guò)串口相連，主機PC1和從機PC2各自通過(guò)以太網(wǎng)連接到網(wǎng)絡(luò )上，主機PC1仍然通過(guò)Telnet協(xié)議(使用Windows自帶的“超級終端”程序)與從機PC2通信，在從機PC2上運行一種我們設計的軟件Telent2com，其將Telnet協(xié)議轉換成串口的數據收發(fā)。為了能夠更好地完成對遠端的嵌入式系統的控制，還使用了Telnet協(xié)議中特殊的控制命令來(lái)通過(guò)串口的額外控制線(xiàn)和一定的硬件電路完成對嵌入式系統，如電源和I/O輸入的控制，如圖1(c)所示。

　　使用這種方法單從嵌入式系統的角度來(lái)說(shuō)，基本上沒(méi)有增加任何額外的電路和成本，仍和第一種方法一樣對外使用串口進(jìn)行通信。雖然增加了一臺額外的PC機，但是對于那些在正常工作中不需要使用網(wǎng)絡(luò )，只在測試和調試時(shí)需要使用網(wǎng)絡(luò )來(lái)完成調試和更新固件的嵌入式系統來(lái)說(shuō)，這臺額外的PC機只能算作是一個(gè)調試工具。

　　此外，由于增加了通過(guò)網(wǎng)絡(luò )完成對嵌入式系統的電源和I/O輸入的控制，相對于第2種方法，即使在調試中嵌入式系統由于某種原因死機了，仍能從遠端通過(guò)控制電源，使系統上電復位;而對系統I/O輸入的控制，則可以更好完成模擬系統與外界的交互模擬。

　　整個(gè)系統的工作由兩部分構成：① Telnet到串口之間通信協(xié)議轉換的PC端程序;② 使用串口控制線(xiàn)控制嵌入式系統電源和I/O輸入的接口電路。

　　2 接口電路的設計

　　接口電路主要是完成將串口RXD和TXD以外的控制線(xiàn)(如RTS、CTS等)對嵌入式系統電源或者I/O輸入進(jìn)行控制。為了防止嵌入式系統可能對PC串口的影響，采用圖2所示的電路。通過(guò)使用光耦來(lái)達到PC串口和嵌入式系統之間的電氣隔離，通過(guò)使用繼電器能夠控制不同電壓的電源和不同電平的信號。

　　3 Telnet到串口轉換的軟件

　　Telnet是一種最基本的網(wǎng)絡(luò )應用層協(xié)議，其通信協(xié)議由RFC0854定義。它是建立于TCP協(xié)議之上的用于傳送數據和控制信息的協(xié)議。在默認情況下，其使用TCP端口23。最初設計它的目的，是為建立一種基于網(wǎng)絡(luò )的串行終端仿真協(xié)議。這也正是為什么可以使用Telnet協(xié)議傳送串口數據的原因。

　　通過(guò)Telnet傳送的數據基本以原來(lái)的格式(如果是0xFF數據，則以?xún)蓚€(gè)0xFF表示)填充到TCP消息的有效數據載荷區。對于控制信息(如轉入二進(jìn)制模式命令，以及我們自定義的控制電源和I/O的命令)則通過(guò)在控制命令前加IAC轉意字符(0xFF)方式混雜在普通數據中傳送。這樣就可以避免像FTP協(xié)議使用額外的端口來(lái)傳送控制信息的必要，降低程序的復雜度。

　　這里所要設計的Telnet到串口協(xié)議的轉換程序(telnet2com)實(shí)際上是一個(gè)Telnet的服務(wù)器。它接受來(lái)自圖1(c)中主機PC1客戶(hù)端的Telnet鏈接請求，然后向PC1客戶(hù)端通過(guò)Telnet協(xié)議發(fā)送其從串口接收到的數據，同時(shí)將接收到的Telnet數據發(fā)送到串口。

　　在Windows操作系統，大部分的服務(wù)器(如IIS)都是以Windows NT服務(wù)組件(service)的形式存在于系統中的，它們在系統啟動(dòng)后就一直運行在后臺，等待事件的觸發(fā)(如某個(gè)TCP端口是否有鏈接請求)。作為服務(wù)組件，其與一般Windows程序的不同之處是：它必然包含名為NtServiceEntry的入口函數，當Windows開(kāi)始運行一個(gè)服務(wù)組件時(shí)，首先運行這個(gè)入口函數，而非通常的main函數。

　　在入口函數中，必須定義一個(gè)dispatchTable的結構，包括服務(wù)名稱(chēng)sServiceName以及服務(wù)的實(shí)際主函數ServiceMain，并通過(guò)StartServiceCtrlDispatcher函數真正完成服務(wù)的注冊和運行。一旦一個(gè)服務(wù)組件啟動(dòng)后，除了不斷監聽(tīng)某端口外，還需要響應服務(wù)管理器(service mananger)的不同請求(如暫停服務(wù))。因此將服務(wù)的實(shí)際功能設計成一個(gè)子進(jìn)程bridgeThread，由服務(wù)的主進(jìn)程調用該子進(jìn)程，而服務(wù)的主進(jìn)程則專(zhuān)門(mén)用來(lái)響應服務(wù)管理器的請求。

　　圖3是子進(jìn)程bridgeThread的流程。首先，使用Winsock對特定端口進(jìn)行監聽(tīng)。然后，通過(guò)消息循環(huán)，當接收到鏈接請求的事件后，將串口初始化。之后，消息循環(huán)就不斷響應來(lái)自Telnet和串口的寫(xiě)請求，將Telnet的數據發(fā)送到串口，直到收到Winsock斷開(kāi)鏈接的請求。

在接收到來(lái)自Telnet客戶(hù)端發(fā)來(lái)的數據后發(fā)送到串口之前，必須掃描接收到數據中是否有IAC轉義字符。如果有，必須將它們去掉，而且對于定義的如控制電源和I/O的命令必須進(jìn)行相關(guān)的操作。反之，從串口接收的數據在發(fā)送到Telnet客戶(hù)端之前，必須在所有的0xFF字符之前多加一個(gè)0xFF。下面是對從Telnet接收的數據進(jìn)行掃描過(guò)程的代碼。

　　這里主要使用了Winsock的API來(lái)完成Telnet部分的數據讀取;串口部分是通過(guò)將串口虛擬成一個(gè)文件，通過(guò)文件讀寫(xiě)的API來(lái)完成的。此外，為了對串口其他控制線(xiàn)的控制，使用了GetCommState( )和SetCommState ( )兩個(gè)Windows API來(lái)完成。

　　在實(shí)驗中，使用這樣一套遠程調試系統，曾與遠在韓國的設計中心進(jìn)行聯(lián)合調試并進(jìn)行嵌入式系統固件程序更新下載，雖然相對于本地下載速度慢了很多，但是仍然比其他方式(如電子郵件+手工下載)更為便捷，結果更為直觀(guān)。

　　4 總 結

　　使用這樣一套軟硬件系統來(lái)完成嵌入式系統的遠程調試，既節省了大量的人力物力，又節約了開(kāi)發(fā)的時(shí)間。此外，如果它和配套的測試軟件結合，可以突破一臺電腦只有一兩個(gè)串口，同時(shí)只能測試一個(gè)嵌入式系統的局限，使一臺主機同時(shí)可以和很多個(gè)嵌入式系統相連，完成自動(dòng)測試和協(xié)同測試。