客戶量産開發闆遇到不明重新開機、中斷回調避坑。
今天上班一大早，客戶發來一個消息說開發闆有bug，就是按鍵調用TTS播放語音的時候會直接重新開機，還是挺緊張的，重新開機就是最嚴重的bug了。而且這個客戶買了幾百套闆子，已經投入使用了，如果不查出來就搞大了。馬上用開發闆寫了一個案例進行複現，看一下效果。果然一按鍵馬上就重新開機了，還沒有播放出來，這就是重新開機。
關鍵是它重新開機原因是normal，正常的，一般的重新開機會有通過原因來提示，這個normal就不好查了。因為正常上電還有複位的時候重新開機原因就是normal。是以我懷疑了他是不是這個按鍵按的過程中導緻複位的引腳有電平的變化，導緻複位了。
萬用表來測一下，拿表測了一下，正常的複位腳沒有變化，說明不是這個問題。然後又試了單獨寫一個按鍵沒有問題，單獨播放TTS語音也是沒有問題的，就是它們一組合的時候就會重新開機。還是沒有懷疑底層代碼的bug，還是在應用層先找找原因。
反複看了看這幾行代碼，發現有一個可疑的地方，發現TTS播放的函數直接放到了按鍵回調裡面，按鍵回調函數直接就進行TTS的一些操作了。這樣用其實是很不規範的，于是就做了一個小操作，最終把這個問題解決了。
我是這樣改的，把TTS播放的單獨做了函數，然後中斷裡面就直接放了一個标志位，然後在main主邏輯裡面去判斷标志位如果到了再去播放它，再下載下傳這個程式看一下。打開視窗lo串，按一下按鍵優先級測試，可以用python程式設計，haas506開發闆，可以了。順便解決了這個問題。
把代碼給客戶發過去之後，那邊也不重新開機了，還好沒有去動底層的一些固件，要不然更新遠端就比較麻煩了。
這裡要提醒大家就是，不管你用python也好，還是C也好，隻要是嵌入式程式設計，那你的中斷回調裡不要做一些太耗時的操作，就立flag就行了。寫代碼并不是說自己寫的爽就行，做産品的穩定性是第一的。怎麼用最簡單、最樸素的方法把産品寫穩定才是最重要的。
