如何强制串行端口写入方法在发送数据之前等待线路清除？

Question

以下是我正在尝试执行的操作的一些背景：

1. 打开从移动设备到蓝牙打印机的串行端口。
2. 将 EPL/2 表格发送到蓝牙打印机，以便它了解如何处理即将接收的数据。
3. 收到表格后，将一些数据发送到打印机，这些数据将打印在标签纸上。
4. 根据需要多次重复步骤 3，打印每个标签。

步骤 2 仅在第一次发生，因为表单不需要位于每个标签之前。 我的问题是，当我发送表单时，如果我发送标签数据太快，它将无法打印。 有时我会在标签上打印“蓝牙故障：无线电无法运行”，而不是我发送的数据。

我通过执行以下操作找到了解决该问题的方法：

for (int attempt = 0; attempt < 3; attempt++)
{
    try
    {
        serialPort.Write(labelData);
        break;
    }
    catch (TimeoutException ex)
    {
        // Log info or display info based on ex.Message
        Thread.Sleep(3000);
    }
}

所以基本上，我可以捕获 TimeoutException 并在等待一定时间后重试 write 方法（三秒似乎一直有效，但如果少于三秒，则似乎每次尝试都会抛出异常）。 经过三次尝试后，我只是假设串行端口有问题并让用户知道。

这种方法似乎工作正常，但我确信有更好的方法来处理这个问题。 SerialPort 类中有一些属性我认为我需要使用，但我找不到任何好的文档或如何使用它们的示例。 我尝试过使用其中的一些属性，但它们似乎都没有达到我想要实现的目标。

以下是我使用过的属性列表：

• CDHolding
• CtsHolding
• DsrHolding
• DtrEnable
• Handshake
• RtsEnable

我确信这些属性的某些组合将能够更优雅地处理我想要做的事情。

我正在使用 C#（2.0 框架）、Zebra QL 220+ 蓝牙打印机和 Windows Mobile 6 手持设备（如果这对解决方案有任何影响的话）。

任何建议，将不胜感激。

[更新]

我还应该注意到，移动设备使用蓝牙 2.0，而打印机仅使用 1.1 版本。 我假设速度差异是导致打印机接收数据滞后的原因。

Answer 1

嗯，我已经根据已经给出的两个建议找到了一种方法来做到这一点。 我需要使用以下内容设置串行端口对象：

serialPort.Handshake = Handshake.RequestToSendXOnXOff;
serialPort.WriteTimeout = 10000; // Could use a lower value here.

然后我只需要执行写入调用：

serialPort.Write(labelData);

由于 Zebra 打印机支持软件流控制，因此当缓冲区接近满时，它将向移动设备发送 XOff 值。 这会导致移动设备等待从打印机发送 XOn 值，从而有效地通知移动设备它可以继续传输。

通过设置写入超时属性，我给出了抛出写入超时异常之前允许传输的总时间。 您仍然希望捕获写入超时，就像我在问题中的示例代码中所做的那样。 然而，没有必要循环 3 次（或任意数量），每次都尝试写入，因为软件流控制将启动和停止串行端口写入传输。

Answer 2

流量控制是此处的正确答案，它可能不存在/实现/适用于您的蓝牙连接。

查看 Zebra 规范，看看它们是否实现了软件流控制（xon、xoff），或者您是否可以打开软件流控制（xon、xoff），这将允许您查看各个缓冲区何时已满。

此外，蓝牙无线电的最大传输速度不太可能超过 250k。 您可能会考虑人为地将其限制为 9,600bps - 这将为无线电提供大量喘息空间，用于重传、纠错、检测及其自身的流量控制。

如果所有其他方法都失败了，那么您现在使用的黑客方法还不错，但我会致电 Zebra 技术支持并在放弃之前了解他们的建议。

-亚当

Answer 3

问题可能不在于串行端口代码，而在于底层蓝牙堆栈。 您使用的端口是纯虚拟的，并且不太可能实现任何握手（因为这在很大程度上没有意义）。 CTS/RTS DTR/DSR 根本不适用于您正在处理的内容。

根本问题是，当您创建虚拟端口时，它必须绑定到蓝牙堆栈并连接到配对的串行设备。 端口本身不知道这可能需要多长时间，并且它可能被设置为异步执行此操作（尽管这完全取决于设备 OEM 如何完成），以防止调用者在没有条件的情况下长时间锁定配对设备或配对设备超出范围。

虽然您的代码可能感觉像是黑客攻击，但它可能是完成您正在做的事情的最佳、最便携的方式。

您可以使用蓝牙堆栈 API 在连接之前尝试查看设备是否存在并处于活动状态，但堆栈 API 没有标准化，因此 Widcom 和 Microsoft API 在如何执行此操作方面有所不同，并且 Widcom 是专有的，并且昂贵的。 您最终会遇到混乱的情况，试图发现堆栈类型，动态加载适当的验证器类，让它调用堆栈并查找设备。 鉴于此，您的简单民意调查似乎更加干净，并且您不必为 Widcom SDK 花费几美元。