单片机程序调试黑皮书

heicad

1、程序的确定性比硬件大，不要害怕程序问题。
2、写程序，最重要的不是学会某种语言，而是会分析问题并提出解决问题的方法。
3、含有中断的程序较为复杂，需要编写者清楚同一时刻，我在做什么，其他人在做什么，用“并发”的方式思考问题，才能写好。
4、程序模块化是为了编写而不是为了运行，模块化和函数是两个不同的概念，函数是为了将需要多次使用的代码统一编写，以便减少程序代码量，便于维护；模块化是指将复杂的程序功能化整为零而成的功能块，一个模块可能由多个函数组成，也可能就是一个函数，还有可能只是一段紧密相连的代码块。
模块---打开冰箱门
1、抬起右手，移动到冰箱门把中心右侧1cm处
2、弯曲右手手指，构筑冰箱门
3、以2kg的力量向后拉
4、完成
5、好的模块化设计，模块间的接口简单明了。总的来说，好看好改的程序就是好程序。
6、编写程序的好习惯是分模块编写，边写边测试，在通过测试的模块基础上编写下一个模块，可以减少程序出现问题的可能性，快速排除与问题相关的模块并定位到程序语句。
7、注释不是程序，但可以帮助编写者提高边写的可能性，也可以大大提高程序的可维护性。建议C语言程序注释到函数，一些重要的操作至少要注释；汇编语言程序，至少注释70%的语句行，建议一行一注。
8、程序有BUG是很正常的，要学会找BUG的方法。
9、故障分软硬，软故障最难找。软故障多源于设计临界所导致，在一定出发条件下发生，当条件破坏时，故障可能消失得无影无踪。
软故障的误导性来源于对硬故障的经验积累。硬故障因为无需出发条件，人们往往用
尝试---判断--再尝试
10、单片机软件和硬件密不可分，查找问题时要两者兵种，不可死认一方。
11、Debug高手和新手间的区别，高手知道该如何去找，而新手会迷茫。
12、平时就要注意积累。学习软硬件只是，还要熟悉自己的实际应用，包括应用条件，否则会对放在面前，对推理极有价值的关键现象视而不见。找BUG可以用“猜” 的方法，但是“猜”完了要推理到所有的现象上去“验证”。所以我们说“怀疑---否定---再怀疑---再否定，直到找到真理所在”，前面的“尝试--- 判断---再尝试”是找BUG的基本方法。
13、在BUG面前，新手和高手初始化状态是一样的，只是高手有意识去找现象用于分析，新手看着现象发呆罢了。
14、论据有两种获得方式---寻找和傻等，高手以寻找为主，新手以傻等为主。
15、随机对随机的方式是一种在查找小概率软故障时用得极端确认方法，需要使用者对故障的基本特征熟练掌握，明确“小概率事件很少发生”的原理。
16、当一个系统由若干个部分组成时，寻找故障的时候可以将怀疑引起故障的部分更换到其他系统上，通过观察故障现象是否随该部分迁移来判断BUG所在。
17、将精力集中在需要查找的部分，排除其他模块的影响，用最简单的方法去判断，这就是模块隔离法的价值所在。
18、发生时间相关性BUG，其分开测试正确，合并测试出错的特性往往让初学者抓狂，在调试含有中断的程序时，一定要多条思路，怀疑程序的时间相关性。
19、因为只有在实际运行时才会表现出来，时间相关性BUG比较难于查找，这也就是我们建议程序在实际环境中调试，而不是仿真环境下调试的原因之一，遵守基本规则编写程序是避免时间相关性BUG说呢之所有BUG的根源。多观察现象，积累判断依据是找时间相关性BUG的法宝。
以上为单片机教程网http://www.51hei.com 站长huqin在多年程序开发中总结的一些经验，虽然写程序很累，只要我们不断的积累经验不断的学习，乐趣自然在其中，当我们开发成功一个产品我想得到的不仅仅是一个产品，还有自豪和满足吧.程序员是一个有激_情的工作，希望我们都能继续写下去.

keil_c51

wxb7893212

有道理

lisingch

分析得不错。

heicad

最近在研究单片机登陆网站有没有志同道合的？

zl_123

分析得不错

xyr

有理，

nust_奔跑

学习了~学会分析错误~找出错误~慢慢成长为高手~努力~

wscf123

经验之谈啊

fiddly

精辟！

linucos

呵呵，好经验啊！