前言首先，请问大家几个小小问题，你清楚：
今天，我们来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲：  正文CAN驱动作为一个在日常开发项目中经常接触到的重要驱动模块，AUTOSAR组织对CAN Driver有着十分全面而准确的实现要求与相关关键词参数的定义。 经常发现大家在开发过程中总是会忽略或者混淆这些模块的关键词的定义，导致最终双方在沟通过程中存在很多的误解，在开发过程中也会存在诸多不必要的失误与bug的产生，因此本文小T将带领大家一起来了解AUTOSAR框架的CAN Driver一些十分重要的关键词解释以及难以理解的基本概念，助力我们日常工作中的CAN驱动开发。 小T未来会继续更新该AUTOSAR词典专栏，该词典将会讲解有关AUTOSAR框架下难以理解或者容易混淆的基本概念与相关重要知识点，像“百科词典”一样帮助大家查漏补缺，助力大家高效完成基于AUTOSAR的软件开发，欢迎大家多多关注与转发该专栏。 CAN 驱动关键词定义小T通过学习AUTOSAR CAN Driver标准文档，并结合自身实战经验，将CAN Driver模块的关键词定义整理如下表所示：  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将三者的区别与联系整理如下表所示：  CanHwObjectCount 该参数按照AUTOSAR官方文档中的定义，表示的就是Hardware Object中的数目，不过需要注意的是该参数面向的对象是HOH，即HRH或者HTH。 该参数表示是否为该HOH配置了FIFO机制，如果数目为1，则并没有FIFO进行缓存数据，如果大于1，那么就是为该HOH配置了FIFO的数据缓存机制，这种缓存机制对于防止CAN接收或者发送的重要报文丢失至关重要。 如下图所示便展示了CanHwObjectCount在HOH中的配置：  
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绑定； 注意事项：
推荐配置方案 小T结合实战经验，将软件开发过程中常见的四类报文类型：应用报文，网络管理报文，诊断报文，Xcp报文的发送与接收的mailbox配置方案总结如下表所示：  推荐配置方案总结如下：
CAN 驱动硬件Buffer类型了解了上述CAN驱动推荐方案之后，我们接下来需要进一步探究下对于can controller硬件资源内部对于用于存储CAN L-PDU的buffer是如何定义的？ 一般来讲，现在市面上主流的CAN Controller对于其硬件资源按照发送与接收可以分为如下几种类型Buffer：
接下来将针对每种硬件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模式  如上图可知，每次发送优先级按照如下方式进行判定：
Tx Buffer Tx Queue模式  如上图可知，每次发送优先级按照如下方式进行判定：
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的情况，那么有如下两种处理方式：
|
|
|
