串口读取丢字符问题：MTTY示例代码解析与疑问

问题 #

我正在尝试与一款廉价国产Arduino Nano建立通信，该设备每秒发送3个字符，但我仅能接收到最后2个。我找到了微软文档中提及的MTTY示例，希望理解其READSTAT.C文件中的读取逻辑，其中不调用WaitCommEvent直接调用ReadFile的方式让我困惑。我自己编写了使用FILE_FLAG_OVERLAPPED的读取线程代码，发现ReadFile持续返回TRUE，且去掉WaitCommEvent后仍会丢失首字符。我已设置GENERIC_WRITE、GENERIC_READ、OPEN_EXISTING权限，并用SetCommMask配置了EV_RXCHAR标志，想请教：

1. 这种不调用WaitCommEvent直接调用ReadFile的方式是否正确？
2. 为何我的ReadFile会持续返回TRUE？
3. 是否必须调用WaitCommEvent？

回答 #

1. 直接调用ReadFile无需WaitCommEvent是合法的 #

Windows串口通信支持两种主流读取模型：

• 事件驱动模型：依赖WaitCommEvent等待指定串口事件（比如EV_RXCHAR代表有字符到达），触发后再调用ReadFile读取数据
• 直接读取模型：不管是同步还是重叠IO模式，都可以直接循环调用ReadFile，MTTY示例用的就是这种逻辑——它靠串口的超时配置控制等待时长，不需要WaitCommEvent触发就能完成读取。

只要你配置的串口参数（波特率、奇偶校验、数据位等）和Arduino端完全匹配，且正确处理读取返回值与实际读入字节数，这种方式完全可行。

2. ReadFile持续返回TRUE的常见原因 #

你开启了FILE_FLAG_OVERLAPPED重叠IO，ReadFile持续返回TRUE通常是以下情况导致：

• 读取操作同步完成：调用ReadFile时，串口输入缓冲区已经有可用数据，重叠IO操作直接同步完成，返回TRUE。此时可以直接通过lpNumberOfBytesRead参数获取实际读入的字节数（同步完成时该参数有效）。
• 重叠结构体配置错误：如果你的OVERLAPPED结构体的hEvent未正确初始化（比如设为NULL），Windows会用文件句柄的信号状态判断操作完成，可能导致ReadFile误判为操作完成，持续返回TRUE。
• 串口缓冲区有残留数据：程序启动前Arduino已发送字符，或之前的读取操作未清空缓冲区，导致缓冲区始终有数据，每次调用ReadFile都能读到内容，自然持续返回TRUE。

3. 不是必须调用WaitCommEvent #

WaitCommEvent只是事件驱动模型的组成部分，用来实现“有数据再触发读取”的被动逻辑；而直接调用ReadFile属于主动轮询（同步模式）或异步等待（重叠IO模式），两种模型没有强制要求，完全看需求选择：

• 若追求低CPU占用，事件驱动+WaitCommEvent更合适
• 若逻辑简单，直接循环调用ReadFile（配合合理的超时设置）实现成本更低

关于丢失首字符的额外建议 #

你丢失首字符大概率和初始化流程有关：

• 打开串口后，先调用PurgeComm清理输入输出缓冲区，避免残留旧数据干扰
• 确保程序完成串口初始化后，Arduino才开始发送数据：可以在程序初始化完成后给Arduino发一个握手信号，让它启动发送；或者在Arduino代码里加一段短暂延迟，等上位机准备就绪再发送。

内容的提问来源于stack exchange，提问作者l_KarmaKat