新闻  |   论坛  |   博客  |   在线研讨会
断言不是错误!
鱼鹰谈单片机 | 2022-01-21 08:44:29    阅读:144   发布文章

断言机制估计很多道友都用过,在 ST 的标准库中,经常可以看到它的身影:

1.png

它的实现方式也是非常简单的,就是通过 USE_FULL_ASSERT 宏进行控制:

2.png

如果断言失败,就会执行 assert_failed 函数,一般实现函数如下:

void assert_failed (uint8_t* file, uint32_t line)

{

  static char buff[128];  

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

  __breakpoint(0);

}

当然这里的 sprintf 函数也常常使用 printf 代替,这样就可以直接通过串口打印出来了,而鱼鹰这个在没有串口的情况下,可以通过内存 buff 显示出来,比较方便在线调试。

而 __breakpoint(0) 一般由死循环 while(1) 代替,而鱼鹰觉得 while(1) 不够好,因为断言失败后,可能很久你才能发现而进入该死循环,而使用  __breakpoint 可以让你在 在线调试 模式下,立刻停止程序运行,从而可以快速定位问题。

不管哪种实现方式,断言失败的结果一般只有暂停程序了,类似 linux 内核的 panic 。

而这是设计者希望看到的,但有些开发者认为不应该这样,因为程序一旦死循环,如果开启了看门狗,会导致整个程序复位,对于产品而言,复位是很严重的 BUG 。

“我不希望我的产品复位,所以请修改你的代码,不让他产生断言失败,可以吗?”

不可以。

断言本身不是错误,它只是发现你程序的 BUG ,进而提醒你。

断言失败,往往是很严重的问题,严重到这段代码或功能无法正常执行,所以你修改的地方应该是调用者,而不是产生断言的代码,请不要颠倒主次,否则没有从根本上解决问题。

就比如最上面的 GPIO 外设指针检查断言部分,如果调用者传入一个非 GPIO 的指针进入函数,从而产生断言失败,那么你会选择关闭断言机制还是说检查你的代码是否存在问题呢?

当然是后者。

所以,如果产生了断言失败的情况,请不要慌,不要认为这是一种错误,而应该根据断言失败的位置,定位断言失败的根本原因,而不是试图通过关闭断言的方式让程序继续运行下去,这只会让你的程序运行得更糟糕,同时也更难定位问题。

*博客内容为网友个人发布,仅代表博主个人观点,如有侵权请联系工作人员删除。

参与讨论
登录后参与讨论
推荐文章
最近访客