当年入门的时候，一穷二白。就用google找到了一个叫Kvaser的官网，有位大叔用幽默拟人的语言把CAN协议交代了一遍，当时想点10个赞。
https://www.kvaser.com/about-can/the-can-protocol/
然后开始看CAN 2.0规范，ISO 15765，ISO 14229.
还有一个叫canbushack的网站上面讲一些跟诊断相关的东东，也不错。
也可以去Freescale, Renesas的官网上去看CAN Controller的资料，可以搜两个常用的Transceiver看看，如TJA1042，TJA1055
最后，当然不要忘记CAN BUS界的大牛Vector，他家官网上也有不少资料。如果你们公司有买他们的软件包，最好仔细阅读源代码和相关文档，里面干货很多。学会用CANoe, 用它做测试和仿真都老好用了。
网络管理的部分现在开始流行AutoSAR了，以前用OSEK，这个都可以在网上找到免费的资料。
个人感觉CAN的协议栈是最重要的，可以自己从CAN driver, IL, NM，TP, Diagnostics依次写一遍，然后再跟Vector的包做比较，你就知道为虾米人家一个包可以卖到1Million了。
除此之外，CAN也经常用来做FBL刷写用的总线，当然也有用LIN和USB，还有用串口的，不过偶没见过。做标定也会用基于CAN的CCP或者XCP协议来实现。
分享一个课本上学不到的东东吧~
某日，EMC工程师M跑过来对我说，“w工，我在做pulse 1 实验的时候，ECU掉电后，CAN通信就断掉了。你帮忙看看吧。”
额，神马是pulse 1实验呢，如下图
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
呵呵，看着是不是有一点点茫然呢，我也看不懂这里的各种参数。放在这里，只是要装一下Cool而已。
透过现象看本质，其实就是一个掉电再上电的实验。
EMC工程师大多对CANoe/CANalyzer的配置不是特别了解，所以他们报的问题基本上锁定在两大类：一个是上位机的配置；另一个是CAN的物理连接。
去实验室，首先要弄清楚问题要如何才能复现出来，这个是解决问题的前提。在工作中，偶尔会遇到一些很难复现的bug，我有个同事就曾经花了1个月去复现一个bug。也有的时候，会遇到其他成员误报bug，这个时候，你才理解“去伪存真”是多么的重要。跑题了，让我们回来看我现在的这个问题（目前它还不能被称为一个bug）。
这个问题的现象是：用CANalyzer作为上位机和ECU进行通信，然后用某软件开始控制Battery，让其掉电再上电。本来上电后，CAN通信应该正常才对，但是CANalyzer那边却一直发错误帧。
关掉CANalyzer然后重启，还是不能建立正常的通信；但是，拔掉插在CANcase上的CAN cable后再插上cable，就可以正常通信了。
看到这里，你有什么想法木有呢？
我脑海里冒出的第一个想法是，是不是CANalyzer bus off了，所以没办法发送消息了。
但是马上又被我否定了，因为重启CANalyzer也没办法通信。
因为要拔掉CAN Cable，这个跟硬件连接是有点关系的。那就看看Network Hardware Configuration里面有没有配正确。
Baud Rate是100K，这个也木有问题。
如果是刚接触低速CAN的同学，到这里应该就不知道该如何是好了。我在上个月做Bus Failure测试的时候也遇到过一个类似的问题。我用了整整一下午来测低速CAN的Fault Tolerance特性，测出来的结果居然与Transceiver的datasheet上的描述不一致。想破头之后，咨询了大牛D工，于是这个教训很彻底地刻在了我的脑海中。
下图就是TJA1055 Bus Failure时要保持通信正常的一些Test Case.
2）必须选择匹配的CANPiggy（也就是Transceiver），因为我们的ECU是低速CAN，所以CANcase也要选择低速CAN的通道。
上面橙色框框里面显示baud rate是100K，这里的baud rate是可以手动配置的。
但是红色框框里面表示这个CANpiggy是一个高速CAN的Transceiver，所以在干扰比较多的环境下，把高速CAN Transceier用到低速CAN的系统里，是会有问题的。至于更深层的，为什么这样用会有问题，就需要看电气参数啦，这个我也不懂，希望有高手可以来解答。
BTW，如果只是在纯软件开发的时候用来做通信，这样配置是可以的。
关于是否要接地，如果不需要做Bus Failure那样的测试，就可以不用接地啦。
联系客服
