天靈靈地靈靈 遙控為何會失靈

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跟著你。