原创 国家兴亡匹夫有责，从神九用到CAN总线讲起（9）知和识-2

国家兴亡匹夫有责，从神九用到CAN总线讲起（9）知和识-2

n=(1 2 4 6 17 21 31);

P3=2/107/106;

Pun=0;

for LTx=23:1:79

      if LTx < 30          P1=4*n(LTx-22)/2^LTx;

      else                     P1=15*2^-25

      end

temp=0;

      for m=1:1:15

             if LTx-m<=49

             temp=temp+(54-LTx+m)*2^-m

                 else if LTx-m<=64

                    temp=temp+4*2^-m

                    end

end

      end

      Pun=Pun+temp*P1*P3

end

这样变化后的LTX部分或全部覆盖CRC域时的错帧漏检率是：4.68*10^-8。

由文（7）、（8）及上述数据我们可以得到：

P_un,2.0A=6.89*10^-8+8.1*10^-11+3.32*10^-8=1.02*10^-7

P_un,2.0B=6.89*10^-8+8.1*10^-11+4.68*10^-8=1.15*10^-7

至此，由文（7）~（9）我证明了二件事：1.CAN的错帧漏检率要比Bosch声称的大2000倍；2.还有可能漏检的情况未分析，即可能更坏。

这些未分析的漏检情况有：

1。CAN的帧开始位出错，由第二个显位开始的一段被错接收，引起变形帧，这个变形帧因第二个错，如同文（8）分析的那样，将数据读为CRC，成为短帧（见图2）；或者将原帧的EOF读为数据，变为长帧。对这种情况下的错帧漏检概率我尚未深入研究。

图2 SOF错开始的漏检错帧

2。已经计算的部分还有二个因素被简化了：1）还有10种尾部多项式未在这里提及，因为它们的贡献较小；2）在本文提到的重构可疑数据流的二个位错中间，还存在容许添加多个位错（图3），只要它们不在连续的可能形成填充规则窗口中，就不会形成新的数据移位，这种情况的贡献尚未详细研究。在本例中如果第3个位错发生在Tx13处可以，Tx14处就不行。

图3  U=x⁶+x⁴+x³+1，Ec=U*G=(1110，1111，0101，1010，0000，01)多位错的情形

这表明上述计算的结果还是保守的，还不是最坏的。

2011年推出的CAN FD将填充位也计入CRC，此时就CRC来说不存在收发数据的移位，也就不可能因2位错而漏检。但是，CAN FD为了与CAN 兼容，在数据域长8字节以内时完全用CAN 的规定，即用原来的15位CRC及其不计填充位的CRC计算方法。这种继承就把错帧漏检率大的缺点也继承下来了。

兼容的方案曾使intel和Microsoft在pc上大获其利，电子工程专辑论坛中的"ARM与X86的战争史诗"写得很好（http://forum.eet-cn.com/forum_post_10005_1200241710_0.htm）。我在pc刚开始时根本没兼容的概念，86年买了一台不完全兼容的Sanyo 550 pc，结果是没软件可用成了废物一堆，这才知道兼容的重要。不过当兼容成了接受家族遗传病时就是另一会事了，这时需要的是壮士断腕的决心了。

Bosch 是这样描述CAN FD与 CAN的关系的（CAN FD Specification v1.0 http://www.bosch-semiconductors.de/media/pdf_1/canliteratur/can_fd_spec.pdf p.3 ） ："只要不用到CAN FD的格式，CAN FD和CAN 的具体实现可以相互通信，这使CAN系统可以逐步过渡到CAN FD。在CAN FD的引入阶段，可能只用于特定的工作模式，例如终端编程时的软件下载，此时不支持CAN FD的其它控制器处于待机状态。“

CAN FD implementations that are designed according to this specification and

CAN implementations that are designed according to the BOSCH CAN Specification 2.0 can communicate with each other as long as it is not made use of the CAN FD frame format. This enables CAN systems to migrate gradually into CAN FD systems. In the introductory phase, it is possible to use CAN FD only in specific operation modes, e.g. software-download at end-of-line programming, while other controllers that do not support CAN FD are kept in standby.

于是可以知道，他们期待最终将CAN 系统过渡到CAN FD系统，我们可以设想有二个结果：1。过渡结束就完全用CAN FD的长于8字节数据的格式，以免遇到原有的错帧漏检问题，这时你会需要修改软件，例如不用部分加填充，就像以太帧最小帧长的处理方法；2。为了仍保持短帧的优点，修改CAN FD协议，统一长短帧的CRC计算方法，废弃目前8字节内数据按CAN2.0校验的CRC方法，此时你的软件不用改，但是你的硬件要升级。无论何种方案，你的升级还要分二步走，先走的人会吃亏。

写到这里，我想到我们中国人口中的知识一词，它可分为知和识，如果我不知道CAN FD的细节，我是无法断定它为了与CAN 兼容也继承了CAN 错帧漏检率大的缺点。但是如果我不想一想，就没人告诉你，还有那些可能影响CAN 以及CAN FD 的情况，所以不要只做知道分子。现在国内的书籍往往是以厂家的宣传资料或databook为依据编写的，而厂家往往出于自己的利益，将优点说得很充分，对问题不会提及，或者轻描淡写一笔带过，只有在有竞争的方面才会互揭软肋。现在各生产CAN芯片的厂家在CAN协议上的利益是相同的，所以没有竞争，同病相怜，没法说缺陷，所以作为用户在作重要决定时一定要自己想明白。

对我的博客也是这样，我告诉你的是我的想法，我当然想说服你，但是未必没有疏漏与错误，所以我也希望你能深思，诚恳地欢迎有心得的朋友提出不同的观点，我们就事论事，互相促进。