新闻中心

EEPW首页 > 牛人业话 > 天灵灵地灵灵 遥控为何会失灵

天灵灵地灵灵 遥控为何会失灵

作者:天雷君时间:2018-11-16来源:电子产品世界收藏

3

本文引用地址:http://www.eepw.com.cn/article/201811/394465.htm

  收到测试大姐的反馈后,洒家立马收拾了心情,屡起袖子,架起示波器,测试了起来。果不其然,测试了几十次,示波器上的接收波形好好的,但是BCM就是没有响应,统计出来的失灵概率为20%左右。

  不消说,肯定是报文接收程序出了问题。为了叙述方便,先简要介绍一下接收程序的设计。

  遥控报文是一串射频位位流,遥控接收程序的目的是从这一串射频位位流中提取遥控命令数据。为了实现这一点,大致需要进行“接收射频位位流”、“解码数据位位流”、“提取数据场数据”、“解密数据”四个步骤。

  其中,射频位到数据位采用了曼彻斯特编码形式,以射频位01表示数字位1,以射频位10表示数字位0,BCM采用上升沿触发中断的方式,根据相邻两个上升沿之间的时间间隔来赋值射频位。BCM根据遥控报文的格式提取出“数据场”中的射频位位流,然后进行曼彻斯特解码,计算出数据位位流,进而提取出字节形式的数据,解密后,提取其中的遥控命令,进而执行相关的闭锁、解锁、寻车等操作。

  显然,肯定是“接收射频位位流”这个步骤出了问题,因为假若是后面三个步骤其中之一出了问题,那就不是偶尔失灵,而是总是失灵的大故障了。

  由于曼彻斯特编码的射频位位流中,相邻两个上升沿的间隔取值只可能为2T、3T、4T,T为射频位位宽。因此,在“接收射频位位流”的具体实现中,BCM根据上升沿时间间隔大小推断出射频位,考虑到上升沿中断触发时刻和中断服务程序之间的延迟,考虑到数据捕捉模块时钟源的精度,在程序里,2T、3T、4T的判断都留了足够的余量,照理说,也不该出问题。

  总之,和往常一样,“设计”上无懈可击,定是“实现”上出了问题。

4

  代码是“实现”“设计”的载体,洒家盯着代码端详半天,实在看不出个所以然,只好付诸调试。笔者开了一个轮转型的大数组,存储在中断服务程序中计算出来的射频位位宽,一番调试,终于看出了一些端倪:

  原来,在一些规整的射频位位宽之后,竟然存在既不是2T、也不是3T和4T的位宽。射频位在这里断了线,后面的数据位肯定不正确,遥控失灵自然也是跑不了的了。笔者多次测试之后,发现了个规律,即这些异常位宽要么是2T-3T之间,要么是3T-4T之间,也不算过于异常。

  看来,在一个数据位周期中(2T),貌似有的上升沿出现得早,有的上升沿出现得晚,既如此,把2T-3T之间的处理为3T,3T-4T之间的处理为4T,就可以补救这种上升沿的错位。

  顺着这种思路,笔者迅速修改了代码,然后热火朝天地测试了起来,果然,失灵的几率大大下降了,测试上50次,只会失灵一两次了。

  ‘也许,这剩下的一两次真的就是被遥控钥匙过滤掉了吧。’历尽劫波的我暗暗想到。不过,为了避免测试大姐再次上门,我决定再多测试几次。洒家怀揣着小小的侥幸心理,一边看着示波器,一边按着按键,一边听着测试台上的门锁动作声音,紧张地再次测试起来。

  都说好事多磨,但是常人实在经受不住一磨再磨,一通操作下来,洒家悲催地发现,这剩下的一两次失灵竟然是真的失灵了!

5

  我斜斜地躺在转椅上,茫然地看着天花板,经过一两天的奋斗,豪气消耗大半,牙齿也开始隐隐作痛了,空空如也的脑袋中兀自循环播放着孙中山先生的临终遗言:革命尚未成功,同志仍需努力!

  ‘要不算了吧,失灵概率2%-3%之间,用户应该是能接受得了的吧?偶尔失灵一下,再多按一下就是了,用户肯定觉察不出来的!’在阳光的照射下,平时肉眼看不见的小灰尘在空中慢慢舞动,‘就像这些灰尘一样,倘若不是太阳这么好,人们怎么能注意到它们的存在呢?’我在心里给自己留好了后路。

  正盘算间,测试大姐爽朗的笑声从身边飘过,只见她一双丹凤三角眼,两弯柳叶吊梢眉,身量苗条,体格风骚。粉面含春威不露,丹唇未启笑先闻,活脱脱一个王熙凤啊!我扪心自问,‘惹得起吗?惹不起!’一念至此,洒家一个激灵,‘对得起用户吗?对不起!’既然如此,走你!继续解决问题!

6

  话不多说,既然问题是由于在一个数据位周期中有的上升沿出现得早,有的上升沿出现得晚而导致的,那么,现在需要搞明白的是,究竟是上升沿确实出现得比预期早或者晚,导致位宽异常,还是由于系统运行期间,上升沿触发时刻和中断服务程序之间的延迟忽高忽低而导致解析出来的位宽出现异常。

  为了确认这一点,笔者开始第一次认真地对着示波器看起遥控报文的波形来,当然,有的看官可能会问了,为什么之前不看这个波形啊?说实在话,我还真的无言以对,反正之前没看过就是了。所幸遥控报文的header部分有上百个数据位0,也很规律,洒家身体前倾,扭着示波器上的时间轴,双目圆睁,看着时间刻度,果然,有的上升沿出现得早,有的上升沿出现得晚,一念至此,笔者悬着的心稍稍放了下来,这说明不是中断服务程序延迟导致的!好心情维持没多久,我这颗小心脏又再次悬了起来,因为,既然是钥匙那端把位宽搞得乱七八糟,BCM这端怎么也解决不了啊!

  日光渐移,透过窗户,将洒家的身影拉得老长。我盯着影子中的大好头颅,挠着头皮,手指翻动,倒像是密宗修行里结的一个个手印。阿弥陀佛加持,菩萨保佑,总得想个解决办法出来!

  我默默翻动着在示波器时间轴上不断游走的波形,目光慢慢从上升沿移动到了下降沿上面,‘上升沿不标准,下降沿是否可能标准呢?’我模模糊糊地想着,同时统计着下降沿之间的时间间隔,刚刚统计了四五个,问题的解决方案就已经向我遥遥招手了。下降沿之间的时间间隔标准多了,我一口气统计了20个,发现报文header部分的波形中相邻下降沿的时间间隔都在标准的2T左右,基本上没有任何误差!

  剩下的事情就简单了,把“接收射频位位流”程序改一改,改成下降沿触发中断,然后相应地把“解码数据位位流”程序改一改,再次测试100次,百发百中!谁能想得到,问题竟这样戏剧般地解决了!故障迅速解决掉了,但是它挥一挥衣袖,这牙疼却不带走,仍然折磨了我一天才慢慢消退。

  事后想来,这跟设计钥匙的厂家编写钥匙程序的方式有着莫大关系,他们的程序可以在射频位的下降沿上保证周期准确性,却无法在上升沿上保证时间精度,倘若反过来,他们的程序能够在上升沿上保证周期准确性,我也就不会遇到钥匙失灵的问题,当然,也就不会有这么有趣的经历了。

  后记

  卤水点豆腐,一物降一物,狮子怕大象,大象怕老鼠。嵌入式产品出了问题,千万不要怕,也不要躲,有Bug才是日常工作的常态,真是没有Bug,日子也会很无聊。正所谓:莫愁前路无知己,总有Bug跟着你。


上一页 1 2 下一页

关键词: bug 遥控

评论


相关推荐

技术专区

关闭