【摘译+整理】System.IO.Ports.SerialPort使用注意

远古的一篇博客,内容散落于博文和评论 https://sparxeng.com/blog/software/must-use-net-system-io-ports-serialport

C# 和 .NET Framework 提供了一种快速的应用程序开发,非常适合需要随着硬件设计的发展跟踪不断变化的需求的早期开发。在大多数方面都很理想。但.NET 附带的 System.IO.Ports.SerialPort 类是一个明显的例外。委婉地说,它是由计算机科学家设计的,远远超出了他们的核心能力领域。他们既不了解串行通信的特征,也不了解常见的用例。在发布之前,它也不可能在任何真实场景中进行测试,而不会发现漏洞,这些缺陷会使 System.IO.Ports.SerialPort (以下简称IOPSP)的可靠通信成为真正的噩梦。(StackOverflow 上的大量证据证明了这一点)。

更令人惊讶的是,当底层kernel32.dll API 非常好时,还会发生这种级别的问题(我在使用 .NET 之前使用过 WinAPI)。.NET 工程师不仅没有设计出合理的接口,还选择无视非常成熟的 WinAPI 设计,也没有从二十年的内核团队串行移植经验中吸取教训。

下面列出其可靠和不可靠的成员列表:

  • event DataReceived (100%冗余,也完全不可靠)
  • BytesToRead 属性 (完全不可靠)
  • ReadReadExistingReadLine 函数(处理错误完全错误,并且是同步的)
  • PinChanged event (顺序完全不能保证)

可以安全使用的列表:

  • 属性: BaudRate 、 DataBits 、 Parity 、 StopBits ,但仅在打开端口之前。并且仅适用于标准波特率。
  • Handshake属性
  • 构造函数、 PortName属性、 Open函数 IsOpen函数、 GetPortNames函数

还有一个没人使用的成员,因为 MSDN 没有给出任何示例,但对你绝对是必不可少的

  • BaseStream

唯一正常工作的串行端口读取方法是通过 BaseStream 访问。

以下示例是接收数据的错误方式:

port.DataReceived += port_DataReceived;

// (later, in DataReceived event)
try {
    byte[] buffer = new byte[port.BytesToRead];
    port.Read(buffer, 0, buffer.Length);
    raiseAppSerialDataEvent(buffer);
}
catch (IOException exc) {
    handleAppSerialError(exc);
}

下面是正确的方法,它与基础 Win32 API 的使用方式相匹配:

byte[] buffer = new byte[blockLimit];
Action kickoffRead = null;
kickoffRead = delegate {
    port.BaseStream.BeginRead(buffer, 0, buffer.Length, delegate (IAsyncResult ar) {
        try {
            int actualLength = port.BaseStream.EndRead(ar);
            byte[] received = new byte[actualLength];
            Buffer.BlockCopy(buffer, 0, received, 0, actualLength);
            raiseAppSerialDataEvent(received);
        }
        catch (IOException exc) {
            handleAppSerialError(exc);
        }
        kickoffRead();
    }, null);
};
kickoffRead();

从 .NET 4.5 开始,可以改为调用 ReadAsync BaseStream 对象,该对象在内部调用 BeginRead 和 EndRead 。

或者就直接调用 Win32 API的方式。

第一个例子的问题在于:

第一个也是最严重的是 DataReceived 在线程池线程上触发,并且可以再次触发,而无需等待上一个事件处理程序返回。因此,它会导致你进入竞争条件,当你去读取缓冲区时,比 BytesToRead 承诺的要少,因为事件处理程序的另一个实例同时读取它们。应用程序程序员可以通过显式同步来克服这个问题。

但同步不会解决实现本身中存在的竞争条件。BytesToRead 调用 ClearCommError 以获取缓冲区级别,并丢弃其他所有内容。但是 ClearCommError 是对串口寄存器错误标志位的原子交换——你只会看到一次,然后就会清除他们。框架中正在查看这些标志的其他代码以触发 PinChangedErrorReceived 事件由于 BytesToRead(查看并清除寄存器) 会忽略它们,因此事件会丢失。事实上,ErrorReceived 事件的 MSDN 页面显示“由于操作系统决定是否引发此事件,因此不会报告所有奇偶校验错误。这是一个彻头彻尾的谎言 — 事件丢失发生在 BytesToReadBytesToWrite 的 getter 函数中。

译者注:这段原因写在作者和游客的讨论中,感兴趣的可以看看原文。如果写过STM32就能理解作者的意思(STM32的有些寄存器在读后就会清除,这样就会导致丢失了一些事件)。作者表示如果你对串口通信的要求很高,(高性能/低时延/错误等)你就应该使用Win32 API或者 p/invoke 或 C++/CLI。(作者列了写商业库说也能用,感兴趣的在原文评论区自行找一下)。如果你对串口通信的要求不高,其实DataReceived的方式其实也能用。

posted @ 2024-07-26 08:56  时风拖拉机  阅读(1122)  评论(1编辑  收藏  举报