斷言機制估計很多道友都用過，在 ST 的標準庫中，經(jīng)?？梢钥吹剿纳碛埃?/p>

它的實現(xiàn)方式也是非常簡單的，就是通過 USE_FULL_ASSERT 宏進行控制：

如果斷言失敗，就會執(zhí)行 assert_failed 函數(shù)，一般實現(xiàn)函數(shù)如下：

void assert_failed (uint8_t* file, uint32_t line)

{

  static char buff[128];  

  sprintf (buff,"%s,%d", file, line);

  __breakpoint(0);

}

當然這里的 sprintf 函數(shù)也常常使用 printf 代替，這樣就可以直接通過串口打印出來了，而魚鷹這個在沒有串口的情況下，可以通過內(nèi)存 buff 顯示出來，比較方便在線調(diào)試。

而 __breakpoint(0) 一般由死循環(huán) while(1) 代替，而魚鷹覺得 while(1) 不夠好，因為斷言失敗后，可能很久你才能發(fā)現(xiàn)而進入該死循環(huán)，而使用  __breakpoint 可以讓你在 在線調(diào)試 模式下，立刻停止程序運行，從而可以快速定位問題。

不管哪種實現(xiàn)方式，斷言失敗的結(jié)果一般只有暫停程序了，類似 linux 內(nèi)核的 panic 。

而這是設計者希望看到的，但有些開發(fā)者認為不應該這樣，因為程序一旦死循環(huán)，如果開啟了看門狗，會導致整個程序復位，對于產(chǎn)品而言，復位是很嚴重的 BUG 。

“我不希望我的產(chǎn)品復位，所以請修改你的代碼，不讓他產(chǎn)生斷言失敗，可以嗎？”

不可以。

斷言本身不是錯誤，它只是發(fā)現(xiàn)你程序的 BUG ，進而提醒你。

斷言失敗，往往是很嚴重的問題，嚴重到這段代碼或功能無法正常執(zhí)行，所以你修改的地方應該是調(diào)用者，而不是產(chǎn)生斷言的代碼，請不要顛倒主次，否則沒有從根本上解決問題。

就比如最上面的 GPIO 外設指針檢查斷言部分，如果調(diào)用者傳入一個非 GPIO 的指針進入函數(shù)，從而產(chǎn)生斷言失敗，那么你會選擇關閉斷言機制還是說檢查你的代碼是否存在問題呢？

當然是后者。

所以，如果產(chǎn)生了斷言失敗的情況，請不要慌，不要認為這是一種錯誤，而應該根據(jù)斷言失敗的位置，定位斷言失敗的根本原因，而不是試圖通過關閉斷言的方式讓程序繼續(xù)運行下去，這只會讓你的程序運行得更糟糕，同時也更難定位問題。