FULL CAN和BASIC CAN

为什么需要FullCAN和BasicCAN？

在CAN驱动层，可以通过过滤的方式，过滤一段范围内的CanID，也就是说：会有一段范围内的报文接收进来，但是接收进来的这一段范围的报文并不一定都是上层所需要的，怎么办呢？用软件方式，再过滤一遍，由CanIf过滤所需要的CAN报文。因此，提出了FullCAN和BasicCAN的概念。

比如：HRH对应BASIC CAN类型，接收CanID范围：0x10~0x18，CanIf根据过滤算法，在0x10~0x18范围内过滤出需要的0x10、0x13、0x14、0x16、0x17送给上层，而其余的丢弃。

Basic CAN

尽可能快地复制信息，因为所有报文仅由一个接收寄存器接收。

一个HWObject(Hardware Object)可以处理一段范围的CanId

Full CAN

有多少接受寄存器取决于硬件

也可以选择直接操作硬件寄存器

一个HWObject(Hardware Object)只能处理单个CanId

不同报文类型如何选择FULL CAN后者BASIC CAN？

应用报文：一般选择配置成FULL CAN类型，对于应用报文，一般不需要缓存，使用最新接收的数据即可。对于发送的应用报文，都配置成FULL CAN类型需要一个前提：上层需要发送应用报文数量＜底层硬件缓存区数量。比如：底层发送硬件缓存区数量为32，节点需要发送的应用报文数量为50，显然无法将50个发送的应用报文都配置成FULL CAN。遇到这种情况，一般会将重要的应用报文配置成FULL CAN，而其他要发送的应用报文配置成BASIC CAN。这样配置以后，硬件缓存区的分配就需要混用，即：Dedicated Tx Buffers+Tx Queue或者 Dedicated Tx Buffers+Tx FIFO，如下所示

如上图，ID3、ID15、ID20是比较重要的应用报文，配置成FULL CAN，分别给一个独立的缓存区；其他的缓存区则配置成BASIC CAN，即：一个缓存区可以发送多个不同CanID的报文。

诊断报文：由于诊断报文的请求及响应需按顺序处理，且数据不能被覆盖，一般将诊断报文配置为Basic-CAN，即共用Buffer，先进先出（FIFO）；

网络管理报文：同样按网管报文的接收与发送进行区分：

对于接收类型的网管报文，一个接收节点通常会要求可以接收一段范围的网管报文，因此一般配置成Basic-CAN。

对于发送类型的网管报文，由于单个节点的发送的网理报文是唯一的，在资源满足情况下，推荐配置成Full-CAN，资源不够情况下配置成Basic-CAN也是可以的；

XCP报文：对于XCP报文，与诊断报文类似，XCP的CTO报文报文需要顺序执行，推荐配置成Full-CAN类型。

其他报文：如果系统中有必须经常接收的报文，请将它们放在Full CAN对象中。