程序调试(除错)过程中的一些雕虫小技

一、前言调试程序，是软件开发过程中的一个必不可少的环节。

这篇帖子，匠人试着来整理一下一些调试的技巧。

说到“技巧”，这个词自从被所长批臭之后，匠人就吓得不敢再提，生怕一不小心就暴露了思想的浅薄和眼光的局限，呵呵。

所以咱们不叫“技巧”，干脆低调点，就叫“雕虫小技”吧。

这里所讨论的“调试”技巧，有些是必须结合开发工具本身的功能来实现，而有些可以通过烧录芯片来验证。

各种开发工具，提供的功能多少强弱也不尽相同，这些方法也未必都能套用。

仅供参考吧。

最后说明一下，这是没有草稿的帖子，匠人仍然以不定期连载的方式，边写边发边改。

可能结构会比较混乱。

欢迎大家一起参与讨论。

二、磨刀不误砍柴功在调试之前，需要掌握以下一些基本功：1、熟悉当前的开发（调试）环境，比如：设置断点、单步运行、全速运行、终止运行，查看RAM、查看堆栈、查看IO口状态……总之，要熟练掌握基本操作的方法，并深刻了解其中意义。

2、了解芯片本身的资源和特性。

3、了解一点汇编语言的知识。

（本来匠人是准备写“精通”的，但考虑到现状，还是“放低”这方面的要求罢了）。

4、掌握基本的电路知识和排错能力。

（软件调试有时也会牵涉到硬件原因。

总不能连三极管的好坏都不能识别吧？）5、万用表、示波器、信号发生器……这些工具总该会用吧？6、搜索、鉴别资料的能力。

（内事问百度、外事问古狗、有事没事上21ic网）7、与人沟通，描述问题的能力。

（调试36计的最后一计——就是向他人讨教。

当然，你得把话说明白才行）差不多了，如果上述7把砍柴刀磨好了，就可以开始调试了。

接下来，请调入你的程序……——什么？你说你程序还没写？——匠人倒塌……三、优先调试人机界面面对程序中的一大堆模块，无从下手是吗？好吧，匠人告诉你，先调显示模块，然后是键盘。

为什么要先调显示模块？道理很简单，我们说“眼睛是心灵的窗户”，同样，“显示是程序的窗户”。

一旦把显示模块调试好了，就可以通过这个窗口，偷窥（天呐，这两个居然是敏感字！）程序内部的数据和状态了。

然后紧接着，就是调试键盘模块。

有了这个按键，我们就可以人工干预程序的运行了。

——什么，你的程序没有显示和按键？——这位童鞋，你真不幸，请去检查一下自己的人品和星座运程先。

谢谢。

实在是没显示？再看看系统有蜂鸣器吗？如果侥幸有的话，也能凑合着发发提示声音吧？或者，有串口吗？可以考虑借助PC 端的串口调试软件来收发数据，这也是一个间接的人机交流方法。

总而言之，要尽快建立人机交流界面。

（未完待续）四、给程序安装个黑匣子某年某月的某一天，一架飞机以优美的抛物线形状，一头栽到海里去了……几天后，人们找到了飞机的黑匣子，里面记录了飞行员的最后一句话：“天呐，我看到火星人了！……”以上空难情节我们经常会通过新闻看到吧（当然，最后一句是匠人版的科幻情节）。

看看，飞机的黑匣子可以记录并再现现场，多么神奇！欧耶！我们在调试程序时，也可以借鉴这个方法，给程序按装一个黑匣子。

程序中的黑匣子其实就是一个在内存中开辟的队列。

队列的原理我们很清楚，先进先出，后进后出（与飞机黑匣子的特性相同）。

比如说吧，假设我们的系统在工作中，某个输入量的采样值经常受到不明原因的扰动。

我们要摸清这种扰动的规律，以便对症下药。

但是这种扰动稍纵即逝。

我们的困扰是：程序正常运行时看不出规律，单步走又难以捕捉扰动。

怎么办？有没有办法，把扰动记录下来？当然可以。

我们可以利用系统里剩余的RAM，开辟一块单元，做成队列。

并写段测试程序，定时把新采样值压入队列。

然后我们让程序运行，在需要的（任意）时刻，让程序停下来。

这时，队列里记录的就是最新一批采样数据。

只要队列的深度足够大，我们就可以找出扰动的规律来。

——什么，你问我什么叫队列？——匠人曰“天呐，我看到火星人了！……”（未完待续……）也谈程序“鲁棒性”magicchip 发表于 2008-2-1 1:24:00 0推荐N年前，匠人曾经在“侃单片机”论坛里发起过一次关于软件抗干扰的讨论。

其实，当时的讨论基本上已经达到了软件所能做的一切范畴。

但是随后，讨论的方向逐渐转向了“软件抗干扰是否有实际意义”上去了。

虽然匠人坚持认为软件在抗干扰方面可以有所作为。

但是，来自反面的意见，也让匠人深思了许久。

世纪轮回。

这次，由emailli网友发起的“建议做为2008年1月的专题----软件抗干扰的方法研究”，又把当年的讨论场景再现。

别具意味的是，对软件抗干扰本身的置疑也被再次提出。

从某种意义上来说，随着单片机硬件抗干扰性能的越来越完善。

软件在此方面的用武之地，似乎确实在萎缩。

试问又有几个单片机程序中应用到了软件陷阱呢？比例恐怕很小吧。

然而，匠人最近有事没事，经常喜欢在同事面前卖弄这个词——“鲁棒性”。

鲁棒性robust[rEJ5bQst]adj.强壮的；健壮的His robust strength was a counterpoise to the disease.他身体强壮抵住了这疾病。

粗野的，不文雅的（玩笑）什么叫“鲁棒性”呢？按匠人的理解，就是，你的程序是否把所有的因素（包括异常因素）都考虑进去了，并且对可能的异常因素采取的规避、补救措施。

比如：1、我们要让一个变量做递增运算，每次+1，达到某一个阀值时清零。

那么你在做阀值判断时，是判“等于”，还是判“大于等于”？（正确答案：判“大于等于”）2、我们要根据一个变量去查表，或散转，假设这个变量正常范围=0~7。

那么你有没有考虑过，如果该值大于7后，程序该怎么办？（答案：先屏蔽（剔除）无效值，再去查表，或散转）3、我们要让某个IO口输出“高电平”去驱动外部电路（比如说，继电器）。

那么你是否只输出一次“1”就认为完事了？（答案：开辟输出缓存，定期刷新输出口）4、串口接收数据，假设收到“0X00”时执行动作A，收到“0X01”时执行动作B。

那么，你有没有考虑过，如果收到的是其他数据，该怎么办？（答案：参考第2例）这样的例子不胜枚举，每一个细节中都存在陷阱。

如果在程序设计中予以考虑，则可以规避；否则，很难说你的程序运行过程中会发生什么事情。

因此，一个好的程序，定义应该如此：“在正常情况下，可以得到正常的结果；在异常情况下，可以得到意料中的结果。

”而不是：“在正常情况下，可以得到正常的结果；在异常情况下，得到不可意料的结果。

”匠人的一些同事（新手）往往会跟匠人来犯犟。

强调曰：“我的程序没有BUG啊，是输入不正常导致的。

”，云云。

确实，这些细节上的疏忽，不能称为BUG。

我们只能称之为“鲁棒性”差！再扩展开来看，在整个系统中，不光是软件需要考虑“鲁棒性”，硬件也同样需要考虑。

举个例子：假设系统工作电压为5V，那么当电压低于5V时，会发生什么事情？考虑过吗？OK，你说你有复位电路，电压跌落时会复位。

那么匠人再问：电压快速跌落时可以复位，但如果电压缓慢下降，你的复位电路还能正常工作吗？或者，电压波动时，又会如何？这样的细节还有很多，贯穿在整个设计过程中。

对于有准备的人来说，只要事先预想到了并采取规避措施，都不是问题。

对于没有准备的人来说，调试将是一场艰苦的跋涉。

因为前进的道路上，“坑”太多了，指不定在哪里跌倒。

以上，为匠人信口开河。

欢迎探讨。

五、在程序中设卡伏击，拦截流窜犯警察抓流窜犯的场面我们都很熟悉了。

一般的方法，就是以案发现场为中心，在犯罪分子逃窜的必经路口，设卡盘查。

有道是天网恢恢疏而不漏，叫你插翅也飞不过去。

有时，程序中也会出现这样一个“流窜犯”，它就是PC指针。

对于一个未经调试的不成熟的程序来说，导致PC指针跑飞的因素很多，我们逐条列举并分析之：1、电磁干扰（如果不是在现场，那么这一条可以暂时不考虑。

因为在调试环境下一般不会有干扰）；2、程序结构错乱（喜欢用jmp或goto类指令的尤其要注意这点）；3、堆栈溢出或错乱，导致PC指针出错；4、PC指针被错误改写（有些芯片PC指针存储单元和其它RAM单元的访问方法是一样的，很容易被误写）；5、数据错误，导致程序没有按照预期路径运行；6、看门狗溢出（原因一般是因为看门狗设置不当、喂狗不及时、程序堵塞或者程序死循环）；7、中断被意外触发；8、外部电路问题，比如电源不稳等等；9、其它……当我们开始怀疑PC指针时，我们首先要做的是确认PC指针是否跑飞了，其次要找到PC指针跑飞的证据。

我们可以在不同的分支路口，或者在我们怀疑的地方，设立断点，看程序是否走了不该经过的路径。

举个例子，比如我们怀疑程序运行中看门狗发生了溢出复位，那么很简单，我们只需要在初始化入口设立一个断点，让程序运行。

正常情况下，程序只会经过一次该断点。

如果再次经过该断点被拦截，那么我们就可以初步确诊“看门狗发生了溢出复位”。

再举个例子，比如程序中某个环节有A、B两个分支，正常时只走A分支，不正常时才走B 分支。

那么我们可以在B分支设立断点，程序一旦异常，走入B分支，就可以被拦截下来。

程序被拦截下来后，我们可以勘察现场，查看RAM区内容和程序刚走过的路径，从中分析导致程序PC指针错乱的原因。

当然，并不是每一次伏击守候都能一举擒获流窜犯（敌人是“狡猾”的，呵呵）。

这就需要我们多一份耐心和技巧。

通过不断调整断点位置来改变拦截地点。

逐渐逼近并找到根源（流窜犯的老巢），然后一举拿下。

（未完待续，喜欢就顶）六、向猎人学习挖坑设陷阱的技术上一回说到，在程序中设卡（断点），可以拦截流窜犯（程序流程错误）。

实际上，断点的功能可强大了，不但可以拦截程序流程错误，也可以拦截数据错误。

当然，这需要一些辅助手段。

还是以前面提到的一个例子来说。

比如某个采样值（当然，也不一定是采样值，在这里也可以是RAM中任意单元中的值）受到未明因素影响，经常“乱跳”。

这种数据出错的原因，可能如下：1、计算错误（比如溢出），导致结果出错；2、被其它程序段误改写；3、其它原因……当数据出错后，我们希望能够在最快时间内，让程序停下来，这样才能有效查出是哪一段程序出了问题。

有些调试环境本身可以捕捉数据错误，并产生断点中断。

这当然最好不过。

但是如果调试环境本身不提供这种捕捉功能，那么就需要我们自己来制造机关了。

看看猎人是是如何做的：他们会在猎物经过的地方，挖个坑，上面盖上浮土。

当小型动物经过时，浮土不会塌陷。

而当体重较大的动物经过时，它们的体重就会压垮浮土，掉进猎人的陷阱。

猎人的这个陷阱机关，妙就妙在是它“智能”的，会根据动物的体重进行筛选。

轻巧的小白兔来了——放过，笨重的大狗熊来了——捕获！欧耶！好了，回到程序中来，假设我们要监控的那个RAM单元，正常值域为0~9；那么我们可以写一段测试代码，判断数值是否>9，根据判断结果执行两个分支，并在那条错误的分支路径上设置断点。

如果数据没有出错，程序会一直运行（小白兔请放心过去）；直到数据错误发生，断点会自动停下来（大狗熊给我拿下）。