如何查找bug

    在C编程中，程序出现bug再正常不过了，如何查找bug对于初学C编程的来说，是一门学问。如何因地制宜，在仅有的资源中，快速准确地定位bug，对项目的开发非常重要，也是优秀码农的标志之一。
常见的查找bug方式有：一是串口输出到桌面上，二是在线仿真。
    如何有效地利用串口来监视程序的运行，值得好好思考。首先，得利用好C语言的宏定义中的条件编译。如，在需要用串口输出相关监视信息到桌面的地方，都如下编写：
#if define DEBUG
     SendString(USART1,"\r\n First step \r\n");
     printf("CarID value %d ",CarID);
#endif
    这里的宏定义，使用非常方便，当代码比较稳定或者产品已经定型后，将文件中的宏定义：
#define DEBUG
注释掉即可，此时，代码中所有利用串口监视程序运行的调试信息，都不会再编译运行。利用好宏定义与条件编译，就再也不当代码稳定或产品定型后很辛苦地一句句的删减调试信息。
    只是，这种利用串口监视程序运行的方法，需在编写时就在程序流程比较关键的地方，预先设置好调试信息。而如何选择关键的地方编写调试信息，就得看自己对程序流程的理解与把控。将比较重要的地方与容易出错的地方，在编译前就预先编写好调试信息，然后编译后，就通过桌面的串口调试助手来监视程序的运行情况。利用串口来监视程序运行，一定要有提前的思维与整体把控的习惯，想在编译前写在编译前。同时，一定要利用好条件编译与宏定义。
另一种，调试方式就是在线仿真了。利用仿真器，如J-Link、ST-Link等。程序出现bug了，编译后直接进入在线仿真模式，可以选择全速运行，直接观看参与条件判断的变量值，看它们的变化是否按照程序编写的理解在变化，然后选择最有可能出错的地方打断点，看程序是否运行到断点处，变量值的变化是否有异常。如果没有，继续在程序的上一层打断点，观看变量值的变化，一步步排查bug。当查找到某个变量的值变化有异常时，我们可用CTRL+F来查找哪些地方对变量进行了操作。甚至可以查看某处的内存空间，是否有值传入或变化。
    STM32开发环境，特别是Keil结合仿真器，查找bug非常方便。只是，查找的方法方式，如何打断点、看变量值、看内存，都是非常有技巧，需要编程经验的积累与不断的总结。
    如果在线仿真都没查找出问题，可以利用keil与仿真器反汇编，直接查看汇编代码的执行的情况。只是，能够看得懂汇编的码农，是比较牛逼的存在了，顶礼膜拜呀！

    近段时间，项目处在联调与定型中，碰到不少调试问题，在不断的查找bug中，发现了条件编译、在线仿真的巨大好处，获益匪浅。于是，整理成一篇文章。
    刚刚再次深入了解了条件编译，发现条件编译不仅仅在调试上具有方便之处，用来控制版本的更新，也非常方便。比如，最近要更新硬件的开发环境，就可以用条件编译来控制底层驱动更新的变化与相应应用层的更新。
    初学者，面对技术这条大道，茫茫然看不到头，选择性多学习多总结，总会－－多点－－成线－－成面－－成体系成技术大牛。
    写在2017的第一篇文章，加油2017！