Stm32 重构USB-CDC流

我在STM32上有一个USB CDC接口，我可以向它发送长度超过一块64字节的消息。这意味着我得到了多个调用

CDC\u Receive\u FS（uint8\u t*Buf，uint32\u t*Len）

，在这里我必须将传入数据复制到另一个缓冲区（例如，ringbuffer）

我的问题是，我如何知道数据是属于一条新消息，还是先前（较大）消息的延续？

---

我能说的是，如果到达的字节少于64字节，我可以假定消息是完整的。但是如果缓冲区中正好有64个字节，如果没有更多的消息，我就必须等待。即使如此，我还要等多久才能不把它们与新的混淆呢？

USB CDC和所有源自RS-232的串行协议都实现了基于流的通信，即可能是无限的字节流

它们不实现基于消息的通信。因此，它们没有消息的概念，也没有消息开始和消息结束的概念

USB的下层是基于消息的。因此，您可能会观察到类似于基于消息的通信的模式。您可能还认为USB CDC是基于消息的，因为STM32cube框架公开了一个USB API，每当低级USB消息到达时，该API将提供更多数据

但是，只有在发送小块数据时中间有停顿，并且USB总线大部分处于空闲状态时，才能观察到这种行为。如果速度增加或USB总线变得更繁忙，它就会崩溃

然后你的电脑将开始合并数据块。通过以尽可能快的速度发送100倍于10字节的数据，可以很容易地测试这一点。前10个字节可能在其自己的数据包中发送。但剩余的数据将合并并作为64字节的数据包发送（最后几个字节除外）

因此，如果您希望在面向流的协议之上有一个面向消息的协议，有两种典型的方法：

• 在消息之间使用分隔符。例如：如果您有人类可读的文本协议，则换行符通常用作分隔符。一旦遇到换行符，您就知道有完整的消息（即换行符）

• 在消息末尾使用长度指示器。这对于二进制协议很有用。前两个字节可以包含以字节为单位的消息长度，编码为16位数字。当信息完整时，这一点就显而易见了

---

还要注意，一个接收到的数据包可以包含多条消息，或者一条消息的结尾和下一条消息的开头。

我知道这一点，我只是希望我可能不必太依赖编码消息的大小。也许我可以增加一些额外的措施，以防长度不正确。无论如何谢谢你！