斷言機(jī)制估計(jì)很多道友都用過(guò)，在 ST 的標(biāo)準(zhǔn)庫(kù)中，經(jīng)常可以看到它的身影：

它的實(shí)現(xiàn)方式也是非常簡(jiǎn)單的，就是通過(guò) USE_FULL_ASSERT 宏進(jìn)行控制：

如果斷言失敗，就會(huì)執(zhí)行 assert_failed 函數(shù)，一般實(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);

}

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

而 __breakpoint(0) 一般由死循環(huán) while(1) 代替，而魚(yú)鷹覺(jué)得 while(1) 不夠好，因?yàn)閿嘌允『螅赡芎芫媚悴拍馨l(fā)現(xiàn)而進(jìn)入該死循環(huán)，而使用  __breakpoint 可以讓你在 在線調(diào)試 模式下，立刻停止程序運(yùn)行，從而可以快速定位問(wèn)題。

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

而這是設(shè)計(jì)者希望看到的，但有些開(kāi)發(fā)者認(rèn)為不應(yīng)該這樣，因?yàn)槌绦蛞坏┧姥h(huán)，如果開(kāi)啟了看門狗，會(huì)導(dǎo)致整個(gè)程序復(fù)位，對(duì)于產(chǎn)品而言，復(fù)位是很嚴(yán)重的 BUG 。

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

不可以。

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

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

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

當(dāng)然是后者。

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