新闻中心

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

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

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

当年,有东土小释迦美誉的智者大师依法华经开展“一心三观”,创立天台宗,名满天下,隋炀帝拜为帝师,亦引来一位印度高僧前来拜访。几番切磋下来,这位高僧发现智者大师的思想竟然颇合当时并未传入中国的《楞严经》的意旨,而且《楞严经》非常详尽地阐述了智者大师一直非常困惑的六根功德来源的疑虑。高僧走后,智者大师设立拜经台,朝夕遥拜十八载,但由于印度将《楞严经》视为国宝,严禁外传,智者大师直到往生,始终无缘得遇。直到百年之后,印度法师般刺密谛历尽艰辛,把《楞严经》传入中国,后经神秀大师宏传,这部大经方流通于世。说句题外话,这位神秀大师便是禅宗五祖忍和尚座下做出“身是菩提树,心如明镜台,时时勤拂拭,莫使惹尘埃”的偈子,落败于六祖慧能大师从而无缘衣钵的那位上座。

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

  《楞严经》将我们凡夫的这颗心称之为“缘影之心”,就是说,这颗心呐,攀缘于各个“影像”而不知“返闻闻自性,性成无上道”。比方说,洒家近日牙疼之时,一股脑地灌下去火药、止疼药、消炎药之后,依然兀自钻心地疼,洒家这颗心呐,一会儿想到小时候一得着零花钱就买糖吃,悔不当初,一会儿又想到直到大学时才开始隔三差五的刷牙,后悔不迭,一会儿又想到倘若补牙的话,这咽炎恶心也受不了,平白地在要命的牙疼之外更添了几分战战兢兢。可是,倘若真如蕅益大师所说的那样,这些疼痛的感受和杂乱的思想了无自性,虚伪无主,它们“未生无潜处,正生无住处,生已无去处”,据说,善根深厚之人只要回光返照,提出三个问题-“没有牙疼之前这种感受藏在哪里?牙疼之时也不是一味的疼,它疼的时候停在哪里?,等过半天,牙疼过去了,这种感受跑到哪里去了?”,便会对牙疼混不理会了。可是显然,洒家福薄,善根浅,发出这灵魂三问之后,还是被这牙疼搞了个七荤八素,好不痛苦!

  当然,万事都逃不开因果,洒家这次之所以牙疼难忍,还是被产品的缺陷给闹的。说起来也很惭愧,或许是责任心太强,又或许是心理素质太差的缘故,总之,只要洒家操刀的产品一有缺陷,就沉不住气、上火,上火厉害了就牙疼,有时候还牵扯得半边脸疼。要说怪,也只怪自己了吧。

1

  横看成岭侧成峰,远近高低各不同,不识庐山真面目,只缘身在此山中。东坡先生千年之前写就的这首诗很是贴合嵌入式产品的开发和测试情况。

  同一个嵌入式产品让不同的人来测试,往往会得到不同的测试结果,脑路开阔、思维发散的测试人员总能找出其它人发现不了的缺陷。倘若让设计这款产品的开发人员自己来测试,多半是心大眼盲,连半个缺陷也很难测出来的。

  这次,为了在BCM这款产品装车之前尽量消灭所有Bug,领导特意安排了一位责任心极强、经验极其老道的测试人员,对这款BCM进行了各种暴力测试,结果,还真找出来一个隐藏了好久好久的问题,简而言之,就是连续多次按按键,存在间或失灵的现象。

2

  在产品开发阶段,洒家其实也遇到过按键失灵的情况,只不过当时并没有意识到这是一个缺陷,而是想当然地认为是按键按得太轻了,时间按得太短了,遥控钥匙自己过滤掉了这次操作,并没有把遥控命令报文发过来,才导致了这次“失灵”。当然,洒家吃斋念佛,对于臭虫(Bug)也慈悲为怀,不忍痛下杀手,所以就高高举起,轻轻落下,竟这般与这个缺陷擦肩而过了。

  但是,世间所有事,都逃不过认真二字。被我放走的这只臭虫,还是没有逃过我们这位态度认真,手段毒辣的测试人员的魔爪。

  那是一个阳光明媚的午后。入秋的太阳斜穿过云彩那白得耀眼的金边,爬过窗台,洒在我写满沧桑的脸上和皱褶里。我慵懒地斜靠在窗台上,按捺着心中的嘀咕,笑眯眯地看着测试大姐拿着一张带字的纸款款走来。

  测试大姐粉面含春,笑意盈盈,将纸张塞入我手中,丹唇微起:“天雷君,测出问题来了,看看吧,按了50次遥控按键,大概有10次失灵。”

  寥寥数语,干脆利落,洒家不禁虎躯一震,不由得站直了身子。“你确认中间没有触发门锁热保护?要知道,如果10秒内操作10次门锁,BCM会启动对门锁电机的热保护,这时是不响应遥控解闭锁命令的。”

  “当然没有,我也不是第一次测试了,所以特意避开了门锁热保护。”在她那白白脸蛋的衬托下,一双滴溜溜的眼睛里忽然流露中微微的哀怨神情。

  ‘连着操作上50次,你倒是挺有耐心,也亏你想得出来!’

我不禁在心里暗暗佩服,也犯起了嘀咕,‘以前的按键失灵,我怎么就没有当成回事呢?!’

3

  收到测试大姐的反馈后,洒家立马收拾了心情,屡起袖子,架起示波器,测试了起来。果不其然,测试了几十次,示波器上的遥控接收波形好好的,但是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跟着你。



关键词: bug 遥控

评论

技术专区

关闭