嵌入式系統的遠程調試
加入技術交流群
1 基本方法
本文引用地址：http://www.j9360.com/article/151545.htm圖1(a)是傳統的嵌入式調試方法：主機PC通過串口與從機嵌入式系統相連，接收從嵌入式系統發來的調試信息并向嵌入式系統發送調試指令，主機和從機之間只能有幾米或者幾十米的距離。圖1(b)是現在比較流行的遠程嵌入式調試方法：主機PC和從機嵌入式系統分別通過以太網連接到網絡上，主機通過諸如Telnet之類的協議向嵌入式系統接收調試信息和發送指令。本文介紹的方法是將這兩者結合起來，位于遠端的嵌入式系統與其相鄰的PC2通過串口相連，主機PC1和從機PC2各自通過以太網連接到網絡上，主機PC1仍然通過Telnet協議(使用Windows自帶的“超級終端”程序)與從機PC2通信，在從機PC2上運行一種我們設計的軟件Telent2com，其將Telnet協議轉換成串口的數據收發。為了能夠更好地完成對遠端的嵌入式系統的控制，還使用了Telnet協議中特殊的控制命令來通過串口的額外控制線和一定的硬件電路完成對嵌入式系統，如電源和I/O輸入的控制，如圖1(c)所示。
使用這種方法單從嵌入式系統的角度來說，基本上沒有增加任何額外的電路和成本，仍和第一種方法一樣對外使用串口進行通信。雖然增加了一臺額外的PC機，但是對于那些在正常工作中不需要使用網絡，只在測試和調試時需要使用網絡來完成調試和更新固件的嵌入式系統來說，這臺額外的PC機只能算作是一個調試工具。
此外，由于增加了通過網絡完成對嵌入式系統的電源和I/O輸入的控制，相對于第2種方法，即使在調試中嵌入式系統由于某種原因死機了，仍能從遠端通過控制電源，使系統上電復位;而對系統I/O輸入的控制，則可以更好完成模擬系統與外界的交互模擬。
整個系統的工作由兩部分構成：① Telnet到串口之間通信協議轉換的PC端程序;② 使用串口控制線控制嵌入式系統電源和I/O輸入的接口電路。
2 接口電路的設計
接口電路主要是完成將串口RXD和TXD以外的控制線(如RTS、CTS等)對嵌入式系統電源或者I/O輸入進行控制。為了防止嵌入式系統可能對PC串口的影響，采用圖2所示的電路。通過使用光耦來達到PC串口和嵌入式系統之間的電氣隔離，通過使用繼電器能夠控制不同電壓的電源和不同電平的信號。
3 Telnet到串口轉換的軟件
Telnet是一種最基本的網絡應用層協議，其通信協議由RFC0854定義。它是建立于TCP協議之上的用于傳送數據和控制信息的協議。在默認情況下，其使用TCP端口23。最初設計它的目的，是為建立一種基于網絡的串行終端仿真協議。這也正是為什么可以使用Telnet協議傳送串口數據的原因。
通過Telnet傳送的數據基本以原來的格式(如果是0xFF數據，則以兩個0xFF表示)填充到TCP消息的有效數據載荷區。對于控制信息(如轉入二進制模式命令，以及我們自定義的控制電源和I/O的命令)則通過在控制命令前加IAC轉意字符(0xFF)方式混雜在普通數據中傳送。這樣就可以避免像FTP協議使用額外的端口來傳送控制信息的必要，降低程序的復雜度。
這里所要設計的Telnet到串口協議的轉換程序(telnet2com)實際上是一個Telnet的服務器。它接受來自圖1(c)中主機PC1客戶端的Telnet鏈接請求，然后向PC1客戶端通過Telnet協議發送其從串口接收到的數據，同時將接收到的Telnet數據發送到串口。
在Windows操作系統，大部分的服務器(如IIS)都是以Windows NT服務組件(service)的形式存在于系統中的，它們在系統啟動后就一直運行在后臺，等待事件的觸發(如某個TCP端口是否有鏈接請求)。作為服務組件，其與一般Windows程序的不同之處是：它必然包含名為NtServiceEntry的入口函數，當Windows開始運行一個服務組件時，首先運行這個入口函數，而非通常的main函數。
在入口函數中，必須定義一個dispatchTable的結構，包括服務名稱sServiceName以及服務的實際主函數ServiceMain，并通過StartServiceCtrlDispatcher函數真正完成服務的注冊和運行。一旦一個服務組件啟動后，除了不斷監聽某端口外，還需要響應服務管理器(service mananger)的不同請求(如暫停服務)。因此將服務的實際功能設計成一個子進程bridgeThread，由服務的主進程調用該子進程，而服務的主進程則專門用來響應服務管理器的請求。
圖3是子進程bridgeThread的流程。首先，使用Winsock對特定端口進行監聽。然后，通過消息循環，當接收到鏈接請求的事件后，將串口初始化。之后，消息循環就不斷響應來自Telnet和串口的寫請求，將Telnet的數據發送到串口，直到收到Winsock斷開鏈接的請求。
評論