今天和一个同行讨论了关于如何减少CAN Message的tolerance的问题 , 大家都知道AUTOSAR CAN DRIVER 针对于CAN Frame的处理存在CAN Driver Layer存在 POLLING 和ISR 两种方式，在COM Layer 有Deferred 和Immediate两种方式。 那么究竟哪种组合方式对于SW 架构设计更合理呢，两种方式的使用的场景又如何呢？

接下来我们详细分析下

RX Message

ISR & Immediate

当收到RX message时立刻产生中断,中断服务函数中的实现会将数据拷贝到COM Layer,同时通知到Application， Application 接到通知后会从COM BUFFER 中读取数据

Tolerance

可以看到使用这种方式，报文从接收，到APP 获取整个过程是同步完成的，我们可以认为Tolerance为0（代码执行时间不计）

Weakness

由于ISR 方式可以随时打断OS TASK 运行，因此需要考虑数据一致性的问题 以防止ISR 和 OS TASK 同时读写同一个BUFFER（E.G OS Task正在读，ISR 发生开始写）. 如果通过加中断保护方式进行防护，带来的问题是，可能由于禁止中断的时间过长或者过频，导致其他ISR 的功能也受到影响，正常设计中我们通常把最重要的功能放入中断中执行，目的就是保证功能即使在RUNTIME 出问题时也尽可能保证这部分重要功能不受到影响，但如果禁止中断的时间过长或者过频，就会失去此意义。

同时由于所有RX 报文都会触发ISR， 如果总线上出现一个“坏小子” 会对我们造成很大的影响

ISR & Deferred

当收到RX message时立刻产生中断,中断服务函数中的实现会将数据拷贝到COM Layer,同时设置Flag, 当Com_MainFunctionRx 被调用时 才会通知到Application， Application 接到通知后会从COM BUFFER 中读取数据

Tolerance

虽然ISR 同步的将数据拷贝到BUFFER 中，但是Application接收到的通知进而读取数据是受到 Com_MainFunctionRx调度影响的， 因此这种方式Tolerance的大小就是Com_MainFunctionRx的调度周期

Weakness

 除了上面提到的使用ISR的问题，由于真正通知Application获取数据的是Com_MainFunctionRx， 因此并不会真的减少Tolerance,因此使用ISR就失去了意义

Polling & Immediate

当收到RX message时，数据会存储在Can Mailbox 中，当Can_Mainfunction_Read函数被调度起来，会将数据拷贝到COM Layer,同时通知到Application， Application 接到通知后会从COM BUFFER 中读取数据

Tolerance

从上图可以看到当Can_Mainfunction_Read函数被调度起来整个流程是个同步过程，因此Tolerance 就是Can_Mainfunction_Read的周期

Polling & Deferred

当收到RX message时，数据会存储在Can Mailbox 中, 当Can_Mainfunction_Read函数被调度起来会将数据拷贝到COM Layer,同时设置Flag, 当Com_MainFunctionRx 被调用时 才会通知到Application， Application 接到通知后会从COM BUFFER 中读取数据

Tolerance

从上图可以看到Tolerance 就是Can_Mainfunction_Read的周期 + Com_MainFunctionRx的周期

Conclusion

通常在我们设计中我们会把Can_Mainfunction_Read的周期设置为1ms. 将Com_MainFunctionRx的周期 设置为10ms (Com_MainFunctionRx  > Can_Mainfunction_Read )

因此我们可以得出结论

1. 如何报文tolerance需要小于1MS –>只能选择ISR & Immediate 模式
2. 如何报文tolerance需要1~2 MS     –> 可以选择Polling & Immediate 模式
3. 如何报文tolerance 并无特殊要求     –> 可以选择Polling & Deferred 模式 Or ISR & Deferred 模式. （tolerance = Com_MainFunctionRx + Can_Mainfunction_Read 周期）

但是我们也看到使用ISR的方式的缺点还是很明显，虽然可以少了那可能不到1ms的时间

Recommend

从功能安全角度开说，报文的tolerance 在1~2 ms 是可以接受的，因此大可不必使用ISR的方式为了减少那不到1ms的时间（特殊需求另说）

因此考虑到SW 架构的整体性能，有如下推荐

1.对于重要的报文，和ASIL 功能相关的使用Polling & Immediate 模式， 误差在1~2 ms

2. 对于重要的报文，和ASIL 功能无关的使用Polling & Deferred 模式， 误差在10ms

TX Message

针对TX message ,ISR 方式只对TX CONFIRMATION 起作用，周期报文的发送只受到Com_MainFunctionTx周期的影响，因此只要保证Com_MainFunctionTx的周期可以被所有报文的发送周期整除即可，

如果出于性能的考虑Com_MainFunctionTx的 设置的值，并不能被所有报文的发送周期整除

比如Com_MainFunctionTx设置为20ms, 但是存在10ms的周期报文，可以将这10ms 周期报文变为事件类型报文，同时由Application 自己计数触发