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

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太有用了!

顺便说一句:如果你的协议是ASCII(而不是二进制),建议不要使用cr或lf作为EOFrame.也许只有在不属于消息的情况下才使用它们.

BTW2:如果你的接收器可以自动检测波特率,它可以节省很多配置问题.

BTW3:发送方可以考虑发送"无"字节(在SOF之前)以确保正确的SOF同步.