刚开始工作那几年，我一直用不习惯仿真器，费劲巴拉的，还不如直接看代码，或者用串口，数码管，屏之类的配合调试来得快。
之前有个老板，让我花几周时间，去搭建一个冷门芯片的仿真调试环境，让我很不解，有那时间，功能都做四分之一了。
随着做的项目越来越复杂，我越来越理解他的意图。
是因为我以前做的项目，太简单了，所以用不用仿真调试，关系不大，用了，反而有点累赘。
项目如果复杂了，程序细节多了，出现问题的概率就大了，这时候如果没仿真调试，一个小BUG，可能就要耗费几个小时，而用仿真调试，可能只要几分钟。
今天，就一对一跟特训营老铁，用仿真调试，去给他的程序定位和解决问题，前前后后也就花了几分钟时间。
事后我建议他，一定要掌握仿真调试能力，效率能提高很多倍。
他问我，像断点的打在哪里，有什么心得吗？有时候能仿真出来，有时候就有点一头雾水。
这个问题，哪怕一篇文章，也很难让大家马上能熟练掌握，因为这是经验，要靠积累的。
我其实也没什么奇技淫巧，纯粹就是用的多了，经验越来越丰富，定位问题越来越精准。
所以，核心还是多用Stlink之类的仿真调试，每碰到一个问题，都尝试用仿真调试的方法去定位和解决问题，我们特训营项目3和项目6完整做下来，基本就非常熟练了。
虽然没什么系统方法论，但我还是总结了几点心得，希望能给大家一点启发。
1.仿真调试除了找程序BUG以外，还有一个功能，就是你如果去修改别人的代码，看不懂程序运行流程的时候，可以借助仿真调试摸清楚。
2.仿真调试的前提，是理解程序的运行流程和逻辑，否则打断点就会无从下手，或者断点打的不够精准。
3.打断点时，我一般是先从硬件驱动程序开始排查，源头有问题，应用层程序怎么调都没用，举个例子，按键状态检测功能，如果检测不到状态，可能会有几个问题：
①.可能是按键检测功能程序写的有问题。
②.可能是外设驱动配置的有问题，引脚电平不能被正确检测到。
像这种问题，我首先会先在引脚电平检测的代码位置打一个断点，然后仿真调试看看，按下按键，是否能检测到正确的电平。
如果能检测到，再去应用层的按键功能检测代码打断点，不断缩小问题范围。
4.仿真调试时，如果一直找不到问题，或者感觉没问题，一定要有发散思维，不要把思维局限在某个功能上，有时候一个功能的BUG，可能是由另一个功能引起的。
5.一次性断点不能打太多，之前打多了keil会出现莫名其妙的问题，一般我是控制在4-5个以内，如果不够，仿真时可以一边加，一边删。
6.单片机进入低功耗，就没法用仿真调试了，如果是低功耗产品，可以调好所有功能，最后再加休眠功能。
7.以上这些看得迷迷糊糊，都无所谓，主要还是得多仿真调试，最好是项目，因为项目细节比较多，锻炼机会也多，这个能力特别重要，能提高产品开发效率。