接着上回繼續分析公司遺留的問題二分析，問題二就是入網速度慢、入網後概率性的掉線。先普及一下我們入網的流程，因爲不同的網絡有不同的PANID，因此目前入網的方式有三種：1、每個設備出廠時候讀取它的MAC地址，生成二維碼貼在設備上，入網之前用手機掃描一下，把MAC地址導入到網關端，因此嘗試關聯的時候網絡允許其關聯；2、每個設備上做一個NFC標籤，設備可以通過I2C等總線讀取NFC標籤，網關端有一個NFC讀寫器，把設備靠近網關，嘀一下，網關把PANID同步到NFC標籤上，每個設備都會關聯該PANID的網絡；3、網關端有個標誌位，一旦允許加入的時候，所有關聯該網關的設備都允許被加入，一旦標誌位清零，任何設備都加入不進來。以上三種方法各有各的優勢，最後一種方法是成本最低的，但我們偏偏就是最後一種方法。(上面兩種判斷是否授權可以入網的方法，在ZDO_JoinIndicationCB函數中，如果沒有授權的設備入網的話，強行讓其關聯失敗AssocRemove(xxx))
我照樣按照自己的節奏，先通過抓包分析，然後再決定採取什麼樣的策略(就跟古代打仗一樣，先派一小隊人馬試探一下，再進行陣列、戰術的調整)，通過抓包發現，關聯時候一直在發beacon request，而沒有associate關聯，當然有4、5個網關同時開着的時候，網關開的越多，關聯越慢。
有了一定的規律就通過打印以及抓包分析(個人認爲，打印還是最直接有效的定位手段，抓包、仿真、抓波形都是輔助手段)，發現到一點，以前關聯設備都是先NLME_NetworkDiscoveryRequest，收到beacon幀迴應後，在ZDO_NetworkDiscoveryConfirmCB裏面，判斷哪些網絡可以加入(全局變量NwkDescList的鏈表裏就是所有網關回應beacon幀的消息信息)，問題就在這裏，之前公司的代碼是每次先連接NwkDescList鏈表裏第一個網關，如果失敗，就接着下一個連接，但是連接成功判斷條件卻是NLME_JoinRequest函數的返回值，因爲這個操作是異步的，也就是這個函數結果基本上一直都是0，就會導致，每次掃描後，總是連接第一個返回beacon幀的網關，導致概率性的綁定不上，以及綁定慢，網關越多，綁定的越慢，綁定不上的概率越大。
後來通過修改，每次綁定的時候，網關端拒絕後(ZDO_JoinConfirmCB函數裏的結果值是2，具體原因請看802.15協議)，把該網關暫時拉入黑名單，下次收到beacon幀請求不加入，直接next，之前想嘗試每次收到所有的beacon幀的網關信息，加入一個數組，associate拒絕後，在associate下一個，但是CC2530有個BUG，你不能直接associate，必須先beacon request，收到beacon幀後再associate就可以，估計裏面狀態只能這樣，都封裝成庫了，但是修改後，綁定速度快多了，如果在4個網關以下，一般10秒內綁定上，5個網關以上，一般也要20-40秒可以綁定上，代碼如下，
詳細具體代碼就不一一展示了，本次主要分享定位的思路和先後順序，而不是解讀代碼，下一講，分享解決長期運行掉線不能自恢復的隱性BUG。