AUTOSAR中CAN信号是如何触发COM回调的呢？

在AUTOSAR中，COM模块提供了两种机制来处理接收到的PDU：ComRxPduCallout和ComNotification

在CAN驱动中，回调函数通常是通过中断或轮询的方式触发的。当CAN控制器接收或发送CAN数据帧时，CAN控制器会产生相应的中断或状态变化，在中断服务例程（ISR）中或轮询循环中，CAN驱动会调用相应的回调函数来处理这些CAN事件。

第一种回调，可以按照收到信号的顺序触发COM层的回调，因为收到的信号会存在fifo里，这就可以按照顺序触发。

先说结论：当Can_MainFunction_Read 处理接收到的消息时，CanIf层将调用PduR层的PduR_CanIfRxIndication 函数。然后，PduR层将该消息路由到COM层，并调用Com_RxIndication 函数。最后，当COM层处理接收到的消息时，它将触发配置的回调函数。

为了在接收到CAN消息时触发COM层的回调，需要遵循以下步骤：

配置CanIf层：确保在CanIf层为接收到的CAN消息配置了相应的CanIfRxPdu。这包括为其指定一个PduId，并将其与期望的CAN ID 和数据长度相关联。

配置PduR层：在PduR层，创建一个路由从CanIf层到Com层。这可以通过在PduR中定义PduRRoutingPath并关联CanIf的PduId 和Com层的PduId 来实现。

配置COM层：在COM层，为接收到的CAN消息定义一个接收IPDU，并指定一个回调函数。这个回调函数将在接收到新消息时被调用。通常，回调函数在接收到消息后会对其进行处理，例如将数据传输到应用程序。

这种回调是通过COM收到CAN的PduID，遍历一个数组，之后根据返回的数字idx再去遍历回调数组，根据idx来判断要执行哪个回调，这个函数的执行是在 Com_RxIndication 里执行的。

通过davinci配置可以看出，CAN Controller中RXprocessing是polling模式，那么callout的回调触发是在polling模式下触发；

也就是调用的是下面这两个函数，注意根据配置要区分Basic CAN和Full CAN；

假设，现在进来的信号是通过Basic can进来的，在Polling模式下，Basic CAN模块是通过轮询CAN控制器中的接收缓冲区（mailBox）来接收CAN数据帧，【也就是如果是报文如果在FilterMask里的，数据可以通过CAN传给canif，否则，不管】

在这个过程中，当CAN控制器接收到一个CAN数据帧时，CAN控制器会将CAN数据帧存储在FIFO Buffer中。Basic CAN模块在轮询CAN控制器的接收缓冲区时，会从FIFO Buffer中读取CAN数据帧，并将CAN数据帧中的信号解析出来。解析后的信号将被传递到CanIf模块中，以便上层模块进行处理。

将接收到的CAN数据帧解析的信号传递到CanIf模块；

之后将数据在传到PDUR,之后在传到COM。

第二种回调，ComNotification是一个接口，用于通知上层模块有新的数据到达或数据发送完成。

在代码中可以是通过一个TASK来循环执行 Com_MainFunctionRx 这个任务，Com_MainFunctionRx是一个COM模块的主任务函数，用于处理接收到的数据。当Com_MainFunctionRx函数接收到数据后，可以通过调用ComNotification来触发通知事件，通知上层应用程序进行处理。

当数据更新时，COM层会检查所有与该数据相关联的ComNotification，并将其标记为“待触发”。然后，COM层会在稍后的时间点触发已标记为“待触发”的ComNotification，并将相关的数据对象ID作为参数传递给应用程序。

假设收到的是信号组，遍历所有COM收到的信号组，如果信号组的数据完整，就触发ComNotification的，进入到下一个处理。

当Com接收到一个PDU时，它会根据配置选择是将PDU缓存起来还是直接调用应用程序提供的回调函数。如果选择了缓存，那么PDU将被缓存起来，并等待应用程序调用Com_ReceiveSignal或Com_ReceiveSignalGroup函数时进行处理；如果选择了直接调用回调函数，则会将PDU的数据传递给应用程序提供的回调函数进行处理。

Com_CacheOrCallRxDeferredCbkFctPtr，用于缓存或调用接收到PDU时的回调函数。

当Com接收到一个PDU时，它会根据配置选择是将PDU缓存起来还是直接调用应用程序提供的回调函数。如果选择了缓存，那么回调函数的索引将被缓存起来，并等待应用程序调用Com_ReceiveSignal或Com_ReceiveSignalGroup函数时进行处理；如果选择了直接调用回调函数，则会将PDU的数据传递给应用程序提供的回调函数进行处理。

对比两种回调：

ComRxPduCallout的触发顺序可以按照接收到PDU的顺序进行，因为在处理每个PDU时，COM模块都会等待应用程序返回处理状态，然后再继续处理下一个PDU。因此，如果应用程序处理PDU的顺序与PDU到达的顺序相同，则ComRxPduCallout的回调也会按照PDU到达的顺序进行。

ComNotification是一种机制，允许应用程序在数据更新事件发生时执行自定义逻辑，并不要求应用程序返回状态值。当COM模块检测到数据更新事件时，它会对与更新事件相关联的数据对象注册的ComNotification进行回调，并将相关的数据对象ID作为参数传递给应用程序。ComNotification的触发顺序不能按照接收到PDU的顺序进行，因为在数据更新事件发生时，COM模块无法确定哪些数据对象会发生更新以及它们的更新顺序。

举例：

假设有两个节点A和B，它们之间通过CAN总线进行通信。节点A向节点B发送两个数据对象1和2。首先，节点A发送数据对象1，然后发送数据对象2，节点B按照接收到PDU的顺序先接收到了数据对象1，然后接收到了数据对象2。此时，如果节点B上的应用程序使用ComRxPduCallout来处理PDU，并且在处理PDU时需要访问其他节点发送的数据对象，那么ComRxPduCallout的回调顺序将按照节点发送的顺序进行。因此，节点B上的应用程序将按照1->2的顺序处理PDU，并且可以在处理PDU时访问先收到的数据对象1。

相反，如果节点B上的应用程序使用ComNotification来处理数据更新事件，并且在处理数据更新事件时需要访问其他节点发送的数据对象，那么ComNotification不一定按照节点发送顺序执行。例如，如果数据对象1和2之间存在依赖关系，并且在数据对象2更新前，数据对象1也会发生更新，那么节点2上的应用程序可能会在接收到数据对象2更新事件前先接收到数据对象1的更新事件。因此，节点B上的应用程序不能保证按照节点发送顺序执行，因为更新事件的顺序可能与节点发送顺序不同。

ComNotification的接收对象的依存关系是通过ComSignal的更新顺序来判断的。在标准的AUTOSAR架构中，ComSignal是一个最小的数据单元，用于在不同的ECU之间传输数据。ComSignal可以表示为一个信号，例如车速、转速等。ComSignal可以在ECU之间交换，也可以在ECU内部使用。每个ComSignal都可以拥有一个或多个ComSignalGroup，其中每个ComSignalGroup包含一组相关的ComSignal。这些ComSignal可以具有不同的数据类型、精度、单位和值范围。ComSignalGroup可以在ECU之间交换，也可以在ECU内部使用。

当一个ComSignal或ComSignalGroup的值发生变化时，ComNotification会将更新事件通知给所有已注册该ComSignal或ComSignalGroup的应用程序。应用程序可以在接收到更新事件时执行自定义逻辑。

ComNotification的接收对象的依存关系是基于ComSignal的更新顺序来判断的。如果多个ComSignal的更新顺序存在依赖关系，那么它们的接收对象之间也会存在依赖关系。例如，如果一个ComSignal的更新依赖于另一个ComSignal的更新，那么它们的接收对象之间也会存在依赖关系。在这种情况下，应用程序需要确保在接收到依赖的ComSignal的更新事件后再处理当前ComSignal的更新事件，以避免使用不一致的数据。

总之，ComNotification的接收对象的依存关系是基于ComSignal的更新顺序来判断的。如果多个ComSignal的更新顺序存在依赖关系，那么它们的接收对象之间也会存在依赖关系。应用程序需要确保在接收到依赖的ComSignal的更新事件后再处理当前ComSignal的更新事件，以避免使用不一致的数据。

审核编辑：刘清