Author:DriverMonkey
Mail:[email protected]
Phone:13410905075
QQ:196568501
測試平臺：AM335X
優化前狀態：採樣速度 105次/S
優化目標：速度爲 130次/S 以上（注：根據ADC的採樣率理論上可以達到 330次/S）
優化步驟：
1）代碼框架可分爲四大模塊（UI, 業務邏輯管理，設備管理，遠程管理）共10個線程
模塊間有項目依賴關係，不能一下全部停掉，先去掉一些輔助功能線程（如：按鍵掃描線程，遠程命令處理線程等）。
接下來只剩下UI，業務邏輯處理，設備管理，遠程管理，四個主線程。編譯運行代碼查看採樣速度有無變化。運行結果
是無任何明顯變化（任然在105次/s 左右波動）
2）現在懷疑UI，設備管理，遠程管理這三個模塊運行效率太低導致採樣速度提不上去導致。
分別屏蔽這三個線程，分別採集線程同時運行查看採樣速度有無明顯變化。
運行結果是無任何明顯變化（任然在105次/s 左右波動）
3）現在只剩下採集線程（其他線程全部停止）發現採集速度同樣上不去
接下來逐一屏蔽業務處理模塊的子模塊，再分別編譯運行，查看運行結果，採樣速度任然沒有任何明顯變化
4）到這一步只剩下應用層代碼通過SPI總線讀ADC 這部分代碼了
寫一份fake 讀ADC 的代碼替換掉原來的代碼，發現能滿足現在的優化需求（fake 讀ADC 代碼的採樣率 280次/S）
通過當前調試現象至少可以肯定ADC 採樣率的瓶頸不在應用層。接下來調試思路，從應用層代碼轉向驅動層，和硬件原理圖的設計
5）運行只有業務邏輯層代碼的程序去讀ADC值，並查看系統狀態。
通過TOP查看發現系統進程狀態發現一個kworker 進程有異常，發現這個進程CPU佔用率爲20%~30%。
繼續查找資料，發現kworker 進程實際上在內核中是一個處理隊列的內核線程。
看到這個kworker進程給我的第一感覺可能是SPI讀寫驅動申請的。繼續調試發現調用讀取ADC SPI 接口有的時候需要花費 5ms 甚至 10ms的時間才能返回。實際上我們次發送和接收才4個字節。那就不可能是SPI驅動引起的，那就可能是別的驅動引起的，而當前運行
APP只調用SPI一個驅動。
現在從系統狀態入手。通過查看系統狀態發現，一個驅動中斷異常(每秒鐘103次中斷)中斷，明顯中斷過於頻繁。實際上這個驅動我們
系統名沒有使用，找到對應代碼重新編譯內核。重新運行APP 採集速度直接到 258次/S
優化結果：
採樣速度達到 258次/S 完全滿足優化目標