LIN STACK的lin_timeout_handle周期问题
-
问一下，这个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;了，只需要记录故障。
-
yifeng_xie 在 LIN STACK的lin_timeout_handle周期问题 中说：
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;了，只需要记录故障。
补充，l_lfx_tx 和 l_lfx_rx中设置state->frameStatus.busActive = l_true还是需要的，我图上是解决从机问题，主机调度表还是需要走l_lfx_tx 和 l_lfx_rx中的state->frameStatus.busActive = l_true。
快速上手云途开发生态
发帖前请查看
帮助改进和优化YT CONFIG TOOL，有机会抽取YTM32B1ME0 EVB哦...