AUTOSAR_SWS_CANInterface 阅读

一、简介

该规范描述了AUTOSAR基本软件模块CAN接口的功能,API和配置。
如图1.1所示,CAN接口模块位于低层CAN设备驱动程序(CAN驱动程序[1]和收发器驱动程序[2])与上层通信服务层(即CAN状态管理器[3],

CAN网络管理[ 4],
CAN传输协议[5],PDU路由器[6])。 它代表用于上层通信层的CAN驱动程序服务的接口。
CAN接口模块提供了一个独特的接口来管理不同的CAN硬件设备类型,例如定义的ECU硬件布局所使用的CAN控制器和CAN收发器。

因此,多个状态内部和外部CAN控制器CAN收发器可以由CAN State Managers模块基于以下功能来控制:
物理CAN通道相关视图。

CAN接口模块由所有独立于CAN硬件的任务组成,这些任务属于相应ECU的CAN通信设备驱动程序。 这些功能一次在CAN接口模块中实现,

因此基础的CAN设备驱动程序仅专注于对相应特定CAN硬件设备的访问和控制。

CanIf满足PDU路由器和AUTOSAR COM堆栈的上层通信模块的主控制流和数据流要求:传输请求处理,传输确认/接收指示/错误通知以及CAN控制器的启动/停止,从而唤醒/参与在网络上。它的数据
处理和通知API基于CAN L-SDU,而用于控制和模式处理的API提供了与CAN控制器相关的视图。在发送请求的情况下,CanIf使用相应的参数完成L-PDU的传输,并通过适当的CanDrv将CAN L-PDU中继到CAN控制器。在接收时,CanIf将接收到的L-PDU作为LSDU分发到上层。接收L-SDU与上层之间的分配
是静态配置的。在发送确认时,CanIf负责通知有关成功发送的上层。
CAN接口模块提供对CAN驱动程序和CAN收发器驱动程序服务的CAN通信抽象访问,以控制和监视CAN网络。 CAN接口将状态更改请求从CAN状态管理器向下转发到下层CAN设备驱动程序,然后向上转发
CAN驱动程序/ CAN收发器驱动程序事件由CAN接口模块转发到例如相应的NM模块。

1.1 一般功能

初始化
传输请求服务
传送确认服务
接待指示服务
控制器模式控制服务
PDU模式控制服务

CanIf的可能应用:

1.中断模式
CanDrv处理由CAN控制器触发的中断。 CanIf(基于事件)在事件发生时得到通知。在这种情况下,可以在CanDrv中的相应ISR中调用相关的CanIfservices。
2.轮询模式
CanDrv由SchM触发并执行后续过程(PollingMode)。在这种情况下,Can_MainFunction_ <Write / Read / BusOff / Wakeup /
必须在定义的时间间隔内定期调用Transceiver>()。
CanDrv通知CanIf有关在一个CAN控制器中发生的事件(接收,发送,BusOff,发送取消,超时)的消息,

等同于中断驱动的操作。 CanDrv负责更新属于CANController中发生的事件的相应信息,例如接收L-PDU。

3.混合模式:中断和轮询驱动的CanDrv
根据使用的CAN控制器,可以将功能分为中断驱动和轮询驱动两种操作模式。
示例:轮询驱动的FullCAN接收和中断驱动的BasicCAN接收,轮询驱动的发送和中断驱动的接收等 本规范描述了唯一的接口,该接口对所有三种类型的操作模式均有效。 总而言之,无论是在中断,任务级别还是混合处理任何事件时,CanIf的工作方式都相同。 唯一的区别是呼叫上下文以及通知中断的方式:抢占式或合作式。 所有

服务根据配置执行。
以下段落描述了CanIf的功能。

CanIf应避免直接访问特定于硬件的通信
标题,并只能通过CanDrv接口服务进行进行访问。C
(SRS_Can_01001)[SWS_CANIF_00023]的基本原理:CanIf仍独立于硬件,因为使用HOH参数调用了CanDrv接口,该接口从特定的CAN硬件样本属性中提取。
这些逻辑上可以链接到整个硬件对象池(多路替代的硬件对象),因此可以通过一个HTH进行交换。CanIf将使用两种类型的HOH来访问Can-

驱动
硬件传输手柄(HTH)和
硬件接收句柄(HRH)。

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

HTH的定义:HTH应该是引用
CAN Controller邮箱的逻辑硬件传输对象
HTH将使CanIf能够使用BasicCAN或FullCAN
参考传输单元的传输方法,并确认传输到目标上层模块的L-SDU
每个CanIf Tx L-PDU应该静态分配给一个
配置时可以使用CanIfBufferCfg配置容器(请参见CanIfTxPduBufferRef)。
CanIf Tx L-PDU不引用HTH,而是Can-IfBufferCfg,后者又引用HTH。
如果使用多个HTH,则每个HTH都应属于一个
或固定组的Tx L-PDU(CanTxPduIds)。
CanIf应当能够将一个CanDrv的所有HRH和HTH用作从零开始的通用单个编号区域。
专用的HRH和HTH源自CanDrv的配置集。 HTH / HRH在编号区域和“硬件对象”中的定义取决于CanDrv。

静态L-PDU

CanIf提供对上层CAN L-SDU相关数据的常规访问。 属性
下表中的表示为配置参数,并且
在第10章中指定:

CanIf只能将每个L-PDU分配给一个CAN控制器。 因此,禁止将单个L-PDU分配给多个CAN控制器。

CanIf只能将每个L-PDU分配给一个CAN控制器。因此,禁止将单个L-PDU分配给一个以上的CAN控制器。[SWS_CANIF_00046]的说明:使用此关系是为了确保在发送确认和接收指示事件时进行正确的LSDU调度。这样,CanIf能够从L-PDU识别CAN控制器。
CanIf支持激活和停用属于一个CAN控制器的所有L-PDU进行发送和接收(请参阅7.19.2,
请参见CanIf_SetPduMode(),[SWS_CANIF_00008])。有关L-PDU模式控制,请参阅第7.19节。
每个L-PDU与一个上层模块相关联,以确保在接收,传输确认和数据访问期间进行正确的调度。每个上层模块可以使用L-PDU来同时服务于不同的CAN控制器。
根据为整个AUTOSAR通信堆栈定义的PDU体系结构(请参见[7,分层的软件体系结构]),L-PDU的使用分为两种不同的方式:
1,对于传输请求和传输/接收轮询API,上层模块使用CanIf定义的L-SDU ID(CanTxPduId / CanRxPduId)作为参数。
2.对于由CanIf在上层模块调用的所有回调API,CanIf会将每个上层模块定义的目标PduId传递为参数。原理是,呼叫者必须使用被呼叫者的已定义目标L-PDU / L-SDU ID。
如果未执行开机初始化,并且上层执行了向CanIf的发送请求,则不会将L-SDU发送到下层,并且应调用DET。因此,无法在网络上传输未初始化的数据。 L-PDU / L-SDU发送功能的行为在第8.3.6节中详细说明。

 

 

 

动态L-PDU

CanIf应该支持使用CanIfRxPduCanIdMask过滤传入消息的能力。 在将CanIfRxPduCanIdMask应用于两个ID之后,应通过比较传入的CanId与存储的CanIfRxPduCanId来完成过滤。
应该在过滤不带掩码的常规CanId之后进行此操作,以允许对属于掩码或基于CanId的范围定义的范围内的某些CanId进行单独处理。
另外,当CanId驻留在L-SDU的元数据中时,应支持DYNAMIC Tx和Rx L-SDU。

在动态L-SDU的传输过程中,定义CanIfTxPduCanIdMask时,必须使用此掩码将通过元数据提供的CanId的可变部分与CanId合并。 没有CanIfTxPduCanIdMask且没有CanIfTxPdu-
已配置CanId,则MetaData应直接用作CanId。
在接收动态L-SDU的过程中,接收到的CanId必须放在L-SDU元数据中。 元数据的内容与CanIfRxPduCanId- Mask参数无关。
[SWS_CANIF_00844] d CanIf将支持动态L-PDU,其中CanId或CanId的相关部分位于L-SDU的元数据中。 C()

物理频道视图

CanIf应该提供一个ControllerId,它抽象
来自不同CanDrv实例的不同控制器。 CanIf中ControllerId的范围应以“ 0”开头。 它应该可以通过CANIF_CTRL_ID进行配置(请参见ECUC_CanIf_00647)

CanIf必须提供一个TransceiverId,该抽象
来自不同CanTrcv实例的不同收发器。 CanIf中的TransceiverId范围应以“ 0”开头。 它可以通过以下方式配置

CanIf支持多个物理CAN通道。 CanSm必须区分这些以进行网络控制。 CanIf API为多个基础物理CAN通道提供请求和读取控制

CAN硬件单元组合了一个或多个相同类型的CAN控制器模块,这些模块可以位于芯片上,也可以作为外部独立设备使用。 每个CAN硬件单元均由相应的CanDrv提供服务。
如果使用不同类型的CAN控制器,则还必须将不同类型的CanDrv与统一的API应用于CanIf。 CanIf在配置时收集有关CAN控制器及其硬件对象的数量和类型的信息。
这允许使用HOH从上层模块透明且独立于硬件访问CAN控制器(请参见第7.2节“硬件对象句柄”和第7.24节“多CAN驱动程序支持”)。 图7.4显示了一个CAN硬件单元,它由连接到两个物理通道的两个相同类型的CAN控制器组成:

BasicCAN和FullCAN接收

CanIf区分BasicCAN和FullCAN处理,以激活软件接受过滤。
用于FullCAN操作的CAN邮箱(硬件对象)仅允许发送或接收单个CanId。 因此,一个硬件对象的BasicCAN操作使得能够发送或接收一系列CanId。
用于配置的BasicCAN接收的硬件接收对象能够接收一系列的CanId,这些CanId通过其硬件接受过滤器。 此范围可能超出此HRH接收的预定义Rx L-PDU列表。

因此,CanIf随后将执行软件过滤以仅传递Rx LPDU的预定义列表
到相应的上层模块。 有关更多详细信息,请参见第7.20节“软件接收过滤器”。

BasicCAN和FullCAN操作之间的主要区别在于需要一种软件接受过滤机制

CanIf将执行软件验收过滤器
从[SWS_CANIF_00469]中获取由回调函数CanIf_RxIndication()传递的HRH

BasicCAN和FullCAN对象可以在单个配置设置中共存。 如果基础CAN控制器提供了多个BasicCAN和FullCAN接收对象,则可以使用。

如果CanIf收到L-PDU(请参阅CanIf_RxIndication()),
它将执行以下比较,以选择在CanIfRxPduCfg中配置的正确接收L-SDU:
1.比较CanIfRxPduCanId与传递的Mailbox-> CanId
(Can_IdType)排除两个最高有效位
2.将CanIfRxPduCanIdType与传递的Mailbox-> CanId(Can_IdType)的两个最高有效位进行比较

在同一CAN网络上同时混合使用。 如果已使用配置参数CANIF_TXPDU_CANIDTYPE(参见ECUC_CanIf_00590)为BasicCAN或ExtendedCAN操作分别配置了BasicCAN / FullCAN硬件对象,则可以完成混合模式操作;对于混合模式操作,则可以使用软件接受过滤器算法(请参见第7.20节“软件”)。 接收过滤器”)必须能够处理两种类型的CanId。

EcuM调用CanIf函数CanIf_Init()来初始化整个CanIf(请参阅[SWS_CANIF_00001])。在初始化过程中,将初始化所有全局变量和数据结构,包括标志和缓冲区。 EcuM执行初始化
通过分别调用CanDrvs和CanTrcvs的相应初始化服务(请参阅[1]和[2,CAN收发器驱动程序规范])。
CanIf期望CAN控制器保持在STOPPED模式,如初始化过程完成后的上电复位之后。在此模式下,CanIf和CanDrv无法发送或接收CAN L-PDU(请参阅[SWS_CANIF_00001])。
如果需要在运行时重新初始化整个CAN模块,则EcuM必须调用CAN接口模块的API服务CanIf_SetControllerMode()来调用CanSm(请参阅[3])以启动所需的CAN控制器状态转换。
CanIf将来自CanSm的调用映射到相应的CanDrv的调用(请参见8.6.3

CanIf的传输请求函数CanIf_Transmit()([SWS_CANIF_00005])是上层在CAN网络上传输L-PDU的通用接口。 上层
通讯层模块仅通过CanIf服务启动传输,而无需直接访问CanDrv。 如果CanDrv可以将L-PDU数据写入CAN硬件发送对象,则启动的发送请求成功完成。
上层模块使用API服务CanIf_Transmit()发起传输请求(请参见第8.3.6节“ CanIf_Transmit”)。
CanIf在调用serviceCanIf_Transmit()时对L-PDU传输执行以下操作:
1.检查,CanIf的初始化状态
2.识别CanDrv(仅当使用多个CanDrv时)
3.确定访问CAN硬件发送对象的HTH
4.调用CanDrv的Can_Write()

如果传输请求服务CanIf_Transmit()返回E_OK,则传输成功完成。 如果请求通过PDU发送L-PDU

通道模式(请参见第7.19.2节“ PDU通道模式”),等于CANIF_OFFLINE,CanIf应向DET的Det_ReportRuntimeError()服务报告运行时错误代码CANIF_E_STOPPED,而CanIf_Transmit()应返回E_NOT_OK。

2.1 传输数据流

2.2 传输缓冲

在CanIf的范围内,传输过程以对CanIf_Transmit()的调用开始,并以上层模块的回调服务<User_TxConfirmation>()的调用结束。

在发送过程中,CanIf,CanDrv和CAN Mailbox应当将要发送的L-PDU仅在一个位置存储一次。 根据传输方法,这些是:
1.CAN硬件发送对象或
2.如果启用了发送缓冲,则CanIf内的发送L-PDU缓冲区

对于触发的传输,CanIf仅必须存储给定L-PDU的传输请求,而不存储其数据。 当HTH空闲时(再次),将通过触发发送功能及时获取数据。 请求发送的单个Tx L-PDU,
不得存储两次。 此行为对应于CAN网络上常规通信的常规方式。
如果启用了发送缓冲,则如果CanDrv在发送请求时拒绝了Canx发送L-PDU缓冲区(CanIfBufferCfg),则CanIf会将Tx L-PDU存储在CanIf发送L-PDU缓冲区(CanIfBufferCfg)中。
基本上,CanIf中用于缓冲Tx L-PDU的整个缓冲区由一个或多个CanIfBufferCfg组成(请参见CanIfBufferCfg)。 每个CanIfBufferCfg分配给一个或多个专用的CanIfBufferHthRef(请参见CanIfBuffer-HthRef),并且可以配置为缓冲一个或多个Tx L-PDU。 但是,如上所述,每个Tx L-PDU只能缓冲一个CanIfBufferCfg总量。

在L-PDU传输期间CanIf的行为不同,是否在相应的Tx L-PDU的配置设置中启用了传输缓冲。如果禁用了传输缓冲,并且对CanDrv的传输请求失败(使用CAN控制器邮箱,BasicCAN),则L-PDU不会复制到CAN控制器的
邮箱和CanIf_Transmit()返回值E_NOT_OK。如果启用了发送缓冲并且发送到CanDrv的请求失败,则取决于CanIfTxBuffer配置,L-PDU可以存储在CanIfTxBuffer中。在这种情况下,尽管无法执行传输,API CanIf_Transmit()返回值E_OK。在这种情况下,CanIf负责L-PDU的出色传输
通过CanIf_TxConfirmation()回调,上层无需重试传输请求。
可以完全独立于此ECU的CAN网络描述文件中定义的已使用发送L-PDU的数量来配置可用的发送CanIf Tx L-PDU缓冲区的数量。
根据[SWS_CANIF_00835],Tx L-PDU通过CanIfBufferCfg配置容器(请参见CanIfBufferCfg)引用HTH。如果也不需要发送缓冲,则这是有效的。在这种情况下,必须将Can-IfBufferCfg的缓冲区大小(请参见CanIfBufferSize)设置为0。然后,CanIfBufferCfg配置容器仅用于引用HTH。

2.3 缓冲特性

CanIfTxPduBufferRef,CanIfBufferCfg,CanIfBufferHthRef和CanIf-
BufferSize描述可能的CanIfBufferCfg配置

2.3.1 L-PDU在发送L-PDU缓冲区中的存储

如果CanDrv在调用Can_Write()的过程中返回CAN_BUSY(请参见[SWS_CANIF_00381]),则CanIf仅尝试在发送L-PDU缓冲区中存储新的发送L-PDU或其发送请求。

CanIf必须支持基本的CAN L-PDU的缓冲-
如果启用了CanIf(如果参数CanIfPublicTxBuffering)中的CAN传输

对于动态发送L-PDU,CanId也必须存储在CanIfTxBuffer中。

如果启用了传输缓冲(请参阅[SWS_CANIF_00063])
如果配置为直接传输的PDU的Can_Write()调用以CAN_BUSY返回,则CanIf将检查是否有可能在CanIfTxBuffer中缓冲请求通过Can_Write()发送的CanIf Tx L-PDU。

当Can_Write()的调用以CAN_BUSY返回时,CanDrv拒绝了请求的L-PDU传输(请参见[1]),因为在传输请求(Tx请求)时没有可用的可用硬件对象

如果拒绝的数据长度超过配置的大小,则CanIf
应:
1.缓冲配置的数据量并丢弃其余数据
2.并将运行时错误代码CANIF_E_DATA_LENGTH_MISMATCH报告给DET的Det_ReportRuntimeError()服务。

如果启用了传输缓冲(请参阅[SWS_CANIF_00063])
如果为触发传输配置的PDU的Can_Write()调用返回CAN_BUSY,则CanIf将检查是否有可能在CanIfTxBuffer中缓冲请求通过Can_Write()发送的传输请求。

2.3.2 清除发送L-PDU缓冲区

2.3.3 发送L-PDU缓冲区的数据完整性

CanIf应当防止同时访问发送L-PDU和发送请求的发送L-PDU缓冲区。
(SRS_Can_01114)这可以通过使用BSW Scheduler中定义的互斥区域来实现。
这些专属区域可以例如 配置为在进入独占区时将禁用所有中断。 来自BSW Scheduler模块的相应服务是SchM_Enter_CanIf()和SchM_Exit_CanIf()。
原理:对于[SWS_CANIF_00033]:始终不能避免对发送L-PDU缓冲区的抢占式访问。 这样的发送L-PDU缓冲区访问(例如存储新的L-PDU或删除发送的L-PDU)可能会抢先发生

2.3.4 发送确认

如果先前的发送请求成功完成,则CanDrv通过调用CanIf_TxConfirmation()将其通知CanIf。

当回调通知时CanIf_TxConfirmation()
调用时,CanIf将识别上层通信层
(请参阅[SWS_CANIF_00414]),该链接已成功传输的L-PDU,并应通过调用CanIf的传输确认服务<User_TxConfirmation>(E_OK)通知已执行的传输(请参阅第7.12节“传输
确认”)。

回调服务<User_TxConfirmation>()由通知的上层模块实现。
可以以某种方式设计或配置上层通信层模块,可以使用针对不同L-PDU或L-PDU组的单个或多个回调服务来处理传输确认。 CanIf在对相应L-PDU传输请求的传输确认时调用所有这些服务。 发送L-PDU
使您能够分派与目标上层模块相关的不同确认服务。 该分配是在组态期间静态进行的。 一个发送L-PDU只能分配给一个发送确认回叫服务。 请参考第8.6.3.2小节“ <User_TxConfirmation>”。

2.4 接收数据流

根据AUTOSAR基本软件体系结构,将在上层通信堆栈(即AUTOSAR COM,CanNm,CanTp,DCM)中评估和处理接收到的数据。 这意味着上层模块可能无法使用(即
(更改)CanDrv(Rx)的缓冲区,也不能访问CanIf(Tx)的缓冲区。 CanIf仅在以下情况下在接收路径中提供内部缓冲:
CANIF_PUBLIC_READRXPDU_DATA_API(请参阅ECUC_CanIf_00607)设置为TRUE(请参阅第7.15节)。 Tx缓冲在第7.11节中介绍,动态L-PDU在第7.4节中介绍。
在新接收到L-PDU的情况下,CanDrv调用CanIf的CanIf_RxIndication()(请参阅[SWS_CANIF_00006])。 组织对L-PDU特定数据的访问
通过这些参数:
1.硬件接收句柄(HRH)
2.收到的CAN标识符(CanId)
3.接收数据长度
4.参考收到的L-PDU

接收到的L-PDU取决于硬件(半字节和字节顺序,访问类型),并分配给通信系统中的最低层-CanDrv。 HRH用作使用L-PDU的

CanDrv和上层模块之间的链接。 HRH标识一个CAN硬件接收对象,在该对象中接收到新的CAN L-PDU。
在CanDrv对接收到的L-PDU进行指示之后(调用CanIf_RxIndication()),CanIf将按照7.14接收指示中所述进行。

CanIf无法识别CanDrv是使用临时缓冲还是直接硬件访问。 它期望在CanIf_RxIndication()的调用中归一化的L-PDU数据。

接收到的L-PDU取决于硬件(半字节和字节顺序,访问类型),并分配给通信系统中的最低层-CanDrv。 HRH用作使用

L-PDU的CanDrv和上层模块之间的链接。 HRH标识一个CAN硬件接收对象,在该对象中接收到新的CAN L-PDU。
在CanDrv对接收到的L-PDU进行指示之后(调用CanIf_RxIndication()),CanIf将按照7.14接收指示中所述进行。

CanIf无法识别CanDrv是使用临时缓冲还是直接硬件访问。 它期望在CanIf_RxIndication()的调用中归一化的L-PDU数据。

CAN硬件接收对象被锁定,直到复制到临时或上层模块缓冲区的过程结束为止。 CanIf的CanIf_RxIndication()返回后,将立即释放硬件对象,以避免数据丢失。
CanDrv,CanIf和属于接收的L-PDU的上层模块访问相同的临时中间缓冲区,该缓冲区可以位于CAN控制器的CAN硬件接收对象中,也可以作为CanDrv中的临时缓冲区

2.5 CAN Controller Mode

CanIf提供用于控制由底层CanDrv表示的所有受支持的CAN控制器的通信模式的服务。 这意味着所有CAN控制器都由相应提供的API服务控制,以请求和读取当前控制器模式。
通过调用CanIf_SetControllerMode()服务,可以在上层请求时更改CAN控制器的状态。 CanIf通过CanDrv API将请求传递给寻址的CAN控制器。

对通过一个CAN网络连接的所有CAN控制器进行一致的管理是CanSm的任务。 这样,CanSm负责将一个CAN网络的所有CAN控制器顺序设置为睡眠模式或唤醒它们。
CanIf通过调用函数来接受每个状态转换请求
CanIf_SetControllerMode()或CanIf_ControllerBusOff()。 CanIf不能确定所请求的CAN控制器的模式转换是否有效。 CanIf仅通过获取当前模式并执行请求的模式转换来与CanDrv交互。
与网络相关的状态机在CanSm中实现。 请参阅[3]。 CanIf仅存储请求的模式并执行请求的转换。
提示:作为一种优化措施,以避免频繁向CanDrv请求内部
使用CanIf_ControllerModeIndication()指示的最后一个状态,并
Can_GetControllerMode()可以按控制器存储。
提示:必须考虑到,不仅CanSm能够请求更改CAN控制器模式。

 2.5.1 CAN Controller Operation Modes

根据CanSm要求的操作模式,CanIf转发请求的CanDrv。
[SWS_CANIF_00677] d如果ControllerId引用的控制器模式处于CAN_CS_STOPPED状态,并且如果CanIf_Transmit()调用中的PduIdType参数已分配给该CAN控制器,则CanIf_Transmit()的调用不会导致Can_Write( )(请参阅[SWS_CANIF_00317])并返回E_NOT_OK。
[SWS_CANIF_00485] d如果ControllerId引用的控制器模式进入状态CAN_CS_STOPPED,则CanIf将清除分配给相应的CAN Controller的CanIf发送缓冲区。 C()
[SWS_CANIF_00739] d如果ControllerId引用的控制器模式进入状态CAN_CS_STOPPED,则CanIf应通过为分配给该CAN控制器的每个未完成的TxConfirmation调用<User_TxConfirmation>(id,E_NOT_OK)来通知相应的上层模块有关传输失败的信息。如果启用了CanIfPublicTxConfirmPollingSupport,则CanIf还应清除有关TxConfirmation的信息(参见[SWS_CANIF_00740])。
注意:这确保了对于每个PDU,应通过
CanIf_Transmit(),将调用正或负<User_TxConfirmation>()。

2.5.2 控制器模式转换

向CAN控制器发送状态更改请求的API会通过回调服务以异步方式进行异步通知。根据CAN控制器硬件中转换请求的设置,异步地发生真正的到请求模式的转换。要求睡眠转换CAN_CS_SLEEP。成功更改后,例如CAN_CS_SLEEP模式下CanDrv调用函数CanIf_ControllerModeIndication()和CanIf
依次调用函数<User_ControllerModeIndication>()。如果CAN转换非常快,则可以在CanIf_SetControllerMode()期间调用CanIf_ControllerModeIndication()。这是特定于实现的。
上层模块必须跟踪CAN控制器的不成功或没有模式转换。模式转换CAN_CS_STARTED和CAN_CS_STOPPED为
对待类似。
CanIf的上层模块可以通过以下方式轮询当前的控制器模式
CanIf_GetControllerMode()。
并非所有类型的CAN控制器都支持睡眠和唤醒模式。然后,这些驱动程序由CanDrv封装,方法是通过其接口提供独立于硬件的操作模式,而该模式必须由CanIf管理。注意:在从CAN_CS_STOPPED到CAN_CS_SLEEP的过渡期间,可能
CAN控制器可能会向ECU集成代码指示唤醒中断。
CanIf区分内部启动的CAN控制器唤醒请求(内部请求)和网络唤醒请求(外部请求)。内部请求是通过调用CanIf函数CanIf_SetControllerMode(ControllerId,
CAN_CS_STARTED),这是一个内部异步请求。外部请求是CAN控制器事件,由CanDrv或CanTrcv通知给ECU集成
码。有关详细信息,请参见文档[13]的“ CAN唤醒序列”一章中的相应UML图。

2.5.3 唤醒

ECU仅在将CAN控制器和CAN收发器设置为某种“监听唤醒”模式的情况下,才支持通过CAN网络进行唤醒,而与所使用的唤醒方法无关(直接与CAN控制器或CAN收发器有关)。

这通常是一种睡眠模式,其中通常的通信被禁用。 只有此模式才能确保CAN控制器停止。 因此,可以使能唤醒中断。

2.5.4 唤醒检测

如果启用了唤醒支持(请参见[SWS_CANIF_00180]),则集成代码将CanIf通知服务CanIf_CheckWakeup()检测到的CAN唤醒(请参见[13]的CAN唤醒序列)。
如果发生CAN总线“唤醒”事件,则可以在执行EcuM_CheckWakeup(WakeupSource)的过程中调用函数CanIf_CheckWakeup(WakeupSource)(请参阅EcuM的唤醒序列图)。 CanIf依次通过对CanDrvs中的EcuMWakeupSource的配置输入引用进行检查,必须检查哪个CanDrvs。 CanIf通过引用CanIfCtrlCanCtrlRef(请参阅ECUC_CanIf_00636)获取此信息。
被称为“通信服务”的通信服务属于配置期间定义的服务(请参阅ECUC_CanIf_00250)。 这样,EcuM和CanSm都可以更改CAN控制器状态并控制与BusOff恢复或唤醒过程有关的系统行为。

2.5.5 唤醒确认

注意:当CAN控制器/ CAN收发器检测到总线唤醒事件时,这将直接通知ECU状态管理器。 如果需要验证此类唤醒事件,则EcuM(或CDD)会打开相应的CAN控制器(CanIf_SetControllerMode())和CAN收发器

注意:在将PDU通道模式设置为CANIF_ONLINE或CANIF_TX_OFFLINE之后,CanIf会将接收到的消息通知上层模块。
因此,如果需要唤醒验证,则必须不将PDU通道模式设置为CANIF_ONLINE或CANIF_TX_OFFLINE。 注意:根据[SWS_CAN_00411]和CAN控制器状态图(请参见[1]),不允许直接从模式CAN_CS_SLEEP转换为CAN_CS_STARTED。

2.6 PDU通道模式控制

2.6.1 PDU通道组

每个L-PDU分配给一个专用的物理CAN通道,该通道连接到一个CAN控制器和一个CAN网络。 通过这种方式,

可以从处理逻辑上单个L-PDU通道组的角度来控制属于一个物理通道的所有L-PDU。这些逻辑组代表连接到一个ECU的所有L-PDU

一个底层的CAN网络。
下面的图7.7显示了L-PDU信道组的一种可能用法及其与上层和/或网络的关系。
L-PDU只能分配给一个通道组。
诸如PduR或网络管理之类的典型用户负责控制PDU操作模式

2.6.2 PDU通道模式

CanIf提供服务CanIf_SetPduMode()和CanIf_GetPduMode()来
防止处理
1,所有发送属于一个逻辑信道的L-PDU
2.所有发送L-PDU和接收属于一个逻辑信道的L-PDU。
仅在相应控制器的情况下才允许更改PDU通道模式
模式等于CAN_CS_STARTED(请参阅[SWS_CANIF_00874])。
当CANIF_ONLINE和CANIF_OFFLINE影响整个通讯时,
PDU通道模式CANIF_TX_OFFLINE和CANIF_TX_OFFLINE_ACTIVE启用/
分别禁用传输路径。
CanIf通过服务提供有关当前PDU通道模式的信息
CanIf_GetPduMode()。

2.6.2.1 CANIF_OFFLINE
2.6.2.1 CANIF_ONLINE
2.6.2.1 CANIF_OFFLINE_ACTIVE

2.7 Software receive filter

并非所有可能通过硬件验收过滤器并因此在BasicCAN硬件对象中成功接收的L-PDU都被定义为接收L-PDU,因此需要从相应的ECU接收。 CanIf可以选择滤除这些LPDU,并禁止进一步的软件处理。
提供了某些软件过滤器算法来优化软件过滤器的运行时间。 软件过滤器机制的方法是从当前正在处理的HRH和CanId中找出相应的L-PDU。 找到L-PDU后,CanIf接受接收并允许上层直接访问L-SDU信息。

2.7.1 软件过滤的概念

配置工具处理有关硬件验收筛选器设置的信息。
最重要的设置是L-PDU硬件对象的数量及其范围。 出口范围定义了哪些接收L-PDU属于每个硬件接收对象。 以下定义是可能的:
1.单个接收L-PDU(FullCAN接收),
2.接收L-PDU列表或
3.可以将一个或多个接收L-PDU范围链接到硬件接收
对象(BasicCAN接收)。

每个CanId的可配置范围
(请参阅[SWS_CANIF_00645]),该软件应通过软件接收过滤器,并且可以通过以下方式配置为标准CAN ID或扩展CAN ID:
CANIF_HRHRANGE_CANIDTYPE(请参阅ECUC_CanIf_00644)。 C()
提供接收L-PDU作为从通信矩阵静态生成的恒定结构。它们根据相应的硬件接受筛选器进行排列,因此每个硬件只有一个接收CanId的列表
接收对象(HRH)。如果使用了多个BasicCAN对象,则对应的列表可以由HRH派生。随后的过滤是通过将多个CanId与新接收的CanId进行比较来搜索一个列表。在命中的情况下,接收的L-PDU从找到的CanId派生。
[SWS_CANIF_00030] d如果已配置为接收HRH中接收到的L-PDU的CanId,则CanIf将接受该L-PDU,并且软件过滤算法将从发现的CanId中得出相应的接收L-PDU。

2.7.2 Data Length Check

将接收到的数据长度值与接收到的L-PDU的已配置数据长度值进行比较。 配置的数据长度值应从该L-PDU内部使用的字节大小中得出。 所配置的数据长度值可能不一定是在CAN通信矩阵中定义并由该CAN L-PDU的发送方使用的数据长度值。

CanIf将接受所有收到的L-PDU
(请参见[SWS_CANIF_00390]),并且数据长度值等于或大于配置的数据长度值

如果数据长度检查拒绝收到的LPDU
(请参见[SWS_CANIF_00026]),CanIf将报告运行时错误代码
CANIF_E_INVALID_DATA_LENGTH到Det_ReportRuntimeError()服务
DET模块的名称。

Published by

风君子

独自遨游何稽首 揭天掀地慰生平

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注