QA1:CAN报文发送,有优先级吗?
答 :有。以英飞凌tc3xx系列为例,MCMCAN模块有多个硬件发送缓冲区,也就是说同一时刻可以缓存多个待发送的报文,这些报文放入待发送的缓冲区以后,会置位发送Pending标志,等待发送,谁先发送呢?在回答这个问题之前,我们先说待发送的报文在硬件缓存区中的存储方式:Dedicated Tx Buffers 、Tx FIFO、 Tx Queue。
对于Dedicated Tx Buffers与 Tx Queue两种存储方式,根据lowest Message ID原则发送,即:发送的CanID数值越小,优先级越高。具体发送顺序示例如下:
对于Tx FIFO存储方式,报文的发送顺序由进入FIFO缓存区的先后顺序决定,即:先进先出,具体发送顺序如下:
如果使用Dedicated Tx Buffers与 Tx Queue两种存储方式,优先级低的报文(比如:网络管理报文、诊断报文、标定报文等,优先级比应用报文低),是不是永远得不到发送了?不是,我们要清楚:发送的硬件缓存区不止一个,而是多个(比如:tc397有32个发送缓冲区),足以在某一时刻缓存多个待发送的报文。是否存在某一时刻(如下t1),发送报文的个数超过硬件缓存区个数?这种可能性是存在的,这也是为什么会有发送报文丢帧的原因。
为了避免发送丢帧或者周期性报文抖动问题,我们可以将相同周期性报文的发送做一个Offset处理, 避免周期性相同的报文以同一个基准时间计时 。
比如:通信启动后,周期性报文Msg01(周期10ms)在t0时刻开始周期性发送;而周期性报文Msg02(周期10ms)在t1时刻开始周期性发送,这样即可避免两者在某一时刻的发送重叠,如下所示:
QA2:Tx FIFO发送方式可能引发的问题有什么?
答: 对于CAN报文,使用FIFO方式发送,我能想到的场景:诊断中,发送诊断指令使用FIFO缓存,保证诊断指令请求的顺序。不知道大家在何种情况下使用过Tx FIFO,还请大家给普及。
这里思考到了一种工况,可能会因使用FIFO发送方式,导致报文的发送延迟,具体如下所示:
假设:CAN BUS上有两个节点:ECU1::CAN1和ECU2::CAN1,ECU1::CAN1使用Tx FIFO缓存待发送数据,ECU2::CAN1使用Dedicated Tx Buffers方式缓存待发送数据。
在某一时刻,ECU1::CAN1的Buffer Index0待发送报文的CAN ID = 0x30,ECU2::CAN1待发送的6个报文的CAN ID <0x30,所以,每次总线仲裁,都会优先发送ECU2::CAN1缓存的报文,而ECU1::CAN1因为总线仲裁失败,导致ECU1::CAN1 FIFO中的高优先级报文无法及时发送出去,如下所示:
所以,在使用Tx FIFO方式时,需要注意此工况。
QA3:程序应先处理发送报文还是应该先处理接收报文?
答 :TBD。为什么是未定义呢?在实际的项目开发中,先处理Rx报文还是先处理Tx报文确实没有明确规定,在项目不出问题之前,没有人会留意两者的处理顺序。
这里我们讨论一下先处理Rx Msg,再处理Tx Msg的情况,实质就是讨论Task中,Com_MainFunctionRx()/Com_MainFunctionTx()的处理顺序。
假设:Com_MainFunctionRx()/Com_MainFunctionTx()均在5ms的Task中,且先处理Com_MainFunctionRx(),再处理Com_MainFunctionTx(),如果此节点收/发的报文数量不多,任务在规定的时间内处理完(t1时刻之前),不会引发问题,如下所示:
如果当前节点接收的报文数量较多,Com_MainFunctionRx()消耗了任务处理的大部分时间,导致Com_MainFunctionTx()处理被Delay,可能会导致本节点发送报文的周期抖动问题,比如:本来10ms的Tx Msg,由于延迟导致Tx Msg>10ms + 容差值,假设容差值±10%(1ms),比如:实际Tx Msg周期13ms,导致通信出问题。
对于一个节点,接收报文数量存在不确定性,比如:接收的报文类型如果有事件性应用报文、高周期应用报文(如:1ms周期性应用报文)等。
那么Com_MainFunctionRx()的处理时间就会存在一定的不确定性。相对于接收报文,节点发送报文的数量相对比较确定,发送所消耗的时间也比较确定,所以,从处理顺序上来说, 先处理确定的发送再处理不确定的发送比较合理 ,这样可以确保发送报文的时间。
而对于接收,即使超一点时间,如果Task没有超过Deadline Time,对程序的运行也不会造成太大影响。
再者,对于CAN报文,发送报文还需要进行总线仲裁,仲裁失败也会存在一定的延时(参考QA2)。
注意 :上述假设OS所使用的基准计数器是可信的,即:基础计数器准确,一般由GPT或者STM驱动。
QA4:周期型报文Offset的作用是啥?
答: 降低同一时刻,多个发送报文的Burst Send问题。这个问题属于QA1的延申。
一个节点,发送的报文类型可以有多种(QA1提到)。其中,节点外发的应用报文从几个到几十个不等。应用报文又分为事件型、周期型、混合型。以周期型应用报文为例,可能有5ms、10ms、20ms、50ms等周期。
如果本节点外发的报文数量较大,在某一时刻会存在大量并发请求。比如:MsgA Cycle =5ms,MsgB Cycle = 10ms,MsgC Cycle = 10ms,如果MsgA的发送时刻为5ms、10ms、15ms、20ms、25ms、30ms.....MsgB、MsgC的发送时刻为10ms、20ms、30ms.....,在time=10ms、time=30ms......等时刻,MsgA 、MsgB、MsgC会同时请求发送,节点要发送的报文数量越多,某一时刻(如下图time = 10ms 时刻),请求发送的报文数量可能就越多。
在某一时刻,发送报文数量过多会带来什么问题呢?这就是QA3中的问题,会使得某个发送报文发送延迟,使得其发送周期出现抖动,即:超过该周期报文的允许误差值,一般来说,≤100ms的周期性应用报文允许的偏差为3%,>100ms的周期性应用报文允许的偏差为1%(看OEM要求)。
既然应用报文会Burst Send,如何降低这种并发请求行为呢? 偏移相同周期报文的发送时机 ,比如:MsgBOffset 5 ms,MsgC Offset 10ms,这样两者的发送就不会重叠,如下所示:
那偏移不同周期的应用报文有用吗?因为周期性报文发送取决于Com_MainFunctionTx()所在任务周期,Offset Value = n * Cycle(n为非负整数,Cycle指Com_MainFunctionTx()的任务周期),所以,Offset Value是Com_MainFunctionTx()任务周期的整数倍。
这样,即使设置MsgA、MsgB的Offset Value不同,也不能避免某一时刻(如:time = 10ms时刻),两者的并发请求,如下所示:
审核编辑:刘清
-
CAN
+关注
关注
57文章
2714浏览量
463328 -
fifo
+关注
关注
3文章
387浏览量
43533 -
STM
+关注
关注
1文章
555浏览量
42368
发布评论请先 登录
相关推荐
评论