“通过串口收发短消息”的Q&A汇编

要试(虚拟)串口是否连接正确，很简单，用windows自带的"超级终端"在特定虚拟端口连上，敲个"AT"回车，看有没有反应，正确回答应该是"OK"。

Nokia数据线上跑的是"Nokia语"- Nokia专有协议的数据，不是通用/扩展的AT命令集。LogoManager能听、能说"Nokia语"，所以不需要安装驱动就能工作。Nokia有一个免费的"Nokia PC Connectivity SDK"，可供开发Nokia手机使用。至于LogoManager是不是用的这个开发包，那就不得而知了。

在SmsTest中，发出AT命令，然后接收应答，比如

WriteComm("AT+CMGF=0\r", 10);
ReadComm(ans, 128);

在WriteComm函数后接着就调用ReadComm，是不是太急，这里的ReadComm函数是读返回的这个字符串还是其中的单个字符或不完全的字符串？请问超时控制设多少最合适啊？

关于读串口，程序中是这样设定超时控制的：

COMMTIMEOUTS timeouts = {　// 串口超时控制参数
100,　　　　// 读字符间隔超时时间: 100 ms
1,　　　　　// 读操作时每字符的时间: 1 ms (n个字符总共为n ms)
500,　　　　// 基本的(额外的)读超时时间: 500 ms
1,　　　　　// 写操作时每字符的时间: 1 ms (n个字符总共为n ms)
100};　　　 // 基本的(额外的)写超时时间: 100 ms

ReadComm什么时候返回呢？按此timeout设定，若n=128（ReadComm的第二个参数），则

若无任何数据，等待500+1*128=628毫秒返回。也就是说，若没有连上手机，根本不存在应答，ReadComm会持续阻塞628毫秒，而后返回。

若数据连续传输，且字符间隔也未超过了100毫秒，但时间已经到了628毫秒，返回已读取的字符(串)。接收到的可能是不完全的字符串。

若在628毫秒内，字符间隔超过了100毫秒（第一个字符之前等待的时间不算），返回已读取的字符(串)。接收到的应该是完整的字符串。

在手机正确连接的情况下，主要是最后一条起作用。一段数据是连续传输的，若波特率是9600bps，可以算出字符间隔是0.1毫秒左右，远小于100毫秒，不会读一个字节或部分数据就返回；通常是数据完毕后才可能出现等待100毫秒而返回的情况。举个例子，若在执行ReadComm(ans, 128)后150毫秒收到"OK\r\n"，则还需要额外等100毫秒，也就是说函数将在250毫秒后返回。这里传输4个字节数据的时间被忽略不计了。如果觉得读得太急，可将基本的(额外的)读超时时间调大一些。不过500毫秒内还没有应答，可能是连接故障造成的。

需要特别注意的是"AT+CMGL"指令及其应答。可能是由于需要扫描所有存储区域的缘故，手机在逐条送出短消息后，还需要延迟好几秒的时间才能送出最后的"OK"。当然可以通过设定上面的基本读超时时间和读字符间隔超时时间都很长（比如20秒），并且一次读很长的数据（比如2000），来达到目的。但这样一来，函数阻塞时间太长，若恰好这时要程序退出，你会赫然发现"该程序无响应"。SmsTest中解决办法是：循环读取串口数据，将每次读取的数据拼接起来，最后得到完整的应答。gsmGetResponse()每次可能读取部分数据，将新数据追加到已读数据后，且检测是否见到"OK"或"ERROR"，以判断是否已经读到完整的数据。