Autosar_SWS_CANInterface官方文档翻译

        CanIf的服务可分为以下主要组别:
        初始化
        传输请求服务
        传输确认服务
        接收指示服务
        控制器模式控制服务
        PDU模式控制业务

        CanIf的可能应用：
        1.中断模式：CanDrv处理由CAN控制器触发的中断。基于事件的CanIf在事件发生时得到通知。在这种情况下，相关的CanIf服务在CanDrv中相应的ISRs中被调用。
        2.轮询模式：CanDrv由SchM触发并执行后续进程(轮询模式)。在这种情况下，必须在定义的时间间隔内周期性地调用Can_MainFunction_Write/Read/BusOff/Wakeup/ Transceiver()。CanIf由CanDrv通知发生在其中一个CAN控制器中的事件(接收、传输、BusOff、超时)，与中断驱动的操作相同。CanDrv负责更新CAN控制器中发生的事件的相应信息，例如L-PDU的接收。
        3.混合模式:中断和轮询驱动的CanDrv
根据使用的can控制器，该功能可以分为中断驱动和轮询驱动的操作模式。示例:轮询驱动的FullCAN接收和中断驱动的BasicCAN接收，轮询驱动的发送和中断驱动的接收等。

        该规范描述了一个唯一的接口，它对所有三种操作模式都有效。总的来说，CanIf以同样的方式工作，无论是在中断、任务级别还是混合级别处理任何事件。唯一的区别是调用上下文，可能还有通知的中断方式:抢占式还是协作式。所有业务均按照配置执行。

        硬件对象句柄:
        用于传输(HTH)和用于接收(HRH)的硬件对象句柄(HOH)表示对CAN邮箱结构的抽象引用，其中包含CAN相关参数，如CanId、DLC和数据。基于CAN硬件缓冲区抽象，每个硬件对象在CanIf中引用，独立于CAN硬件缓冲区布局。HOH被用作CanDrv接口服务调用中的一个参数，由CanDrv的配置提供，并被CanDrv用作CAN邮箱通信缓冲区的标识符。

        CanIf仅作为硬件对象句柄的用户，但不基于硬件特定信息解释它。因此，CanIf仍然独立于硬件。

        CanIf应避免直接访问硬件特定通信缓冲区，并应仅通过CanDrv接口服务访问它。CanIf仍然独立于硬件，因为使用HOH参数调用CanDrv接口，这些参数从具体的CAN硬件缓冲区属性中抽象出来。

        每个CAN控制器可以在CAN邮箱中提供多个CAN传输硬件对象。这些可以在逻辑上链接到一个完整的硬件对象池(多路复用硬件对象)，从而由一个HTH寻址。

        HRH的定义:HRH应该是 引用CAN控制器邮箱的逻辑硬件接收对象的句柄
        HRH应允许CanIf使用引用的接收单元的BasicCAN或FullCAN接收方法，并将已接收的L-SDU指示给目标上层模块
        如果HRH引用为BasicCAN接收配置的接收单元，则应在CanIf中启用软件过滤
如果使用多个HRH，每个HRH应至少属于单个或固定的Rx L-SDU (CanRxPduIds)组。

        HTH的定义:HTH应该是 引用CAN控制器邮箱的逻辑硬件传输对象的句柄
        HTH应使CanIf能够使用参考传输单元的BasicCAN或FullCAN传输方法，并确认传输到目标上层模块的L-SDU
        每个CanIfTx L-PDU应在配置时静态分配给一个CanIfBufferCfg配置容器(参见CanIfTxPduBufferRef  即可以认为每个发送的Pdu ,在canif层需要配置一个CanIfBufferCfg)。
CanIf Tx L-pdu不引用hth，但是CanIfBufferCfg引用hth。
        如果使用多个HTH，每个HTH应属于单个或固定的Tx L-PDU (CanTxPduIds)组。
CanIf应能够使用一个CanDrv的所有hrh和hth作为公共的、从零开始的单一编号区域。专用的hrh和hth来自CanDrv的配置集。在编号区域和硬件对象内的HTH/HRH的定义为CanDrv。

        L_Pdu可分为两种类型(动态L_PDU 和 静态L_PDU  二者的区别在于动态的L_PDU可以使用API 'CanIf_SetDynamicTxId'来设置/更改Tx-PDU的CAN标识符。)
注意：目前来看仅在Tx L_PDU里存在动态和静态类型的区分，是在DavinciCfg中只有Tx_L_PDU 配置成动态的选项

        静态L-PDU: 

        CanIf为上层提供对CAN L-SDU相关数据的一般访问。

        CanIf应将每个L-PDU只分配给一个CAN控制器。因此，禁止将单个L_PDU分配给多个CAN控制器。使用此关系是为了确保在传输确认和接收指示事件时LSDU调度正确。通过这种方式，CanIf能够从L-PDU中识别CAN控制器。
        CanIf支持激活和不激活属于一个CAN控制器的所有l - pdu进行传输和接收。
每个L-PDU与上层模块相关联，以保证接收、传输确认和数据访问过程中的正确调度。每个上层模块可以使用L-pdu 同时 服务于不同的can控制器（??????）。

        L-PDU的使用分为两种不同的方式:
        对于传输请求和收发轮询API，上层模块使用CanIf定义的L-SDU ID (CanTxPduId/CanRxPduId)作为参数。
        对于所有由CanIf在上层模块调用的回调api, CanIf将上层各模块定义的目标PduId作为参数传递。

        其原则是，呼叫方必须使用已定义的目标L-PDU/L-SDU Id
        如果不上电初始化，上层对CanIf进行传输请求，则不向下层传输l - sdu，并调用DET。

        动态L_PDU:
        CanIf应该支持使用CanIfRxPdu-CanIdMask过滤传入消息的能力。在对两个id应用CanIfRxPduCanIdMask后，通过比较传入的CanId和存储的CanIfRxPduCanId来进行过滤。这应该在不带掩码的常规CanId过滤之后进行，以允许对一些属于掩码定义的范围或基于CanId的范围的CanId进行单独处理。
        在动态L_SDU发送过程中，当定义了CanIfTxPduCanIdMask时，通过元数据提供的CanId的可变部分必须使用该掩码与Ca