在串行通信中使用什么类型的框架

Question

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

• 使用SOF框架和转发序列，如HDLC？
• 依赖于使用带有长度信息和CRC的标头？

这是一个嵌入式系统，使用从UART到内存的数据DMA传输。 我认为使用SOF的框架方法最具吸引力，但也许另一个方法足够好了？

有没有人对这两种方法有利有弊？

Answer 1

以下基于UART的串行经验，而不是研究。

当包含以下内容时，我发现通信问题较少 - 或者换句话说，同时执行SOF / EOF和（长度 - 可能）/校验码。帧：

1. SOFrame
2. （可能是长度）
3. 数据（地址，往，来，类型，序列＃，操作码，字节等）
4. 注册码
5. EOFrame

收到的“名人”总是包括：

1. 好的 - 没问题。
2. 由于发件人没有发送完整的消息（挂起，断电或rump上电传输）而导致损坏（接收方应将过时的未完成消息超时。）
3. 由于噪音或传输干扰而损坏。 （字节帧错误，奇偶校验，错误数据）
4. 由于接收器在发送消息中间启动或因输入缓冲区溢出而丢失几个字节而导致损坏。
5. 共享总线冲突。
6. 休息 - 这在你的系统中是否合法？

无论您使用什么样的框架，都要确保它能够很好地解决这些消息类型，及时验证＃1并快速识别2-5并为下一帧做好准备。

SOF 具有巨大的优势，它很容易重新开始，如果接收器由于先前的垃圾帧而丢失等等。

长度很好，但恕我直言最不实用。如果长度需要在消息的开头，它可以限制吞吐量。一些低延迟操作在准备好开始传输之前就不知道它的长度。

CRC 推荐超过2个字节。简短的检查代码对我来说不够改进。我宁愿没有检查代码而不是1字节代码。如果错误发生的时间只是被检查码捕获，我想要的东西比2字节的99.999％更好，我喜欢4字节的99.99999997％

EOF 非常有用！

BTW：如果你的协议是ASCII（而不是二进制），建议不使用cr或lf作为EOFrame。也许只有在不属于消息的情况下才能使用它们。

BTW2：如果您的接收器可以自动检测波特率，它可以节省很多配置问题。

BTW3：发送方可以考虑发送“无”字节（在SOF之前）以确保正确的SOF同步。