CAN负载率为什么不能太高？

最近我对CAN负载率比较感兴趣。因为一个项目负载弄的比较大。结果吃了亏。

首先很久很久以前我就认为CANoe那个负载率基本上没啥用。那个canoe的负载很久才显示出一次。对于判断总线质量用处真的不大。canoe是个什么工具。可以说是个专业工具，很难用。大概只有专业人员才有那个时间用。并且一个重大的优势在于二次开发比较强悍。并且很重要的一个作用就是可以向别人证明自己的设备没啥问题，通过canoe抓取的数据一般是很让人信服的，因为每个人都认为canoe是很厉害的。毕竟vector给很多大公司提供通信设备，甚至包括给很牛逼的汽车公司。但是canoe对我来说用处现在看来很有限，因为我已经可以实现抓取数据。另外canoe的发送数据也是很弱。canoe主要还是用于分析。发送和接收是否用了两个控制器，这个我不清楚。

产品的设计还是在于预防。预防了才不会出问题。假设不预防，例如把负载弄的很大，例如我的项目甚至有时候达到接近70%，那么就很难分析。这个出不出问题就靠运气。

看过不少的CAN的文章就是里面搞很多公式 弄的特别玄乎，又是做了什么实验负载率大了 会怎么样。这种实验我觉得意义不大。首先你的试验设备如果用的比如用canoe发送，那么发送的时间间隔很难控制住。所以最好自己写单片机程序来发送。

有些文章说负载大了影响实时性。也不知道什么东西实时性这么高，一般影响个几个ms就不错了。靠仲裁能影响多大。

负载率高了能丢帧么？假设在环境比较好的情况下，很难丢帧，即便负载达到80%也很难丢一帧。

那么负载率高了又啥坏处呢？

我目前认为负载率高了对控制器的接收能力是个比较大的考验。如果用一个CAN控制器又是发送又是接收的，CAN本身就是个半双工，CAN控制器所在设备接收了数据还得处理数据，所以这方面的是要考虑的。

另外如果环境不好，那么要关注的是那些优先级低的CAN帧。很可能是负载大的时候，若环境不咋地，优先级低的CAN帧最容易接收不到。

如果弄个子设备啥数据不发送，只是接收，那么很难接收不到。

一般来讲，即便负载很大，比如70%，想要发送不成功很难（当开启自动发送时）。

另外要注意不同CPU带的CAN控制器的发送接收能力或者自动发送策略可能不一样的。

另外发送要注意别挤在一起。瞬间负载才是最应该注意的。

微软雅黑字体版权不知道CSDN没有注意这事。

想到哪里写到哪，可能感觉比较乱，但是很可能是干货。