Basic Can和Full CAN却别(转载)

1. CAN通信模式概述

在汽车电子系统中，CAN通信模式分为Full CAN和Basic CAN两种。

 

二、两种CAN模式的具体分析

2.1 ► Basic CAN模式特点(低性能写入，周期长)

Basic CAN模式，每个硬件对象(HOH)能同时处理多个L-PDUs。这种模式充分利用了硬件对象HOH的处理能力，使得多个数据单元能够并行处理，提高了通信效率。

强大的CAN ID处理能力：Basic-CAN使得一个硬件对象（HOH）能够同时处理多个L-PDUs，即它能高效地处理一段特定CAN ID范围内的报文。

FIFO缓存机制：Basic-CAN通常与FIFO（先进先出）缓存策略相结合，这种机制确保接收到的报文按照它们到达的顺序被妥善存储并处理。

2.2 ► Full CAN模式特点（高性能写入，周期短）

在Full CAN模式下，每个硬件对象(HOH)仅能处理单个的L-PDU。单个CAN ID处理能力：每个HOH仅能处理特定的L-PDU，即每个HOH仅能处理单个CAN ID的报文。

同样，专用缓存区在Full-CAN模式下，每个CAN ID都会配备一个专门的缓存区，以确保新报文到达时，原有报文不会被覆盖。

3，适用场景：Full-CAN模式特别适用于处理应用报文和标定报文，这类报文通常更关注最新接收的数据而非缓存。对于发送报文，若上层需要发送的报文数量少于底层硬件缓存区容量，则可配置为Full-CAN模式。

2.23► 硬件对象（HOH）一个CAN硬件对象可以理解为一个PDU缓存区

接下来，我们来了解HOH。HOH实质上是用于存放CAN报文信息的RAM段，类似于常说的邮箱（mailbox）。根据收发功能的不同，HOH可进一步细分为HRH与HTH。在实际项目中，HOH的使用可以根据需求灵活调整，但为了减少报文阻塞的可能性，通常建议全面使用HOH。

023. 实际使用场景

在实际项目中，我们常常遇到不同类型的报文，如诊断报文、应用报文、网络管理报文以及XCP报文。针对这些报文，我们需要根据其特性来合理配置CAN模式。

3.1 ► 报文类型及模式配置

对于应用报文，由于它们通常更关注最新接收的数据，而非缓存，因此我们通常将其配置为Full-CAN模式。在发送应用报文时，为了减少仲裁导致的阻塞，我们会优先选择将那些发送周期短且重要的报文配置为Full-CAN，而将长周期的报文配置为Basic-CAN。

诊断报文则因其请求及响应需按顺序处理且数据不能被覆盖的特性，一般被配置为Basic-CAN模式，即采用共用Buffer的先进先出（FIFO）方式。

网络管理报文的配置则根据其接收与发送类型有所不同。对于接收类型的网络管理报文，由于一个节点通常需要接收一段范围内的报文，因此一般也被配置为Basic-CAN模式。而对于发送类型的网络管理报文，在资源充足的情况下，我们推荐配置为Full-CAN模式，以确保报文的优先级和实时性；若资源不够，配置为Basic-CAN模式也是可以的。

对于XCP报文，由于其报文需要顺序执行，与诊断报文类似，我们也推荐将其配置为Full-CAN类型，以确保报文的顺序性和完整性。

 

034. 问题案例分析

4.1 ► 车身报文配置问题

问题背景：在某系统中，存在一个车身报文，其周期为100ms，ID为0x200。理论上，该报文应每100ms发送一帧，然而在实际应用中，我们发现接收此报文的时间间隔达到了3.2s。

问题分析：经过调查，我们发现该报文被配置为Basic CAN类型，并采用了FIFO模式，同时设置depth为32，即中断接收模式。在这种模式下，只有当FIFO满时才会触发接收中断。由于depth设置为32，这意味着需要32帧报文填满FIFO才会触发中断，从而导致接收报文的周期延长至3.2s。

解决方案：为了解决这一问题，我们将depth值改为1。这样，每当接收一次报文时，就会立即触发接收中断，从而确保了接收报文的周期准确性。