一种软硬结合的嵌入式系统远程调试方法

摘要：介绍一种软硬件相结合来实现嵌入式系统远程调试的方法。其主要思想是，通过使用一个程序将串口和Telnet协议进行转换，主机通过Telnet从远端访问与嵌入式系统用串口直接相连的PC机，从而间接访问到嵌入式系统，获得调试信息、发送指令和更新固件；同时，通过附加的硬件电路，完成远端对嵌入式系统的电源和I/O的控制，从而获得更为全面的调试手段。


关键词：多维力传感器 MSC1210 微位移检测

引 言

　　随着全球化的进程，越来越多的嵌入式系统的设计工作可能由地处两个相距很远地方甚至两个国家的设计团队共同完成，或者设计在一个地方完成，制造在另外一个地方完成。于是，就有了这样一种情况，一个地方的工程师需要对处在另一个遥远地方的嵌入式系统进行程序调试和程序更新。当然,首先会想到的是可以在设计系统时，就使它支持网络接口，在嵌入式系统上面运行诸如Telnet的服务器端程序，这样，使用某种客户端程序就可以从远程访问到该嵌入式系统。但是，使用这种方法的成本太大，需要为嵌入式系统加上额外的网络通信接口芯片，还要为支持TCP/IP栈增加额外的程序存储器和数据存储器。本文介绍一整套通过硬件和软件来完成对嵌入式系统的远程调试方法。
　　
　　　　　　　　　　　　　　　　　　　　　　　图1

1 基本方法

　　图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

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函数。

void NtServiceEntry(char *sServiceName) {
SERVICE_TABLE_ENTRY dispatchTable[] =
{
{TEXT(sServiceName), (LPSERVICE_MAIN_FUNCTION)ServiceMain},
{NULL, NULL}
};
StartServiceCtrlDispatcher(dispatchTable);
}

　　在入口函数中，必须定义一个dispatchTable的结构，包括服务名称sServiceName以及服务的实际主函数ServiceMain，并通过StartServiceCtrlDispatcher函数真正完成服务的注册和运行。一旦一个服务组件启动后，除了不断监听某端口外，还需要响应服务管理器（service mananger）的不同请求（如暂停服务）。因此将服务的实际功能设计成一个子进程bridgeThread，由服务的主进程调用该子进程，而服务的主进程则专门用来响应服务管理器的请求。
　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　图3

　　图3是子进程bridgeThread的流程。首先，使用Winsock对特定端口进行监听。然后，通过消息循环，当接收到链接请求的事件后，将串口初始化。之后，消息循环就不断响应来自Telnet和串口的写请求，将Telnet的数据发送到串口，直到收到Winsock断开链接的请求。

　　在接收到来自Telnet客户端发来的数据后发送到串口之前，必须扫描接收到数据中是否有IAC转义字符。如果有，必须将它们去掉，而且对于定义的如控制电源和I/O的命令必须进行相关的操作。反之，从串口接收的数据在发送到Telnet客户端之前，必须在所有的0xFF字符之前多加一个0xFF。下面是对从Telnet接收的数据进行扫描过程的代码。

case WSA_READ://Telnet收到数据事件
while((iBytes=ReadSocketData(&(g_lpBridgeCfg->sockClient),sTcpBufferIn,MAXSIZE_TCPBUFFER))!=-1) {//读数据
iPos = 0;
iPosComBuffer = 0;
while (iPos < iBytes) {//扫描数据
if(sTcpBufferIn[iPos]==0xFF) {//如果是IAC
iPos++;
switch(sTcpBufferIn[iPos]) {
case 0xff://是否为正常数据0xFF
sComBufferOut[iPosComBuffer++]=sTcpBufferIn[iPos++];
break;
default:
handleCmd(sTcpBufferIn[iPos++]);
//命令处理
}
}
else {//如果不是
sComBufferOut[iPosComBuffer++]=
sTcpBufferIn[iPos++];//写到Com缓冲
}
}
}
SetEnevnt(g_hEvent[COM_WRITE]);//触发Com写事件
WSAResetEvent(g_hEvent[WSA_READ]);//复位winsock读事件
break;

　　这里主要使用了Winsock的API来完成Telnet部分的数据读取;串口部分是通过将串口虚拟成一个文件，通过文件读写的API来完成的。此外，为了对串口其他控制线的控制，使用了GetCommState()和SetCommState()两个Windows API来完成。

　　在实验中，使用这样一套远程调试系统，曾与远在韩国的设计中心进行联合调试并进行嵌入式系统固件程序更新下载，虽然相对于本地下载速度慢了很多，但是仍然比其他方式（如电子邮件+手工下载）更为便捷，结果更为直观。

4 总结

　　使用这样一套软硬件系统来完成嵌入式系统的远程调试，既节省了大量的人力物力，又节约了开发的时间。此外，如果它和配套的测试软件结合，可以突破一台电脑只有一两个串口，同时只能测试一个嵌入式系统的局限，使一台主机同时可以和很多个嵌入式系统相连，完成自动测试和协同测试。

　　　　　　　　　　　　　　　　 　　　　参考文献
1 王建华,张焕生,侯丽坤.Windows核心编程.北京：机械工业出版社，2000
2 Postel J, Renold J. RFC 854Telnet Protocol Specification. 1983
3 msdn.microsoft.com