调试心得——软硬兼施

有一本书叫《程序调试黑皮书》，作者也是学习单片机的，而且善于消除BUG，在书中曾经提到了几种调试方法，这里顺便总结一下：

3.1模块化测试：

在写程序的过程中，按照模块化的思想封装好每个模块，然后完成一个测试一个，这样做的好处就是及时发现问题，从而避免在整体运行时不能及时定位问题的麻烦。我发现最近的几次错误都会没做好这一步，导致后来整体运行时连定位问题都花费大量精力和时间，弄得身心疲惫TAT（最痛苦的不是如何解决问题，而是你不知道问题发生在哪里，隔靴搔痒！！）

3.2出入口测试：

在函数或者功能块中的出入口中，检查有可能出错的参数，相当于黑盒测试，关于软件的一些测试方法

3.3功能注释：

在每个功能块或者函数中添加注释，一些关键性的语句添加比较详细的注释，因为程序猿都知道，注释很重要！！我一直保持注释程序的习惯，先不说程序的可读性或者维护性，鬼知道若干年后的哪一天，你会对着一堆没注释的程序骂娘，结果发现原来是自己写的.........(每个被骂的程序都是由不负责的程序员写的)。

在注释的时候，本着几年后的自己都能看懂的想法去写，我写的程序基本上就是自己才会去看，所以不管如何，程序是写给自己看的，恩恩，我是这么想的。

问题有两种：硬件故障，软件故障。   

一般出现问题，我是先从硬件层面解决，因为只有你的硬件平台完全没问题了，才能进行软件层面上的调试。

基本上程序调试有如下方法：

1、keil软件仿真：通过 单步调试、IO口设置、内部资源设置 可以仿真大部分情况，发现程序中的一些明显的逻辑错误。 

2、keil、protues联调 ：结合proteus里的硬件仿真跟keil的单步调试，可以更加详细深入了解内部资源运行状况。  

附上 联调需要的驱动 联调配置 

3、外部信号表现：之前没有很清楚的使用这种方法，而且每次都是事倍功半，现在突然觉得方法论还真的挺重要的。

利用外部硬件的表现来跟踪程序和检查内部变量。如用得最多的LED，通过LED的闪灭可以反映变量数据或者程序的进度。

4、编程调试技巧：   利用“挖坑”方法——就是可能出现错误的地方设置一个判断，出现了不是预想的情况程序就掉入我们挖好的坑里，在坑里设置外部表现（如LED亮）

条件编译——调试之利器 - 以技术自娱的Geeker - 博客频道 - CSDN.NET

刚刚想起来，其实我的很多方法是看到了程序匠人的程序出错笔记后才知道的，后来不自觉就用了，现在贴出链接，强烈建议大家看看

[转载].程序匠人 - 程序调试（除错）过程中的一些雕虫小技 - COM张 - 博客园

（上面那个博客排版的挺好的，原来的匠人的帖子是程序调试（除错）过程中的一些雕虫小技（更新：2010-04-09）-书友会论坛 - 21ic电子技术论坛）