CAN驱动Mailbox配置过程中有哪些关键配置参数值得我们注意？

正文

CAN驱动作为一个在日常开发项目中经常接触到的重要驱动模块，AUTOSAR组织对CAN Driver有着十分全面而准确的实现要求与相关关键词参数的定义。

经常发现大家在开发过程中总是会忽略或者混淆这些模块的关键词的定义，导致最终双方在沟通过程中存在很多的误解，在开发过程中也会存在诸多不必要的失误与bug的产生，因此本文小T将带领大家一起来了解AUTOSAR框架的CAN Driver一些十分重要的关键词解释以及难以理解的基本概念，助力我们日常工作中的CAN驱动开发。

CAN 驱动关键词定义

小T通过学习AUTOSAR CAN Driver标准文档，并结合自身实战经验，将CAN Driver模块的关键词定义整理如下表所示：

CAN 驱动关键词定义解释#### CAN 驱动Mailbox关键配置参数

在底层MCAL CAN Driver配置过程中总是会存在许多容易混淆的关键配置参数，该类参数如果配置有误，有些时候就会出现让人费解的问题与bug，因此为了能够减小这类问题的出现，小T结合自身实战经验一起来学习下CAN驱动中关键配置参数的定义与相关注意事项。

Hardware Object

如上述表格中所述， 一个Hardware Object就是一个CAN L-PDU的buffer，用来存储仅一个CAN ID Message ，你将可以将其理解为就是我们常说的Mailbox，该Mailbox就是CAN 控制器硬件上的一个物理buffer空间，用来存储用于发送或者接收的一个CAN ID Message， 该CAN ID Message自然就是包含CAN ID，DLC， Data三个部分 。

HOH，HTH，HRH三者区别与联系

为了更好地理解HOH，HTH，HRH三者的区别，小T将三者的区别与联系整理如下表所示：

HTH,HRH,HOH三者区别与联系CanHwObjectCount

该参数按照AUTOSAR官方文档中的定义，表示的就是Hardware Object中的数目，不过需要注意的是该参数面向的对象是HOH，即HRH或者HTH。

该参数表示是否为该HOH配置了FIFO机制，如果数目为1，则并没有FIFO进行缓存数据，如果大于1，那么就是为该HOH配置了FIFO的数据缓存机制，这种缓存机制对于防止CAN接收或者发送的重要报文丢失至关重要。

如下图所示便展示了CanHwObjectCount在HOH中的配置：

1.CanHwObjectCount在HOH中的发送配置

2.CanHwObjectCount在HOH中的接收配置

如上图1所示，可以知道该HOH为发送类型的HOH，因此就直接可以理解为 HTH ，那么该HTH中定义了参数CanHwObjectCount的值为1，表示不存在FIFO机制， 仅是一个唯一的buffer ，如果数据发送或者接收比较频繁，意味着新数据可能来不及发送；

如上图2所示，可以知道该HOH为接收类型的HOH，因此就直接可以理解为 HRH ，那么该HRH中定义了参数CanHwObjectCount的值为2，表示存在深度为2的FIFO机制，如果数据发送或者接收比较频繁，至少存在深度为2的FIFO缓存空间来防止重要数据的丢失。

Full CAN与Basic CAN

在MCAL CAN Driver中的Full CAN与Basic CAN是用来修饰HOH的类型参数，该参数可以通过CanObejctType进行定义。

Full CAN：一般表示仅存在1个的Hardware Object与之对应，且该Full CAN类型的Hardware Object与特定的CAN ID Message绑定；

Basic CAN：一般表示存在1个或者多个的Hardware Object与之对应，且该Basic CAN类型的Hardware Object与非特定的CAN ID Message或者一定范围内的CAN ID Message绑定；

注意事项：

对于Basic Can类型的HOH 一般建议通过配置硬件过滤器来实现底层无关CAN Message的数据接收或者特定范围内的报文接收，减少不必要的硬件中断，也就从某种程度上降低了CPU负载；

当硬件资源较为充足且无需过多考虑新数据可能覆盖老数据的场景，一般推荐将HOH配置成FULL CAN类型。

在HOH的配置过程中，一般情况下均需要 先将FULL CAN类型的HOH统一配置在前，Basic CAN类型的HOH配置在后 ，否则容易造成生成的代码中Maibox使用错乱的情况。

推荐配置方案

小T结合实战经验，将软件开发过程中常见的四类报文类型：应用报文，网络管理报文，诊断报文，Xcp报文的发送与接收的mailbox配置方案总结如下表所示：

CAN Mailbox的四类报文推荐配置方案推荐配置方案总结如下：

诊断报文由于属于重要报文，丢失与发送均不允许丢失且存在严格的时序关系，因此发送与接收均推荐Basic CAN+FIFO 来设置；

Xcp报文发送与接收都是特定ID的报文，因此发送与接收均推荐Full CAN+Buffer来设置；

应用报文在mailbox硬件充足的前提下，发送与接收优先采用Full CAN+Buffer来设置，如果硬件资源不够的话，那么推荐采用Basic CAN+FIFO来配置；

网络管理报文接收一般是一定范围的报文，因此接收推荐采用Basic CAN+Buffer来配置，发送由于ID确定，因此推荐采用Full Can+Buffer来设置；

所有报文的发送与接收配置完成之后，一定要确保所有配置HOH中的CanHwObjectCount加起来的mailbox发送与接收数目分别不能超过芯片手册规定的发送mailbox与接收mailbox硬件资源总和；

CAN 驱动硬件Buffer类型

了解了上述CAN驱动推荐方案之后，我们接下来需要进一步探究下对于can controller硬件资源内部对于用于存储CAN L-PDU的buffer是如何定义的？

一般来讲，现在市面上主流的CAN Controller对于其硬件资源按照发送与接收可以分为如下几种类型Buffer：

发送硬件Buffer类型：Tx Buffer，Tx FIFO，Tx Queue；

接收硬件Buffer类型Rx Buffer，Rx FIFO；

接下来将针对每种硬件Buffer类型分别进行讲解：

Tx Buffer

Tx Buffer又名Dedicated Tx Buffer，该Buffer会与特定的CAN ID进行绑定，发送优先级是完全通过CAN ID越小，优先级越高，高优先级优先发送；

一般该Tx Buffer会配置HOH的CanObejctType类型为Full CAN模式。

Tx FIFO

上文中说的FIFO机制实际上在硬件底层可以分为两种，一种是Tx FIFO，另外一种就是Tx Queue，因为两种本身都是一种缓存空间。

Tx FIFO顾名思义就是按照“ 先进先出 ”的方式来进行发送，忽略CAN ID优先级，一般为了防止出现优先级反转现象，不建议使用FIFO模式。

Tx Queue

Tx Queue 作为FIFO机制的一种，与Tx FIFO本身有所不同的是放置新的Message发送请求时按照先后顺序来放置，但是发送时则与Tx Buffer机制一样，按照高优先级优先发送原则，即CAN ID越小，优先级越高，如果存在多个同样CAN ID的报文需要发送，那么数字小的Buffer ID号先发送。

除了上述单一的发送模式之外，绝大多数情况可能存在上述组合模式，组合模式下特别需要注意的是外发报文优先级的判定：

Tx Buffer + Tx FIFO模式

如上图可知，每次发送优先级按照如下方式进行判定：

取出Dedicated Tx Buffer中的最小CAN ID发送请求；

取出Tx FIFO中最老的CAN ID发送请求；

比较上述Tx Buffer与Tx FIFO分别取出的CAN ID发送请求，两者之间的CAN ID越小的发送请求优先发送。

Tx Buffer + Tx Queue模式

如上图可知，每次发送优先级按照如下方式进行判定：

取出Dedicated Tx Buffer中的最小CAN ID发送请求；

取出Tx Queue中最小CAN ID发送请求；

比较上述Tx Buffer与Tx Queue分别取出的CAN ID发送请求，两者之间的CAN ID越小的发送请求优先发送。

Rx Buffer

Rx Buffer与Tx Buffer同理， 一般都是与特定的CAN ID进行绑定，一般该Rx Buffer均会配置HOH的CanObejctType类型为Full CAN模式，如果此时老的数据CPU还没有处理完，新的数据将不会得到处理。

Rx FIFO

Rx FIFO典型的就是按照“先进先出”的方式进行CAN报文的接收处理，一般而言，Rx FIFO都会存在两个，一个是Rx FIFO0，另外一个是Rx FIFO1，这个根据实际情况进行选择。

同时Rx FIFO如果存在Full的情况，那么有如下两种处理方式：

Blocking Mode：表示如果FIFO已经满了，只有等到数据处理完成之后才可以放入新的数据，一般推荐使用该方式；

Overwrite Mode：表示如果FIFO已经满了，新来的数据可以覆盖掉最老的数据，如果采用OverWrite方式，需要确保获取数据时与接收数据时不会存在数据一致性问题；

审核编辑：刘清