LIN STACK的lin_timeout_handle周期问题
-
limanjiang 在 LIN STACK的lin_timeout_handle周期问题 中说：
你这个是那个芯片？想改慢的目的是什么呢？降低CPU的负载率吗？
当前是MC0在用，后续MD1也要用的。
是的，为了降低负载。 -
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总线是否有数据呢？
-
limanjiang 在 LIN STACK的lin_timeout_handle周期问题 中说：
可以尝试获取LIN 底层节点状态来判断试试：
可以通过如下接口函数获取
这个接口不太行的，见上图。数字1接口1ms周期进来，处理完Callback后就会将状态切换到Idle了。实测了下，也确实符合预期，CANOE一直发送数据，在1ms任务中一直调用这个接口判断值> LIN_NODE_STATE_IDLE，如果为真，计数值会+1；如果为假，计数值会-1。最终，计数值是0。系统会进入休眠。
-
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的临时方案吗？我们可以先手动改一下
-
-
Frankie 在 LIN STACK的lin_timeout_handle周期问题 中说：
关于bus active的定义：
。修改的方法就是你 #15 楼发的帖子这么改曾工，还有一个bug，在l_lfx_tx 和 l_lfx_rx中设置state->frameStatus.busActive=l_true;的时机也有问题。当前，l_lfx_tx 和 l_lfx_rx中驱动返回错误，是不会调用state->frameStatus.busActive = l_true;的。
当进入if(linState->currentEventId==LIN_PID_OK)后，应该就设置state->frameStatus.busActive = l_true;了。此时，一次完整且有效的报文开始事件已经产生，则busActive=true。驱动调度出错也不能设置busActive = false。
所以，代码应该改成下图这样，l_lfx_tx 和 l_lfx_rx中没必要设置state->frameStatus.busActive = l_true;了，只需要记录故障。
快速上手云途开发生态
发帖前请查看
帮助改进和优化YT CONFIG TOOL，有机会抽取YTM32B1ME0 EVB哦...