出于遗留原因，我需要让我的程序能够与可用规范有限的第三方设备通信。这本身并不是真正的问题，我有一些代码可以在它忽略所有串行错误时与它对话。
虽然我希望它不要忽略错误——但问题是从设备接收到的每条消息都会在第一个字节上产生一个帧错误(由于制造商的一些奇怪的设计决定)。
当设备发送响应时，它似乎在线路上断言一个空格 6 位时间，然后是一个标记 2 位时间，然后进入正常帧(1 个空格起始位，8 个数据位，2 个标记停止位)。或者换句话说:传输的第一个字节似乎使用 5 位帧，而每个后续字节都使用 8 位帧；或者第一个字节实际上是一个非常短的中断条件。 (除了这个怪癖，消息格式设计得相当好并且明确。)我假设这是作为某种中断唤醒信号，尽管我不知道为什么它不使用与消息的其余部分，或真正的长于一个字符的中断条件。
毫不奇怪，这会惹恼操作系统，当它看到第一个“字节”时会产生一个帧错误。目前我正在使用基于 Windows 的程序与此设备通信(但稍后可能会迁移到 Linux)。在 Windows 上，我使用重叠 I/O 和 ReadFileEx 来读取实际数据，并使用 ClearCommError 来检测错误情况。不幸的是，这意味着我得到了独立于数据报告的帧错误——然后这被视为正在读取的整个数据 block 的错误(通常一次 8 个字节，但有时更多)而且我似乎真的不能进一步本地化。
(帧错误偶尔也会破坏传入消息中的第二个字节，但幸运的是，这不会在解释这种特定消息格式时造成任何问题。)
我希望能够识别哪些字节具体导致了帧错误，以便端口处理代码可以将其传递给协议(protocol)处理代码，并且它可以忽略发生在重要部分之外的错误信息。但我不想降低性能(如果我尝试逐字节读取，我怀疑会发生这种情况；而且我不确定这是否会起作用)。
有什么好的方法吗？或者我最好忘记整个想法并完全忽略框架错误？
最佳答案
我不是 100% 确定这是一个可靠的解决方案，但到目前为止它似乎对我有用。
我已经这样做了，当它检测到一个帧错误时，下一次读取将只读取一个字节，然后下一个(假设仍然没有帧错误)将尽可能多地返回读取.这似乎清除了错误并毫无问题地接收了以下字节。 (至少当这些字节本身没有任何框架问题时。我不确定如何测试它们发生时的作用。)
关于c++ - 有选择地忽略串行端口上的帧错误，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15627119/