我們已經了解了很多的 KEIL 調試方法，但是到底該怎么使用這些方法呢？這篇文章將介紹個人的調試經驗。 虛擬串口

首先是虛擬串口，為什么要虛擬串口，這里的虛擬串口又是什么意思？

在線仿真的時候我們根本不需要虛擬串口，因為單片機一般來說都有串口，所以不需要虛擬的串口，但是在軟件仿真情況下又該如何呢？

有些時候我們可能沒有開發板，但項目很急，需要提前做，該怎么辦？KEIL 的軟件仿真可以幫你解決大部分問題，它可以幫你驗證程序邏輯問題，也能驗證硬件配置是否正確，相當不錯的功能。比如你的串口配置是否有問題，進入仿真模式：

從上面的仿真圖你可以了解到在軟件仿真模式下，你可以正常使用 printf（），scanf（）函數，輸入輸出操作由串口窗口進行，所以還是很方便的，但是需要注意的是：

即使是軟件仿真，它的發送時間和你的設定波特率也是有關系的，即發送完一個字節后，必須延時后才能在串口窗口看到數據，這個時間和現實時間可能不匹配（即 115200 不一定是 1 秒就發送115200 個 bit，可能更多，也可能更少），但道理是一樣，因為它對串口的工作過程進行了完全模擬。在這里你還可以選擇顯示方式。

這里看到我之前寫的一個注釋：

但實際測試發現并不會丟失最后一個字符，不知道當時咋測試的。繼續正題。有一個問題，如果說你想把這個數據傳給其他上位機呢？比如你想把串口數據傳輸到一個虛擬示波器顯示（事實上 KEIL 也能顯示波形，但是功能比較簡單），又該怎么辦？這個時候你可以虛擬一個 COM 口，將串口數據綁定到 COM 中：

在命令行中輸入紅色方框中的內容，既可達到目的。當然你可以將其保存為.ini 文件，具體使用方法請看魚鷹相關筆記。上面的命令參考鏈接：http://www.keil.com/support/man/docs/uv4cl/uv4cl_cm_assign.htm？_ga=2.225757210.1084600666.1557148734-475076243.1554469739完成綁定后。

KEIL 軟件的串口 1 數據除了會發送到 KEIL 串口窗口中（【View】【Serial Windows】），也會發送到 COM1 口中（當然數據輸入也是從 COM1 中進行輸入的）。但是因為 KEIL 對 COM1 進行了綁定，也就是你的 KEIL 正在使用 COM1 口，那么其他軟件肯定是無法打開這個 COM1 口的，那么這樣又該怎么查看 COM1 的數據呢？

此時你可以使用一個軟件虛擬兩個串口，這里我用 vspd.exe 軟件虛擬 COM1 和 COM2，并且將 COM1 和 COM2 進行了連接，這里就是說 COM1 發送的數據會被 COM2 接收，接收同理，這樣一來，KEIL 中的串口數據就能發送到 COM2 中了，因為 COM2 并沒有被任何軟件所使用，所以你可以使用串口助手打開（其他串口軟件類似）。

因為在這里是虛擬的串口，所以說你的波特率參數并沒有用處，即你的串口配置成 115200，你的上位機以 9600 接收也是可以的。但是你會發現，這個中文支持不如 KEIL 自帶的窗口好用，但通過將串口綁定到其他 COM 口的方法能擴展它的串口仿真功能，還是相當不錯的。事實上，KEIL 除了仿真串口，也能仿真 I2C、CAN，比如下面的：

對此感興趣的可以參考鏈接：http://www.keil.com/support/man/docs/uv4/uv4_sm_can_communication.htm變量使用在前面公布的文章中，魚鷹曾經說過一個詞，顛覆認知：打了多年的單片機調試斷點到底應該怎么設置？| 顛覆認知也說過一個串口通訊的問題：

KEIL 調試的 ini 文件有什么用？通過運用上面的知識，總算是解決了項目串口通信的問題，測試多天，不再出現這個問題了。那么魚鷹是如何解決的呢？且聽魚鷹道來。這個通信錯誤的現象是，前一個數據幀尚未發送完成，后面又來一個數據幀，導致傳輸數據錯亂了，這種現象在多任務中很常見，所以魚鷹很早就對它進行了研究：

信號量保護之禁止中斷

因為魚鷹知道，資源互斥的現象很平常，只有深刻理解了其中的原理，你才能更好的掌握它。而這個通信過程的互斥資源有兩個，第一個是發送緩存數組的資源，另一個就是串口。在這里因為沒有采用隊列的方式發送數據，所以緩存數組和串口是綁定在一起的。

也就是說，一旦數組中含有發送數據，那么馬上就開始進行發送，中間不應該斷開，所以可以把數組和串口當成一個資源使用（特別需要注意的是，一定要在對數組賦值之前獲得互斥鎖，而不是在串口發送前獲取，因為只要這樣，才能保證你發出的數組數據不會被其他程序修改）。

很明顯，這個資源是互斥的，所以可以使用一個變量作為訪問該資源的鎖，每次訪問之前看資源是否被使用，如果被使用了就等待。而鎖的釋放是由發送完成中斷完成的，即只有將全部數據發送完成之后這把鎖才能釋放，進而由其他任務使用。

那么如何利用上面提到的技能查找這類問題呢？

這里的關鍵點還是在鎖，因為如果這把鎖被正確使用的話，是不應該出現兩個數據幀混亂的情況的，需要對這把鎖重點關注，那么該如何關注呢？

就是用前面的斷點窗口，對這個變量（鎖）設置寫入訪問斷點，如下：

這里要說明一點，單片機所有的全局變量都是可以在命令行直接獲取數據的（事實上如果你將斷點設置在函數內部，也可以獲取局部變量的值），比如你在命令行直接輸入 lock

0x00000001 就是這個全局變量 lock 的值。

回到剛才鎖的話題。在斷點窗口設置之后，你就會在 Command 命令窗口中得到如下消息：

正常的 lock 數據流程應該是這樣，1~0~1~0~1……也就是上鎖、釋放鎖交替進行的，但是魚鷹在觀察有錯誤通信的代碼發現，出現了 1~0~0 這種情況，也就是說一次上鎖之后，出現了兩次釋放鎖的過程，那這是怎么回事？

魚鷹前面說過，釋放鎖的位置在串口發送完成中斷中（此處是 DMA 傳輸完成中斷），難道有其他位置對它進行了清零操作？為了確定這個位置繼續增加調試信息（注意如果重新設置了一個新斷點，需要把之前的斷點刪除）：

這次將寫入時的 PC 指針打印出來（需要注意，ST-LINK 不能實時更新這個 PC 數據，但 CMSIS-DAP 可以，暫時未找到解決辦法），你會發現清零的位置是一樣的（沒有實際環境，模擬的情況）：

可以看到，清零操作時的 PC 指針都是一樣的，也就是說，釋放鎖的過程確實只有一處，那么為什么會出現兩次釋放呢？那肯定是啟動了兩次 DMA 傳輸，導致兩次進入傳輸完成中斷，從而釋放了兩次鎖。

這里再說一點，怎么通過 PC 指針找到對應源代碼的位置：

之后輸入你的 PC 指針即可：

但是按理來說，如果上鎖操作正常的話，應該不會出現兩次啟動 DMA 傳輸的過程才是，所以由此可以判斷出，肯定有至少一處地方沒有上鎖而直接使用了互斥資源，才最終導致了異常情況。

通過對互斥資源在整個系統的使用情況，發現確實有一個地方使用了互斥資源，但是卻沒有對互斥資源上鎖（當時由于某種原因，只對鎖是否可用進行了判斷，但判斷完成后，并沒有對它加鎖）。當加上了這把鎖之后，通信就此正常了（實際情況要比這個更復雜一些）。

為什么說顛覆認知，就是因為掌握了這個技能后，很多問題可以迎刃而解。就比如項目中有一個變量莫名奇妙的變化了，通過對每一次寫入操作的監控，發現了數據變化順序出現了問題，不該出現的變化卻出現了，從而深入下去找到變化的原因，并最終解決了這個項目問題。可以說掌握了這個技能，魚鷹用它解決了很多以前難以解決的問題，所以我才會對它推崇備至！

從前面講述的內容可以知道，原來 printf 函數不僅可以打印一些字符串，還能獲取運行在單片機上所有的數據（包括你定義的全局變量、靜態變量、外設寄存器、CPU 寄存器），了解了這個，你再也不用在你原來的代碼中添加調試代碼后再刪除了，使用這個方法有以下幾點好處：

1、命令行中的 printf 函數打印數據比串口打印速度更快，極大地減少了調試語句對原本代碼的影響。

2、再也不會忘記刪除代碼了，因為這些語句根本就沒有下載到單片機中，只要退出調試模式，就不會對程序造成任何影響。

3、只要你使用 KEIL，有一個可以設置斷點的調試器（不管是 ST-LINK、CMSIS-DAP、還是 J-LINK）都可以采用這種方式調試，極大的方便了開發。

說到程序的變量，事實上我們也可以在 KEIL 內部定義一個變量，即使用 DEFINE 命令定義一個變量名，這個變量不存在于單片機中，而只存在 KEIL 軟件中，所以不用擔心存儲空間不夠的問題，但是因為單片機和 KEIL 共用同一套符號系統，所以，你定義的變量名不能和單片機的全局變量名相同。至于你定義的這個變量用來干什么，那完全就是你自己的事情了。

數組輸出

前面的內容說了程序中的變量都可以通過 printf 函數打印出來，但在公眾號公布的文章說過，它畢竟不是標準的 C 語言函數，所以它不支持指針，所以也不支持數組，那么我們該如何輸出數組呢？

這個時候其實要用到公眾號公布的另一篇關于 ini 的使用問題的文章。

看完那篇文章之后，在 ini 文件中輸入以下代碼，并編譯執行：

然后，在你的程序中添加如下代碼：

這里的 OspreyARR 數組是我們準備輸出的數據，OspreyPointer 這個數據用于保存數組的地址。因為不支持指針，只能換種方式來達到相同的效果了。

然后對上面的斷點設置如下：

事實上我們也可以設置成這樣：

這里的 0x2000 004E 就是數組的地址，但是因為每次編譯之后，數組的地址可能都不一樣，所以使用一個變量 OspreyPointe 實時保存這個地址，這樣你需要顯示什么數據，只要修改這個變量的值即可，不需要修改斷點窗口的值。

全速運行之后，你就可以獲得如下結果：

可以看到，數組中的所有數據都打印出來了，同時將當前打印的地址、長度信息也打印出來了。

數組查看這個技能有什么好處？下位機和上位機通信是很正常的是，而通信錯誤再正常不過了，那么怎么實時獲取通信過程的數據呢，以前靠串口 printf，現在靠更高級的 KEIL printf，就是這么簡單，串口助手都省了。

除此之外，我們還可以對接收或者發送的數據進行解析，方便閱讀，比如下面的是我在工作中根據自己的通信協議做的一個簡單解析：

時間獲取

上面介紹了獲取數據的方法，但是很多時候，我們不僅需要數據進行分析，還需要獲取數據時間，有時候時間是很關鍵的一環。

那么該如何獲取時間呢？

以前一般使用 SysTick 獲取時間，但是當你使用操作系統的時候，你會發現這個時鐘被操作系統占用了，那么怎么辦？搶嗎？肯定不行，那么只能找替代方案了，那么找誰，普通定時器？高級定時器？都不是，這里魚鷹推薦 DWT。

為什么推薦它呢？

1、很多 STM32 單片機都集成了這個模塊

2、它的精度是 CPU 運行周期，即它是由 CPU 系統時鐘驅動的，即你的內核時鐘頻率是 72 M，那么它的頻率也是如此，所以精度很高。

當我們使用定時器中斷的時候，如果需要看你的定時中斷是否及時處理了（如果沒有及時處理，那么兩次進入定時中斷的時間肯定是不同的），那么使用 DWT 是不二人選，因為即使你的中斷延遲了一個指令的執行時間，它也能發現，因為多運行一條指令，那么 DWT 的計數器必然會增加，所以如果時間要求高的話，可以直接獲取計數器的值。

但很多時候，可能并不需要那么精準的時間，而只需要大概的實際時間，而且為了方便使用，魚鷹使用相對時間（即上次和這次執行時間之差），所以可以使用下面的這個函數（上面這個函數用于直接獲取計數器的值，0xE0001004 為 DWT 計數器的地址，事實上 DWT 使用是需要初始化配置的，但 KEIL 在進入 Debug 模式后會自行配置，不需要你操心）：

并且為了和正常時間匹配，對 DWT 時間進行了換算，單片機系統時間設置為 72M，所以我這里除以 72 用于換算成 us 時間，另外為了更加精確，使用了浮點型數據（關于為什么加 0xFFFF FFFF 請看公眾號相關文章，魚鷹就不在此詳述了）。

那么該怎么使用呢？我在公眾號的視頻中其實已經展示了這個方法，現在詳細介紹這個方法：

首先設置一個你需要的斷點，然后在 Command 里面輸入你的 printf（）調試信息：

這樣就可以了（前提是你已經使用 ini 文件包含了上述內容）。

其實單純獲取時間信息是用處不大的，你還可以結合前面的變量和數組數據顯示，一起輸出到命令窗口，這樣你就能獲得這個斷點的執行頻率和變量的數據，但是這里需要說明一點的就是，魚鷹在 KEIL V5.14 下用調試器 CMSIS-DAP 可以同時在 Watch 窗口和命令窗口中實時刷新數據，但是使用 ST-LINK 時發現命令窗口的數據變量值是不能實時刷新，也就是說這個變量始終是一個數據，并沒有改變。

但是后來在使用 V5.25 版本時，CMSIS-DAP 調試下，命令窗口能刷新，Watch 窗口卻不能刷新了，所以各種情況需要道友自行分析，不能認為數據不變就是真的不變了，很可能是軟件或調試器的問題，但能確定的一點就是，當你將程序暫停時，Watch 還是會刷新數據的，這個時候的數據是可以信任的。

（關于這個還有一篇文章KEIL 下如何準確測量代碼執行時間？）

LOG 輸出

不知道你是否羨慕別人的上位機程序能夠實時的打印 LOG 數據，是否夢想著自己的嵌入式程序有一天也能實現？事實上真的可以。

在嵌入式開發時，受單片機資源的限制，很多時候都是用串口打印數據，高級一點的用 J-Scope 之類的工具，但是用串口有比較多限制：

1. 需要實現串口驅動程序，并占用為數不多的串口資源

2. 串口速度比較慢

3. 需要一個類似串口助手的上位機

4. 數據接收后需要自己保存這些數據

5. 不能設置斷點，調試受到很大的限制

6. 調試代碼在調試完之后得刪除，萬一忘記了，就會影響性能

但是用了 KEIL 自帶的 LOG 打印功能，就不存在這些問題，它的輸出速度就是調試器的速度，調試器多快，你的打印就有多塊（但是打印數據也別太多，需要針對性的打印，后面會說原因），而調試器速度一般都是 M 級別的，對于一般情況完全夠用了。

現在看怎么使用，使用的話，其實很簡單，就是幾條指令的事情，在你的 ini 文件最后輸入以下命令：

這樣從這條命令以下的所有內容都會保存在 DEBUG_LOG_OUT.txt 中（所以如果你不想把 ini 文件的其他內容保存在 LOG 中的話，那么就把這條命令放在 ini 文件最后即可）。

現在解釋一下這幾條命令，LOG OFF 表示將 LOG 文件關閉，即使你沒有打開一個 LOG 文件，執行該命令也不會出錯，這條命令主要是防止一個 LOG 文件重復打開的錯誤，加上這條命令就不會了。

第二條命令，即將 Command 窗口的數據保存在 DEBUG_LOG_OUT.txt 中，注意這里有個 》 ，而 DEBUG_LOG_OUT 這個文件名就隨你意了，但是實驗的時候按這個來，等你確定會了之后就可以隨便取你喜歡的名字了，出了問題自己對比一下就知道了。

然后再說一點，這里使用的是相對路徑，即你的工程文件下的路徑，如果你想往上一層，你可以使用 。./ 表示在這個工程上的一個文件夾下輸出 LOG 文件。

當退出調試模式之后，KEIL 將自動保存 Command 數據到文件中（也就是說在此之前你是看不到這些調試數據的），現在看看我的調試 LOG：

一次設定之后，LOG 打印就不需要你操心了，即使調試器通信錯誤，它也會把之前輸出的數據保存下來的。

看到這里，你應該知道 ini 文件到底有多重要了吧，你的所有調試命令都可以用它保存并在進入調試模式后自動執行，比如說你有一個斷點，很復雜，不想每次設置，那么你可以在設置完一次后，從命令窗口將這個命令復制到 ini 文件中，比如像這樣：

這樣你每次進入調試模式后，那些斷點就會被自動設置了，根本不用你操心，而且如果需要修改的話，也是直接在編輯器中修改后重新編譯就行，馬上就能生效，不再需要從斷點窗口設置了。

而這里有個刪除所有斷點的命令，這是為了防止和之前設置的斷點沖突，所以一次性全部刪除了（事實上，可以刪除某一個斷點，但需要斷點序號，而斷點序號每一次都可能不一樣，所以選擇直接全部刪了方便）。而為了更好的配合這些功能，可以把下面的 Breakpoints 勾選去掉，這樣它就不會保存關于斷點的設置了，而為了讓 Toolbox 在關閉后還能每次自動顯示出來，也可以去掉 Toolbox 的勾選。

另外再說一點，KEIL 支持把某一塊內存數據保存成文件，這個命令是 SAVE，感興趣的話可以去官網了解一下。

注意事項

上面說了 KEIL 命令調試的很多優點，現在說說它的缺點：

1、KEIL 命令調試不支持指針，這個已經多次強調了，要實現指針的功能，只能間接使用。

2、對程序運行造成一定的影響（事實上這個不關 KEIL 的事，是調試系統本身的問題）

前面說過，調試器可以說是第三方監視器，雖然幾乎沒有侵入性（事實上對 CPU 還是有影響的），但是它還是會竊取 CPU 時鐘的，而且在執行斷點的時候，雖然由 ini 文件定義的函數由 KEIL 執行了，實際上上執行這些函數也是需要時間的，那這個時間怎么來。

就是通過暫停 CPU 后去執行這些代碼，這個你可以通過 DWT 計數器看出來，因為只有 CPU 執行了 DWT 才會計數，但是你會發現在執行這些代碼時，DWT 是沒有進行計數的（在 KEIL 函數的前后獲取 DWT 計數，可以發現計數值不變）：

也就是說 CPU 和 KEI 是在交替使用系統時鐘的。平常來看，由于 KEIL 執行速度很快，看不出來問題，但到中斷的時候卻會出現問題。

情況是這樣的，驅動步進電機時，魚鷹使用了這種調試方法打印每次進入定時器中斷的時間，發現即使使用最高精度的情況下（CPU 運行時鐘），每次進入中斷的時間看似都是固定的，但步進電機還是表現出失步情況，也就是說系統內部時間看起來每次進入中斷時間一樣，但是實際情況是，已經丟失了時間（好好理解這句話），這個時間損耗就在運行這些命令上，而一旦把這些命令輸出刪去，就會發現電機不再出現失步了。

這是一個比較大的缺陷，但是在一般情況下是不會有多大問題的，因為一般情況下竊取一點 CPU 時間也不會對整個系統有太大影響，前提是你別竊取太多了。

編輯：jq