我們常常說，軟件三分寫七分調。實際開發中，確實也是這樣子的。我工作這幾年了，對這體會也越來越深。每當需求一下來，我代碼很快就可以寫完，但是，調試需要花很多時間。

這里需要明確的是， 調試的目的不僅僅是調通整個功能需求 。調通功能是最基本的要求，還需要進行優化、完善邏輯、完善異常處理。所以，需要非常長的時間。

記得畢業的時候參與的第一個項目，那個項目的硬件架構相對一般產品來說會復雜一些：

我負責的部分就是D芯片的軟件。D芯片所做的事情就是跟產品功能比較相近的，當時通過A發數據，經過B、C之后，再到D，產品功能表現得不正常。我當時的 第一反應 就是我負責得D芯片的邏輯可能出問題了。

A、B、C都是比較有經驗的工程師負責的，而且負責C的還是個組長級別的，大家也覺得應該是我負責的D芯片的代碼出的問題，因為我是個剛畢業的新人，覺得問題出在我這里的概率比較大。

他們也沒有去查是不是他們的問題，每天就是來看看我是否有找到問題。花了幾天的時間，我最后才定位出來，是C芯片給我發的數據出問題了~

因為當時缺乏調試經驗，所以沒能很快就定位出問題所在。要是現在的話，這種問題很快就能查出來的。因為現在積累了一些經驗：

調試經驗

平時開發調試時，可能會有這么兩種情況：

• 獨立開發，自己調試

• 協作開發，聯合調試

1、獨立開發

一些小的項目，如果整個項目是我們自己開發的話，調試起來也比較方便，因為是我們自己開發的，所以會比較熟悉一些。

我的習慣是：分模塊來進行開發，每開發完一個模塊就先想辦法測一下這個模塊，沒問題了再集成到工程里。模塊初步開發、測試時，代碼可以隨意一些，調好了之后，再重新梳理、整理代碼，集成到工程里。

自測的方式：有一些代碼直接對應著功能，直接測試看功能正不正常；有一些代碼可以通過log打印來看是否正常；有一些可能需要在線調試看看是否符合預期；有一些需要數據輸入的，可以自己模擬一些數據等。

2、協同開發

協同開發時，可能就比較麻煩一些。特別的，有時候甚至需要跨部門對接調試。

我的習慣是：先開發并自測自己的模塊；然后模擬對方，簡單地自測通信。

自測自己模塊的方式如上面獨立開發一樣。我們模擬對方進行測試時，需要考慮是不是需要花比較多的時間，如果需要花太多的時間的花就算了，等到聯調再一起調。

花時間較少的，可以自測通信的情況可能有如下三種：

• 線程/進程間通信。這應該比較容易，模擬對方線程/進程進行收發測試。可以寫一些測試命令，比如發某個命令，觸發某條消息發送。
• 板間通信，如串口通信。可以用串口助手模擬對方進行測試，自己對照協議模擬一些協議數據進行收發測試。
• socket通信，如TCP通信。你負責客戶端，就模擬服務端；你負責服務端，就模擬客戶端。

當然，協作開發也可以不自測通信，看個人習慣。

我模擬自測通信是為了對我自己的模塊的通信有一定的把控，聯調時出問題時，就可以比較快地指出對方的問題。當然，這不是為了推鍋，而是為了能更好地分析、解決聯調問題。

比如，我最近的項目中，設備與手機APP對接。配網功能、設備于APP局域網內通信功能。我負責設備端，設備端作為服務器；對方作為客戶端。

在與對方聯調前，我已經寫了一個客戶端運行于PC或設備上，模擬對方的手機APP，對我的模塊做了基本的自測，也測出了我的模塊的一些問題。

然后在與對方正式聯調時，出現的大多問題都在對方那邊，所以這時候我就可以幫助對方分析問題，提高了聯調效率。

上面分享了一些我的經驗及思路，下面看看一些具體的調試方法與調試工具：

調試方法

1、LOG

我在實際工作中，log打印調試解決了我大多數的問題，一般的問題，通過分析log都可以定位出問題所在。但是，打log也是有很多講究的，需要我們打印出有助于我們調試的信息。

比如：

• log的格式

帶時間戳、函數名、行號等有助于分析問題的信息。比如：

[func:100]

當然，實際中可能不只包含如上信息，根據需要添加。

• 在一些判斷分支要加上log

這樣可以清楚地知道程序跑到分支判斷時的執行流程。

• 在一些大的操作的開始處，加上顯眼的log

可以清楚地知道某個操作開始的地方。

• 業務邏輯模塊，可以加上特定的標簽

比如統一的log的格式中加上特定標簽，比如BUSINESS。如：

[BUSINESS][func:100]

因為業務邏輯一般是整個項目地最上層，其它模塊都是為它服務的。

我們看log的時候，通過編輯器搜索關鍵字 BUSINESS 就可以只列出業務邏輯相關的log，我們只要看這些log，就可以大致知道程序的運行流程。

當然，其它模塊也可以根據需要加上標簽。

• 控制log打印頻率

與數據打交道的模塊可能需要打印一些數據來分析源數據是否正常。可以稍微的控制打印頻率，盡可能在不影響數據分析的情況下打印盡可能少的log。

否則，一些log的文件動不動就幾百MB，分析起來也很頭疼。特別的，log需要保存在flash上時，為了防止log爆滿flash，常常需要限制log文件的大小并做log滾動覆蓋，這時候無效log太多了可能就會覆蓋掉有效的log。

往期關于log調試相關的文章：

C語言、嵌入式中幾個非常實用的宏技巧

bug解決不了？使用日志法

分享一個極簡的log模塊！

嵌入式軟件打log的一些心得！

2、在線調試

在線調試，可以看到程序運行的更多細節。基本的應該都會吧。

GDB往期相關推文：

例說GDB調試

手把手教你使用VSCode + gdb + gdbserver調試ARM程序

GDB調試器的簡單使用(圖文)

關于keil的調試相關的內容，推薦看一下我同事魚鷹寫的文章（公眾號：魚鷹談單片機），他對這方面研究得比較深。

3、其它調試工具

我們公眾號之前也分享了很多有用的調試相關的工具：

（1）VirtLCD

這是一個實用的LCD模擬器，手頭上暫時沒有LCD或者開發初期，需要頻繁下載程序，驗證效果的時候，可以使用VirtLCD來提高我們的開發、調試效率。

VirtLCD的介紹及簡單使用：

實用 | 手頭上無LCD卻又急著開發UI？LCD模擬器了解一下~

（2）Wireshark

Wireshark 是一個網絡封包分析軟件。比如我們在調試socket通信的時候，可以使用Wireshark 監控看看我們有沒有發送數據出去，或者有沒有收到對方發送的數據。

wireshark的介紹及簡單使用：

wireshark抓包工具的使用及分析

（3）VSPD

Virtual Serial Port Driver（VSPD）是一個虛擬串口軟件。虛擬串口軟件是一種模擬物理串行接口的軟件，它完全復制了硬件 COM 接口的功能，并且將被操作系統和串行應用程序識別為真實端口。

在編寫串口上位機時，需要進行調試。一種方式是與下位機進行通信進行測試；另一種方式是借助虛擬串口軟件來進行測試。

VSPD的介紹及簡單使用：

工具 | 虛擬串口軟件的使用分享

（4）LVGL GUI Guider

GUI Guider是恩智浦為LVGL開發了一個上位機GUI設計工具，可以通過拖放控件的方式設計LVGL GUI頁面，加速GUI的設計。

相關文章：

實用工具 | LVGL GUI-Guider的使用分享

基于vs2019的lvgl模擬器使用

lvgl最新版本在STM32上的移植使用

（5）Jlink+JScope

J-Scope 是 SEGGER 推出的波形顯示軟件，傻瓜式，簡單易上手。需要搭配 Jlink仿真器 （V9或V10）使用。

J-Scope的介紹及簡單使用：

J-Scope的介紹及簡單使用

（6）SEGGER_RTT

RTT全稱是Real Time Transmit（實時傳輸），是SEGGER 公司推出的，是搭配 Jlink仿真器 （V9或V10）使用的一種調試手段。

SEGGER_RTT的介紹及簡單使用：

SEGGER_RTT的介紹及簡單使用

（7）CmBacktrace

CmBacktrace （Cortex Microcontroller Backtrace）是一款針對 ARM Cortex-M 系列 MCU 的錯誤代碼自動追蹤、定位，錯誤原因自動分析的開源庫。

CmBacktrace 的介紹及簡單使用：

CmBacktrace 的介紹及簡單使用

（8）VOFA+

VOFA+（伏特加）插件驅動的高自由度上位機。其是一款通用的數據調試工具，它讓圖形化調試變得像串口調試一樣簡單。通過打印字符串，或者發送十六進制數字的方式，就能完成數據的可視化操作。

官網：

https://www.vofa.plus/

VOFA+的介紹及簡單使用：

VOFA+的介紹及簡單使用

（9）QEMU

QEMU是一款知名的而且開源的模擬器（官網：https://www.qemu.org/），它能在 X86 PC 上運行能夠模擬 Arm、MIPS、RISC-V 等各種 CPU 和開發板，以及 網卡、聲卡、鍵盤、sdcard、emmc、usb等各種外設。

QEMU我還未使用過，之前轉載的一篇文章：

Linux利器：QEMU！用它模擬開發板能替代真開發板？

（10）Valgrind

Valgrind是一套Linux下，開放源代碼（GPL V2）的仿真調試工具的集合。

Valgrind的介紹及簡單使用：

工具 | Valgrind仿真調試工具的使用

（11）Bus hound

Bus hound是一款為了在pc電腦上進行總線數據包監控以及操控的開發工具。用來捕捉來自設備的協議包和輸入輸出操作，它是功能強大的總線協議分析器。

之前有與USB上位機聯調，通過這個工具可以監控上位機發出的數據是否正確。關于Bus hound的文章我們公眾號還沒有分享過，先占個坑，之后有機會再分享。

審核編輯 ：李倩