serial-communication - 在串行通信中使用什么类型的帧

Question

在串行通信链路中，首选的消息成帧/同步方法是什么？

使用 SOF 和转义序列进行取景，例如在 HDLC 中？

依赖于使用带有长度信息和 CRC 的 header ？

它是一个嵌入式系统，使用 DMA 将数据从 UART 传输到内存。
我认为 SOF 的取景方法最吸引人，但也许另一种就足够了？
有人对这两种方法有优缺点吗？

Answer 1

以下基于UART串行经验，不是研究。
当包含以下内容时，我发现较少的通信问题 - 或者换句话说，同时执行 SOF/EOF 和(长度 - 也许)/校验码。框架:

SOFrame

(长度可能)

数据(地址、收件人、发件人、类型、序列号、操作码、字节等)

校验码

EOFrame

总是，收到的“名声”包括:

好的 - 没有问题。

由于发送方未发送完整消息而损坏(它挂起、掉电或开机后传输)(接收方应超时陈旧的不完整消息。)

由于噪声或传输干扰而损坏。 (字节帧错误、奇偶校验、错误数据)

由于接收器在发送消息的中间启动或由于输入缓冲区溢出而丢失几个字节而损坏。

共享巴士碰撞。

Break - 这在您的系统中是否合法？

无论您使用什么框架，确保它能够可靠地处理这些消息类型，及时验证 #1 并快速识别 2-5 并为下一帧做好准备。
特种部队 它的巨大优势在于它很容易重新开始，如果接收器由于之前的废话帧等而丢失，等等。
长度 很好，但恕我直言，最没用的。如果长度需要在消息的开头，它可以限制吞吐量。一些低延迟操作在准备开始传输之前只是不知道长度。
CRC 推荐2字节以上。一个简短的检查代码对我来说并没有足够的改善。我宁愿没有校验码也不愿有一个 1 字节的校验码。如果不时发生错误只能被校验码捕获，我想要比 2 字节的 99.999% 更好的东西，我喜欢 4 字节的 99.99999997%
EOF 太有用了!
顺便说一句:如果您的协议(protocol)是 ASCII(而不是二进制)，建议不要使用 cr或 lf作为 EOFrame。也许只在它们不是消息的一部分的情况下使用它们。
BTW2:如果您的接收器可以自动检测波特率，它可以节省很多配置问题。
BTW3:发送者可以考虑发送一个“无”字节(在 SOF 之前)以确保正确的 SOF 同步。