CAN总线调度问题

hw531025

一、问题背景：      
      使用一个103作为CAN的主机（主要功能为接收，也有发的需求），5个F103（例如：A\B\C\D\E）作为CAN的从机（多数为发，少数同时需要接收）。目前，主机使用的是轮询的方式对总线上的报文进行读取。通信速率为500K。目前使用的通信方式有点类似I2C，对每个103设为一个ID，比如：A：0x103，B：0x104，......，E：0x107，主机的ID设为0x101。每个103的上发消息的频率一致。


      看过CAN的协议，明白CAN的报文是以ID的优先级进行仲裁。


二、疑问：
      1、主机的过滤器应该如何设置？
       比如在准备接收A的消息的时候，过滤器设为屏蔽其他的消息？针对每一个从机，都进行相应的过滤设置？
      2、如果用上述的通信方式，那么是否会导致永远只收到优先级最高的报文，如上述，只收到A的报文？
      3、是否有更合理的方式，主机既可以接收到各个从机的报文，又能在必要的时候对各从机发送报文？
      4、如果有大于8字节的数据，即出现多帧的情况，有什么较好的处理方式？

275891381

hw531025 发表于 2018-5-21 12:18
首先谢谢您的回复。
1、像您举例所说，如果A被打断，我又没有设置自动重传的功能时，A的报文是否就会遗 ...

1：不重传那你就要自己软件读标志位处理吧，没用过不重传，不太懂
2：你既然轮询了，从机就等待轮询信号再发送也可以呀，肯定丢不了
3：加入你没有过滤，就试试降低被收到那个从机的发送频率试试能不能收到其他的，可能频率太高，优先级也高，一直占用着总线

275891381

1：论坛里有个pdf专门介绍怎么屏蔽；冲突的时候接收a的时候，比a低的都自动停了，高的会打断a，一般不会这么巧都冲突，接收a的过程中can忙着，别的不会发出来
2：can只能同时一个在发，加入优先级最高的不同的发送，别的肯定都发不出来了，发送都要有适当间隔，can很快哪怕一点点就可以
3：从机之间不互发的话，都设置只能接受主机就可以了，主机就不设置屏蔽，不就可以能收能发了吗
id的设置系统很简单可以这样随意设置，节点多了id设置也是有技巧的，要有利于设置屏蔽规则

WYS666

http://www.openedv.com/forum.php?mod=viewthread&tid=10328

hw531025

WYS666 发表于 2018-5-21 12:07
http://www.openedv.com/forum.php?mod=viewthread&tid=10328

这个我已经看完，但是感觉帮助不大。接收端的相关内容并没有很全面。

275891381

hw531025 发表于 2018-5-21 12:12
这个我已经看完，但是感觉帮助不大。接收端的相关内容并没有很全面。

那证明你没有看懂，3楼pdf足够你用了

hw531025

275891381 发表于 2018-5-21 12:06
1：论坛里有个pdf专门介绍怎么屏蔽；冲突的时候接收a的时候，比a低的都自动停了，高的会打断a，一般不会这 ...

首先谢谢您的回复。
1、像您举例所说，如果A被打断，我又没有设置自动重传的功能时，A的报文是否就会遗漏，即丢包？
2、因为主机还设置了自己的轮询周期，值是100ms，在这个前提下，是否有机制可以避免丢包？
3、目前的设置是，从机从不互发，只接受来自主机的消息。主机不屏蔽，目前的一个状况就是，本来五个从机都在发，但是最终就只收到一台从机的消息，另外四台的消息都收不到。

hw531025

275891381 发表于 2018-5-21 12:17
那证明你没有看懂，3楼pdf足够你用了

pdf所提供的只是配置相关的内容，对于多机的调度问题，并未提及。

hw531025

275891381 发表于 2018-5-21 12:49
1：不重传那你就要自己软件读标志位处理吧，没用过不重传，不太懂
2：你既然轮询了，从机就等待轮询信号 ...

1、自动重传会导致网络风暴和总线拥塞么？不用重传的功能就是担心这两个因素2、ID：103和104都是2s发一次，ID 108是300ms一次，最终只收到104的数据，另外两个都没有。

275891381

hw531025 发表于 2018-5-21 12:53
1、自动重传会导致网络风暴和总线拥塞么？不用重传的功能就是担心这两个因素2、ID：103和104都是2s发一次 ...

这个大间隔应该阻塞不了，应该是代码问题了，有条件的话挂个can分析仪，看看发出来没

hw531025

275891381 发表于 2018-5-21 14:23
这个大间隔应该阻塞不了，应该是代码问题了，有条件的话挂个can分析仪，看看发出来没

好的，谢谢，我再调试看看！

pnyssk

楼主：
    你好！
    除了CAN模块的使用方法，你还需要了解一定的CAN物理层协议的知识。你样用CAN是很浪费的，而且效率很低。
    1. 对于CAN模块的使用和历程网上有很多，你需要多研究。
    2. 根据总线物理层定义，基本上所有的数据都会发送的到总线上，只是可能因为仲裁而被延时。CAN一般不用分主机和从机的，每个节点只需要按照周期去发送数据，总线上一般是不会阻塞的，基本上CAN模块已经将处理了大部分繁琐的工作，我们只用专注手法数据就可以了，至于总线仲裁和应答都是由模块自己完成的，我们关注下CAN模块的状态寄存器就可以了。即使拥塞了也没事，只要6个设备都做好BUSOFF处理就能解决总线的大部分问题。
    3. 我推荐一种总线模型（见附件），每一个设备有三个报文ID，第一个ID表示设备的状态，按照300ms周期发送；第二个ID表示查询指令，按照100ms周期发送；第三个ID表示对第二个ID是应答。
    4. 至于大于64位的数据的话，可以将数据的Byte0设为帧数的指定，0x00表示只有单帧，0x01表多帧的第一帧，0x02表多帧的第二帧，以此类推；然后将Byte1设为数据的长度，表示有多少个字节的数据，多余的字节就用0x55或者0xAA填充，每接受帧数据的一帧，接收端就发送一个肯定指令，然后发送端就继续发送下一帧的数据。

Di诺

pnyssk 发表于 2018-5-27 14:27
楼主：
    你好！
    除了CAN模块的使用方法，你还需要了解一定的CAN物理层协议的知识。你样用CAN是很 ...

看哥们理解CAN挺透彻，能多讲讲不，最好能最大限度使用CAN，而不是自己在数据方面头疼阻塞重传什么的。CAN能在汽车上用，感觉制定CAN协议的时候，已经将很多的问题考虑进去了，不然可靠性不能保证。

hw531025

pnyssk 发表于 2018-5-27 14:27
楼主：
    你好！
    除了CAN模块的使用方法，你还需要了解一定的CAN物理层协议的知识。你样用CAN是很 ...

谢谢您的回复，因为我接触CAN总线的时间比较短，虽说看了一部分的例程和文档，但是总觉得认识不够深刻。

像您所说，总线仲裁而延时的情况，我发现，有时候超过三条报文（比如四条）同时到达，STM32是没办法将优先级最低的那条接收到的，并不是延时接收。不知道您有没有遇到过这个情况。

另外，我看文档说，CAN总线的实时性不高，如果我想用在实时性较高的场景，又该如何处理？

最后，想请教您BUSOFF处理的方式？您是否能提供相应的例程借为学习参考？

感谢您的细致回复！

pnyssk

你好！
    你所说的情况是否是FIFO溢出了，当FIFO的3个邮箱都是满的，下一个有效的报文就会导致溢出，并且一个报文会丢失，至于哪个报文会被丢弃，取决于对FIFO的设置。CAN模块CAN_MCR寄存器可以设置自动重传，当CAN的仲裁或者错误，都会导致数据发送不成功，这时发送失败的数据会从新被发送。
    CAN总线的特点是高性能和可靠性，对于500Kbps的CAN总线，每个位时间为2us，发送一个完整标准数据帧大概是256us的时间。如果按照6个节点的模型来算，按照最坏的情况来算，被仲裁5次，那么一个数据大概被延时1.3ms（粗略的计算，只是提供思路）之后才能被发送出去。CAN总线的稳定性和准确性是毋容置疑的，至于实时性需要看对总线的处理，或者按照最坏的情况来算延时情况，对于这个延时，你是否能接受。
    至于BUSOFF的历程的话，这个发不了。你可以研究下CAN总线BUSOFF快和慢恢复机制。

hw531025

pnyssk 发表于 2018-5-28 14:26
你好！
    你所说的情况是否是FIFO溢出了，当FIFO的3个邮箱都是满的，下一个有效的报文就会导致溢出，并 ...

好的，您说的我记下来了。

今天还发现一个新的问题，就是接收报文这部分基本比较稳定了，但是把定时发送报文加入进去，最终总线上好像就只剩下发送的报文（优先级最高），接收不到其他报文。关于这部分解决思路，您有什么建议吗？