在串行通信中使用什么类型的帧 [英] What type of framing to use in serial communication

查看:29
本文介绍了在串行通信中使用什么类型的帧的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

In a serial communication link, what is the prefered framing/sync method?

  • 使用 SOF 和转义序列进行构图,就像在 HDLC 中一样?
  • 依赖于使用带有长度信息和 CRC 的标头?

这是一个嵌入式系统,使用 DMA 将数据从 UART 传输到内存.我认为使用 SOF 的取景方法最有吸引力,但也许另一个就足够了?

It's an embedded system using DMA transfers of data from UART to memory. I think the framing method with SOF is most attractive, but maybe the other one is good enough?

有人对这两种方法有优缺点吗?

Does anyone has pros and cons for these two methods?

推荐答案

以下基于 UART 串​​口经验,而非研究.

Following based on UART serial experience, not research.

当包含以下内容时,我发现通信问题较少 - 或者换句话说,同时执行 SOF/EOF 和(长度 - 可能)/校验码.框架:

I have found fewer communication issues when the following are included - or in other words, do both SOF/EOF and (length - maybe)/checkcode. Frame:

  1. SOFrame
  2. (长度可能)
  3. 数据(地址、收件人、发件人、类型、序列号、操作码、字节等)
  4. 校验码
  5. EOFrame

总是,收到的名气"包括:

Invariably, the received "fames" include:

  1. 好的 - 没问题.
  2. 由于发件人未发送完整消息(挂起、断电或最后通电传输)而损坏(接收方应使陈旧的不完整消息超时.)
  3. 由于噪音或传输干扰而损坏.(字节帧错误、奇偶校验、错误数据)
  4. 由于接收器在发送消息的中间启动或由于输入缓冲区溢出而丢失几个字节而导致损坏.
  5. 共享总线冲突.
  6. Break - 这在您的系统中是否合法?

无论您使用什么框架,都要确保它能够可靠地处理这些消息类型,及时验证 #1 并快速识别 2-5 并为下一帧做好准备.

Whatever framing you use, insure it is robust to address these messages types, promptly validate #1 and rapidly identifying 2-5 and becoming ready for the next frame.

SOF 有一个巨大的优势,它很容易重新开始,如果接收器由于之前的垃圾帧等丢失了.

SOF has the huge advantage of it it easy to get started again, if the receiver is lost due to a previous crap frame, etc.

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

Length is good, but IMHO the least useful. It can limit through-put, if the length needs to be at the beginning of a message. Some low latency operations just do not know the length before they are ready to begin transmitting.

CRC 建议大于 2 字节.一个简短的检查代码对我来说并没有足够的改善.我宁愿没有校验码也不愿有一个 1 字节的校验码.如果错误时不时发生只能被校验码捕获,我想要比 2 字节的 99.999% 更好的东西,我喜欢 4 字节的 99.99999997%

CRC Recommend more than 2-byte. A short check-code does not improve things enough for me. I'd rather have no check code than a 1-byte one. If errors occur from time-to-time only be caught by the check-code, I want something better than a 2-byte's 99.999% of the time, I like a 4-byte's 99.99999997%

EOF太有用了!

顺便说一句:如果您的协议是 ASCII(而不是二进制),建议 不要 使用 crlf 作为 EOFrame.也许只在它们不是消息的一部分的情况下使用它们.

BTW: If you protocol is ASCII (instead of binary), recommend to not use cr or lf as EOFrame. Maybe only use them out-of-frame where they are not part of a message.

顺便说一句:如果您的接收器可以自动检测波特率,就可以省去很多配置问题.

BTW2: If your receiver can auto-detect the baud, it saves on a lot of configuration issues.

顺便说一句:发送方可以考虑发送一个无"字节(在 SOF 之前)以确保正确的 SOF 同步.

BTW3: A sender could consider sending a "nothing" byte (before the SOF) to insure proper SOF syncing.

这篇关于在串行通信中使用什么类型的帧的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆