2

我正在开发一个 Windows 实用程序，它使用标准 COM 端口与一些自定义硬件进行通信。通信协议（我无法控制）要求我发送和接收原始 8 位数据字节。

我目前正在使用以下 Windows API 函数将数据发送到 COM 端口：

WriteFile(hFile, lpBuffer, numberOfBytesToWrite, ...)

wherehFile是对正确打开的 COM 端口的引用，并且lpBuffer是我存储在内存中的字节数组。在需要将空字符（ASCII 零）发送到设备之前，该代码运行良好。WriteFile一旦检测到空字符就停止发送，因为它假定它已到达字符串的末尾。即使我设置numberOfBytesToWrite正确，也会发生这种情况。

如何使用 Windows API 将原始数据发送到 COM 端口？我更愿意使用类似于 的标准 API 调用WriteFile，但我愿意接受建议。

我目前正在使用RapidQ来构建实用程序，但它所做的只是直接调用 Windows API 函数。

编辑：我的设置包括通过串行端口连接到自定义硬件模块的 Windows PC。该模块有一个小屏幕，我可以在上面查看传输的字符。我已经用另一个第三方实用程序测试了这个设置。我能够使用这个第三方程序与模块通信，并且空字符正确显示。在我自己的程序中，当我使用 时WriteFile，传输流中任何位置的空字符都会停止发送流的其余部分。

4

6 回答 6

3

我之前做过 Windows 串口编程，并且确信我已经能够通过串口发送空字符（如果不这样，各种文件传输协议将无法正常工作）。我能想到两种可能的解释：

  1. 接收设备正在使用在第一个空字符处停止的方法打印它接收到的数据。您如何确定传输设备在第一个空值处终止？问题可能出在更远的地方吗？
  2. 串口驱动坏了。这不太可能，但可能是一种解释。如果您正在使用一些狡猾的专有第三方串行端口及其驱动程序，那么他们可能会受到怀疑。如果您使用标准内置串行端口和普通 Windows 驱动程序，那么这可能不是问题。

我只是快速浏览了一下 RapidQ，还有第三种可能的解释：

  1. RapidQ 在调用 Win32 API 函数的过程中可能进行的封送处理可能会遇到要发送的数据中嵌入空字符的问题。我对 RapidQ 一无所知，但这是链条中另一个必须考虑的环节。
于 2008-12-22T21:20:12.577 回答
2

Win32 中的串行通信

于 2008-12-22T21:18:10.257 回答
1

Greg 可能是正确的，但我也会检查您的 com 端口设置。确保正确设置 DCB 设置。查找 SetCommState 和 GetCommState 以获取信息。

通常，串行是 8N1，但您的设备可能正在使用其他奇偶校验或停止位配置等。

像 Greg 一样，我自己在串行方面做了很多工作，这通常是问题的根源……尝试使用 RS485 和不正确的 DCB 结构进行交谈……呵呵……

拉里

PS：如果你还没有，我建议你给自己买一个好的串行分线盒。我在房子周围的某个地方有一个，它会在你所有的通信过程中显示所有信号是什么，在所有线路上，它是一个非常强大的调试工具。

于 2008-12-22T21:28:18.037 回答
1

我过去曾使用过 WriteFile，它在处理空字节时效果很好。我会深入研究 RapidQ，这可能是问题所在。

于 2008-12-22T21:34:46.370 回答
1

如果这些都没有帮助，你总是可以做我做的。使用 Greg 的 COMM 代码来测试设备。还记得 Qmodem 吗？:) 非常好的测试/调试串行例程的工具。您甚至可以使用 Qmodem 和一个简单的 Qmodem 脚本来读取另一个盒子（或同一盒子中的另一个端口）上的 COM 端口，并打印出每个发送的字符的十六进制值。等一下。Qmodem 有内置的。:) 使用调试 ASCII 仿真，它将显示串行端口上每个字符的十六进制值。然后，您至少可以验证您的代码是否正常工作。

现在，问题。WriteFile 在遇到 NULL 时会返回，还是只是坐等等待，永远不会返回？

如果它永远不会返回，那么它可能不是您的代码。WriteFile 仅在发送所有 dwBytesToWrite 或出现错误时返回。其他任何东西，它正在尝试写入，但另一端出现故障。

于 2008-12-22T21:44:22.870 回答
0

要通过串行发送 NULL 字符，您可以使用 setEndOfFile() 函数，将端口处理程序作为文件。

如果您有太多 NULL 数据要发送，它可能并不理想，但这是一种解决方法。

功能详情

于 2019-05-14T16:01:14.087 回答