从USB串行端口读取时，SerialPort.BaseStream.ReadAsync丢弃或加扰字节

Question

编辑：我已经添加了发送代码和接收到的输出示例。

---

我正在从连接到嵌入式系统的USB“虚拟”串行端口读取数据。我编写了两种接收数据的方法，一种是同步的，一种是异步的。同步的一个起作用，而异步的一个则丢失或加扰一些传入的数据。我不知道为什么第二个失败。

可以使用的方法调用将读取超时设置为零的SerialPort.Read，并请求接收缓冲区中的所有内容。我检查返回值以查看实际读取了多少字节，然后将数据放入循环缓冲区以供其他地方使用。此方法由计时器中断调用，它可以完美地接收串行数据（通常以高于1.6 Mbps的速率而无数据丢失）。但是，轮询计时器对我来说已成为一个问题，我希望在其余代码中异步接收数据。

丢失数据的方法在串行端口BaseStream上等待ReadAsync并循环直到取消。这种方法是可行的，但是它经常使数据包的前导字节不按顺序返回，相当频繁地丢失单个字节（大约每千个数据字节一次），并且偶尔从数据包中丢失数百个连续字节。

这里可能存在两个完全不同的问题，因为更大的数据丢失块的丢失似乎与更高的数据速率和更重的系统活动相关。问题的特定部分可能是由于缓冲区超限所致-可能是由于USB调度程序遇到延迟时USB握手失败-但我在此处显示的示例仅在50时传输了非常少量的数据毫秒间隔，除此测试例程外，系统处于空闲状态。

我观察到ReadAsync经常在一次读取时返回数据包的第一个字节，而在下次读取时返回数据包的其余部分。我相信这是预期的行为，因为MSDN表示如果一段时间内没有可用数据，则ReadAsync将返回其收到的第一个字节。但是，我认为这种行为与我的问题有某种关系，因为当单个字节丢失或顺序混乱时，它总是第一个字节“总是”，其余的数据包则正常到达。

当数据包较小时，通常（但并非总是）从数据包开头的“丢失”字节似乎在其余数据包之后的下一次读取中传送，这对我来说绝对没有意义。对于较大的数据包，仍然偶尔会发生这种情况，但是通常在数据包较大时，第一个字节会丢失。

我进行了广泛搜索，并阅读了有关该主题的所有SO问题。我发现其他人似乎也有类似的问题（例如：SerialPort.BaseStream.ReadAsync缺少第一个字节），但是没有人提供任何可接受的甚至合理的解决方案。

Ben Voigt（http://www.sparxeng.com/blog/software/must-use-net-system-io-ports-serialport）和其他似乎真正了解串行通信的人建议在基流上使用ReadAsync，微软的物联网团队也推荐了这种方法，因此我必须相信这种方法应该可行。

问题1：为什么我的代码在USB Serial BaseStream上使用ReadAsync会丢弃/加扰字节？

问题2：如果无法使ReadAsync可靠地以正确的顺序返回接收到的所有字节，我是否可以在传统的SerialPort周围放置一个异步包装器。读取并等待/循环它，这样就不必从计时器轮询？我读过这是个坏主意，但我也读过SerialPort类在内部是异步的，因此也许可以吗？还是我唯一的选择将它放在工作线程上并让它花所有时间等待？

我的代码如下。我已serialPort1.ReadTimeout = 0;和serialPort1.BaseStream.ReadTimeout = 0;（我已经尝试过其他的持续时间）。我已经启用了RTS和DTR，并且由于这是一个USB_serial端口，因此它应该在内部处理握手，并且当我同步读取时肯定可以这样做-但是从BaseStream读取时可能不是这样吗？

这是第一种方法：

// this method works perfectly when called from a timer.
// SerialPort.ReadTimeout must be set to zero for this to work.
// It handles incoming bytes reliably at rates above 1.6 Mbps.

private void ReadSerialBytes()
{
    if (!serialPort1.IsOpen)
        return;

    if (serialPort1.BytesToRead > 0)
    {
        var receiveBuffer = new byte[serialPort1.ReadBufferSize];

        var numBytesRead = serialPort1.Read(receiveBuffer, 0, serialPort1.ReadBufferSize);
        var bytesReceived = new byte[numBytesRead];
        Array.Copy(receiveBuffer, bytesReceived, numBytesRead);

        // Here is where I audit the received data.
        // the NewSerialData event handler displays the 
        // data received (as hex bytes) and writes it to disk.
        RaiseEventNewSerialData(bytesReceived);

        // serialInBuffer is a "thread-safe" global circular byte buffer 
        // The data in serialInBuffer matches the data audited above.
        serialInBuffer.Enqueue(bytesReceived, 0, numBytesRead);
    }
}

这是第二种方法，已编辑以删除@Lucero指出的尾部递归。现在，我不会用尽内存:)，但是，仍然存在原始的数据丢失问题。

// This method is called once after the serial port is opened,
// and it repeats until cancelled. 
// 
// This code "works" but periodically drops the first byte of a packet, 
// or returns that byte in the wrong order.
// It occasionally drops several hundred bytes in a row.
private async Task ReadSerialBytesAsync(CancellationToken ct)
{
    while((!ct.IsCancellationRequested) && (serialPort1.IsOpen))
    {
        try
        {
            serialPort1.BaseStream.ReadTimeout = 0;
            var bytesToRead = 1024;
            var receiveBuffer = new byte[bytesToRead];
            var numBytesRead = await serialPort1.BaseStream.ReadAsync(receiveBuffer, 0, bytesToRead, ct);

            var bytesReceived = new byte[numBytesRead];
            Array.Copy(receiveBuffer, bytesReceived, numBytesRead);

             // Here is where I audit the received data.
             // the NewSerialData event handler displays the 
             // data received (as hex bytes) and writes it to disk.
             RaiseEventNewSerialData(bytesReceived);

            // serialInBuffer is a "thread-safe" global circular byte buffer 
            // The data in serialInBuffer matches the data audited above.
            serialInBuffer.Enqueue(receiveBuffer, 0, numBytesRead);
        }
        catch (Exception ex)
        {
            MessageBox.Show("Error in ReadSerialBytesAsync: " + ex.ToString());
            throw;
        }
    }
}

这是来自发送系统的C ++代码（带ARM芯片的teensy 3.2）。它发送一个从00到FF的字节序列，每50毫秒重复一次。

 void SendTestData()
 {
    byte asyncTestBuffer[256] = { 0 };
    for (int i = 0; i < 256; i++)
        asyncTestBuffer[i] = i;

    while(true)
    {
    Serial.write(asyncTestBuffer, sizeof(asyncTestBuffer));
    delay(50);
    }
}

传统的同步SerialPort.Read（从计时器调用）完全按预期接收每个块，而不会丢失数据。看起来像这样，一遍又一遍：

=====
32 msec => Received 256 bytes 
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
=====

现在，这里是SerialPort.BaseStream.ReadAsync接收的内容。在另一个版本中，我附加了一个终端数据包序列号，以证明当我看到一个零后跟另一个零时，它们之间实际上并没有一个完整的丢失数据包。数据包序列号都存在，因此前导字节确实确实丢失或乱序发送。

7 msec => Received 255 bytes 
0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
=====
5 msec => Received 1 bytes 
00
=====
55 msec => Received 1 bytes 
00
=====
4 msec => Received 255 bytes 
0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
=====
42 msec => Received 1 bytes 
00
=====
5 msec => Received 255 bytes 
0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
=====
68 msec => Received 1 bytes 
00
=====
7 msec => Received 255 bytes 
0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
=====
31 msec => Received 255 bytes 
0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
=====
9 msec => Received 1 bytes 
00
=====
33 msec => Received 1 bytes 
00
=====
10 msec => Received 255 bytes 
0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
=====
55 msec => Received 255 bytes 
0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
=====
12 msec => Received 1 bytes 
00
=====
12 msec => Received 1 bytes 
00
=====
15 msec => Received 255 bytes 
0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
=====
68 msec => Received 255 bytes 
0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
=====
16 msec => Received 1 bytes 
00
=====
14 msec => Received 256 bytes 
000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F606162636465666768696A6B6C6D6E6F707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C8D8E8F909192939495969798999A9B9C9D9E9FA0A1A2A3A4A5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6B7B8B9BABBBCBDBEBFC0C1C2C3C4C5C6C7C8C9CACBCCCDCECFD0D1D2D3D4D5D6D7D8D9DADBDCDDDEDFE0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF
=====

我花了几周的时间来解决这个问题，这个问题最初表现在所开发产品的怪异行为中。我敢肯定，我一定做错了什么，但我看不到它，在这一点上，我非常渴望任何想法或建议！

Answer 1

在逐步完成 .Net SerialPort 类的反编译源代码（仅安装了 resharper Rclick on SerialPort->Navigate->Decompiled Sources）后，我终于想出了一个答案。

答案 #1：字节乱序问题是由于我的程序之前的错误造成的。我已经取消并重新启动了 readAsync 循环，但是我使用了错误的取消令牌，因此有两个循环副本都在等待来自串行端口的 readAsync。两者都发出中断以返回接收到的数据，但当然这是一个竞争条件，即谁先到达那里。

答案 #2：请注意我使用同步读取方法的方式：我不使用 Received 事件（它不能正常工作）或检查要读取的字节数（这是不可靠的）或类似的东西。我只是将超时设置为零，尝试使用大缓冲区读取，并检查我返回了多少字节。

当以这种方式调用时，同步 SerialPort.Read 首先尝试满足来自内部缓存 [1024] 的接收数据字节的读取请求。如果它仍然没有足够的数据来满足请求，那么它会使用完全相同的缓冲区、（调整后的）偏移量和（调整后的）计数针对底层 BaseStream 发出 ReadAsync 请求。

底线：按照我的使用方式使用时，同步 SerialPort.Read 方法的行为与 SerialPort.ReadAsync 完全相同。我的结论是，在同步方法周围放置一个异步包装器可能没问题，然后等待它。但是，我现在不需要这样做，因为我可以可靠地从基流中读取数据。

更新：我现在使用包含持续等待 SerialPort.Basestream.ReadAsync 并将结果添加到循环缓冲区的循环的任务从我的串行端口可靠地接收超过 3Mbps 的数据。