winapi - 如何使用 Windows API 将空字符发送到串行端口？

Question

我正在开发一个 Windows 实用程序，它使用标准 COM 端口与一些自定义硬件进行通信。通信协议(protocol)(不受我的控制)要求我传输和接收原始 8 位数据字节。

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

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

其中hFile是对正确打开的COM端口的引用，lpBuffer是我存储在内存中的字节数组。该代码可以完美运行，直到需要将空字符(ASCII 零)发送到设备。一旦检测到空字符，WriteFile 就会停止发送，因为它假定已到达字符串末尾。即使我正确设置了 numberOfBytesToWrite，也会发生这种情况。

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

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

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

Answer 1

我以前做过Windows串行端口编程，并且确信我能够通过串行端口发送空字符(否则各种文件传输协议(protocol)将无法工作)。我可以想到两种可能的解释:

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

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

RapidQ 在调用 Win32 API 函数的过程中可能执行的编码(marshal)处理可能会因要发送的数据中嵌入空字符而出现问题。我对 RapidQ 一无所知，但这是链条中必须考虑的另一个环节。