LIN STACK的lin_timeout_handle周期问题
-
想问一下,接口lin_timeout_handle的周期500us可以改慢一点吗?
-
你这个是那个芯片?想改慢的目的是什么呢?降低CPU的负载率吗?
-
limanjiang 在 LIN STACK的lin_timeout_handle周期问题 中说:
你这个是那个芯片?想改慢的目的是什么呢?降低CPU的负载率吗?
当前是MC0在用,后续MD1也要用的。
是的,为了降低负载。 -
我的理解是可以的,但是需要做下匹配:
以master 为例:本意是每个周期递减一个时基

需要再调用的周期里匹配周期时间参数:
-
limanjiang 在 LIN STACK的lin_timeout_handle周期问题 中说:
我的理解是可以的,但是需要做下匹配:
以master 为例:本意是每个周期递减一个时基

需要再调用的周期里匹配周期时间参数:
好的,我们试一下,谢谢你!
-
limanjiang 在 LIN STACK的lin_timeout_handle周期问题 中说:
我的理解是可以的,但是需要做下匹配:
以master 为例:本意是每个周期递减一个时基

需要再调用的周期里匹配周期时间参数:
你好,我测试了下,超时时间改为1ms对我们当前功能(休眠与唤醒)没有影响。

有别的问题,就是上图两段代码中的数字500,超时任务的周期修改后是否会导致这两个接口功能出现异常?而这两个接口在LIN STACK中是有被使用的。 -
这两个接口也需要同步修改的,会影响下面两个计算的

-
limanjiang 在 LIN STACK的lin_timeout_handle周期问题 中说:
这两个接口也需要同步修改的,会影响下面两个计算的

你好,我们后续测试发现新的问题。针对主机厂需求:LIN总线有报文的话,设备就不能休眠。

如上图,数字1处显示LIN上有0x02的报文正在发。由于此报文不是我们节点需要接收的报文,函数lin_get_frame_by_id返回0(NULL)。
导致上图数字1的接口进不去,使得上图数字2处的赋值语句不会执行。
最终结果就是接口l_ifc_read_status返回的里面并没有LIN_IFC_STATUS_BUS_ACTIVITY。我们是使用此接口判断LIN是否有数据的。是否有别的办法来判断LIN总线是否有数据呢?
-
可以尝试获取LIN 底层节点状态来判断试试:

可以通过如下接口函数获取

-
limanjiang 在 LIN STACK的lin_timeout_handle周期问题 中说:
可以尝试获取LIN 底层节点状态来判断试试:

可以通过如下接口函数获取


这个接口不太行的,见上图。数字1接口1ms周期进来,处理完Callback后就会将状态切换到Idle了。实测了下,也确实符合预期,CANOE一直发送数据,在1ms任务中一直调用这个接口判断值> LIN_NODE_STATE_IDLE,如果为真,计数值会+1;如果为假,计数值会-1。最终,计数值是0。系统会进入休眠。
-
感觉还需要设计一个超时机制才可以,总线数据一直再发的话这个这个LIN 底层的状态机一直是在变化的,没有数据的话应该一直是IDLE才对;如果一监测到IDLE 直接休眠也是不合理的,因为这也只是一个临时状态,只有一直是IDLE持续一段时间之后才能认为总线没有数据。我觉得是不是可以设计一个计数器,如果一直是IDLE 就递增,监测到其他状态就清0;如果一直IDLE 到某一个设置的阈值之后,认为总线没有数据了,可以进休眠。
-
limanjiang 在 LIN STACK的lin_timeout_handle周期问题 中说:
感觉还需要设计一个超时机制才可以,总线数据一直再发的话这个这个LIN 底层的状态机一直是在变化的,没有数据的话应该一直是IDLE才对;如果一监测到IDLE 直接休眠也是不合理的,因为这也只是一个临时状态,只有一直是IDLE持续一段时间之后才能认为总线没有数据。我觉得是不是可以设计一个计数器,如果一直是IDLE 就递增,监测到其他状态就清0;如果一直IDLE 到某一个设置的阈值之后,认为总线没有数据了,可以进休眠。
是的。现在软件逻辑是10ms判断一次LIN的状态(不论是哪个接口获取)。如果接口返回的是LIN有活动,计数器就会自增(初始化时计数器初始值给的10);如果没活动,就自减。在应用层通过接口来获取计数器是否为0,如果是0就是LIN总线休眠了,设备就可以走下电流程。
现在测试下来两种方法全都不行,设备最终都会休眠。 -


问一下,这个busActive的设计想法是否为YCT的LIN STACK对应HW instance是否活动? -
yifeng_xie 你当前的计数器只要在一段时间内监测到的IDLE状态总数大于(非IDLE状态+10)就会进休眠了,有一定的随机性,触发的概率看起来也很高;重新设计一下计数器的逻辑有用没?LIN_STACK 接口因为有ID过滤所以不满足很正常,底层接口不区分ID,但是如果周期性读取也有一定随机性,但是我觉得如果读取间隔小,次数多(比如原来10ms,CNT10,最小监测总线空闲周期是100ms; 如果在同样的最小有效监测周期100ms,改成1ms 监测一次,监测100次(次数越多越准)都是IDLE,只要有一次不是就重新计数,条件会更严苛一些)可以在一定程度上保证准确度。
-
limanjiang 我试过,一次加10或者20,应用层去判断计数器是否为0,也没用的。debounce策略最终还是需要底层能支撑起来。

这个busActive的设计想法跟我说的一样嘛?如果一样的话,LIN STACK协议栈是有问题的。 -
Frankie 在 LIN STACK的lin_timeout_handle周期问题 中说:
这个是lin stack的bug,下个版本修复
好的。
另外曾工,我看了下我这样改也有bug。如果busActive=true代表总线busy,那么只增加我改的那几句还不够的,因为l_lfx_tx/l_lfx_rx这两个函数不是所有条件都会设置true。实际进入这个case下,总线已经busy了。 -
Frankie 在 LIN STACK的lin_timeout_handle周期问题 中说:
这个是lin stack的bug,下个版本修复
曾工,现在有针对这个bug的临时方案吗?我们可以先手动改一下
-
快速上手云途开发生态
发帖前请查看
帮助改进和优化YT CONFIG TOOL,有机会抽取YTM32B1ME0 EVB哦...
。修改的方法就是你 #15 楼发的帖子这么改