【问题标题】:Does a stuffing bit in CAN count towards the next stuffing groupCAN 中的填充位是否计入下一个填充组
【发布时间】:2020-03-05 12:26:25
【问题描述】:

如果你在 CAN 数据中有一个位序列:

011111000001

1 之后需要填充 0,0 之后需要填充 1。但我不确定 1 应该去哪里。

该标准对我来说似乎模棱两可,因为有时它会谈论“正常操作期间的 5 个连续位”,但有时它会说“5 个连续的数据位”。填充位算数据吗?

应该是:

01111100000011

或者

01111100000101

【问题讨论】:

  • Wikipedia 通过示例给出了很好的解释。维基百科页面的哪一部分不清楚?
  • @Lundin 这确实是一个很好的例子,并明确说明了我的情况。但是 Wikipedia 不是一个实际的来源,这就是我没有使用它的原因——我可以很容易地把它改成完全相反的说法。这就是为什么我希望找到一个官方标准来确认它(我还没有)。
  • 同样的链接提到了标准的名称,ISO 11898-2。如果您搜索“Bosch CAN 2.0B”,您可以找到一个几乎相同的免费旧草稿版本
  • 也许 11898-2:2016 说得很清楚,但我认为博世标准不足以回答这个问题。它指出“每当发送器在要发送的比特流中检测到五个连续的相同值的比特时,它会自动在实际传输的流中插入一个互补比特。”我个人认为“实际”一词的使用使其模棱两可 - 它表明“要传输的比特流”和“实际传输的比特流”是不同的东西,在这种情况下,可以解释为我的问题中的第一个选项是正确的
  • 是的,它们当然是不同的东西,这就是你引用的比特填充章节的重点。 “比特流”是要传输的数据,“实际比特流”是附加了填充比特的数据。我会发布一个答案。

标签: can-bus


【解决方案1】:

位填充仅适用于 CAN 帧,直到 ACK 位。在 End-Of-Frame 和 Intermission 字段中,不应用位填充。

发送什么并不重要。

它只是“在5个连续的相同值的位之后”插入一个互补位。

你的第二个例子是正确的。连续 6 位使消息无效。

【讨论】:

  • 这似乎与我发现的一般情况一致,我现在可以确认这是第三个非官方来源。因此,除非我另有发现,否则会这样做。
【解决方案2】:

来自旧的 Bosch CAN2.0B 规范,第 5 章:

帧段START OF FRAME、仲裁字段、控制字段、数据字段和CRC SEQUENCE采用比特填充的方法编码。

意味着从帧开始到 15 位 CRC 的所有内容都可以有位填充,但不能有 1 位 CRC 定界符和帧的其余部分。

每当发送器检测到要发送的比特流中的五个连续比特时

这个“比特流”是指前面引用的句子中提到的所有字段。

...在实际传输的比特流中

实际传输的比特流是原始数据+附加的填充比特。

【讨论】:

  • 在严格解释你所说的情况下,我回答的第一个例子是正确的。 “要传输的比特流”部分是:“1111100000”。在 0 中,直到最后才达到“五个连续位”。但是因为1s,情况发生了变化。这是因为“实际传输的比特流”的内容才知道的。所以它实际上应该说“实际传输的比特流中的五个连续比特”。
  • @richjhart 看,这不是火箭科学。如果有 5 个相同值的位,则插入相反极性的填充位。时期。该规范可能假设读者了解 uni 教授的基本数据通信,因为位填充是一个通用概念,并非 CAN 独有。您也拥有它以及其他各种低级协议,例如 HDLC。在那里工作完全一样,也是 5 位。
  • 标准的全部意义在于不假设读者有任何知识。有不同的方法来做位填充,任何一种方法都是合法的。仅仅因为它在其他标准中的工作方式完全相同并不意味着该标准将自动相同。我发现有趣的是,它明确表示位填充不适用于消息的某些部分——对我来说,这也使问题更加合理。你说“一个填充位......被插入。句号”。那么,这个资格不是意味着情况并非总是如此吗?
猜你喜欢
  • 2015-10-31
  • 2020-02-14
  • 2016-05-15
  • 2017-04-07
  • 2019-07-28
  • 1970-01-01
  • 2018-03-08
  • 2019-01-31
  • 2021-05-05
相关资源
最近更新 更多