|
嵌入式系統的調試往往很復雜，可用的手段并不像PC編程那么多，開發成本較PC系統也要大很多。嵌入式系統調試主要手段只有JTAG為代表的單步追蹤、printf夾殺大法等。 這兩種調試方法在嵌入式中也不盡然全部能解決問題。Jtag需要調試者有一個調試設備(有可能很昂貴)，和目標系統相連。使用類似GDB Client等軟件登錄調試設備，跟蹤運行程序。說實話，這個方法對嵌入式來講是終極的調試辦法，也是比較好的調試方法。但仍然有幾個不足,當斷點過多時，超出硬件的限制，某些低檔的CPU不支持更多的斷點，就需要JTAG利用軟件模擬，或采用軟件陷阱(軟中斷或異常)等辦法實現斷點。機理比較復雜，簡單點說，1.不能進行長時間調試，不太穩定; 2.有可能影響程序的運行時刻的行為，通過時序影響。掛接JTAG系統后，利用硬件實現的斷點不會影響系統運行的速度，但是軟件實現的斷點是必定犧牲一些性能的。可靠性也要打折扣的。當斷點太多，而系統又進入臨界區域，可能會造成斷點不起作用。因為嵌入式實現全局臨界區域往往需要關閉中斷，有些CPU沒有非屏蔽中斷，當斷點超過一定數量，使用軟件斷點，而軟件斷點又需要在中斷工作的情況下使用…… 特別調試時序問題和高速通信類的代碼，JTAG幫助并不大。通信過程往往很快，通信包也是接二連三，才能完成一個完整的動作。如果是高速通訊，斷點是無法讓程序完成工作的。所以只能使用printf夾殺的辦法，printf夾殺辦法很好。但是也要注意幾個問題：嵌入式系統往往沒有屏幕，printf輸出是通過串口輸出。而串口工作模式有兩種，一種是查詢，另外一種是中斷，或DMA。不管哪種，調試輸出的printf只能使用查詢的辦法輸出，千萬不要使用中斷或DMA的辦法。不管是前后臺程序也好，還是操作系統也好，都有不方便的時候，也許在全局臨界內需要打印(關閉了中斷)，也許需要在中斷里打印(不允許嵌套中斷)，也許要在一些驅動里打印(很多配合的設備沒有初始化，內存分配和中斷并不能很好的工作)。在這些情況下，利用Uart中斷輸出字符是不明智的。所以調試輸出只能使用查詢的辦法。嵌入式物聯網智能硬件等系統學習企鵝意義氣嗚嗚吧久零就易，不要幻想著使用什么牛叉的辦法，不必了。一句話，不可靠！既然做調試，那可靠的輸出結果是第一要求。也就是因為如此，printf也會影響代碼的工作效率，串口最高的波特率115200bps，越快速的CPU越是浪費時間，因為需要等待上一個字符輸出完畢，這段時間完全是通過空轉消耗這部分時間。所以使用printf要有一些技巧，在不影響一些關鍵時序的位置下再打印，而不是隨意爛打……淹沒了bug。 以上這兩種辦法并不能很好的解決全部的問題，在實際中如果嵌入式系統有一兩個LED燈，嘗試用IO口將其在特殊的情況下點亮熄滅的辦法，也可表示程序的狀態。這種辦法適合調試中斷、臨界區域這些問題。點量LED燈需要的時間是非常短的，基本上是一條內存讀寫命令，如果IO口寄存器是CPU統一編址的話。基本上造成的影響微乎其微。在調試一些復雜的時序的時候，還可以使用空閑的IO口，將其在特殊的情況下拉低，拔高，然后利用數字示波器或者邏輯分析儀抓取再具體分析。特別是分析一段代碼的執行頻度，執行時間，優化效果等。對整體的性能提升等，有非常大的意義。對于簡單的單片機，廠商開發軟件都有個時序統計的功能。但對于有cache和MMU的單片機，時序統計并不準，往往不如用示波器測得的準。如果沒有示波器利用CPU內部的時間計數器也可以實現時間的統計，需要結合printf使用。 我一個同事，調試飛利浦的ARM7，由于飛利浦ARM7外擴的RAM全部是靜態RAM，即使在CPU死機情況下，只要不斷電，SRAM里的數據也不會丟失，由于SRAM和內部的SRAM統一編址，所以，訪問起來也就是一條讀寫指令，速度很快。利用這個特性，他把程序的模塊和點全部標記上，當系統運行不正常，將ARM7復位以后，ARM7上電第一個工作就是取出復位前的數據打印出來。由此可調試ARM7的代碼，非常巧妙的辦法。如果只有SDRAM的朋友們是不能用這種辦法的，因為只要系統復位，SDRAM沒有刷新，數據即會丟失。 使用哪種辦法，都有利有弊，在嵌入式系統里權衡的東西比PC平臺多得多…… |
