原创 再诡异的现象背后可能只是一个傻x的低级错误——谈调试心态

2012-6-13 21:33 1544 12 14 分类: 工程师职场

 

今天调试一个小模块,FPGA的24号引脚作为输入端,在此引脚上外部给一个恒定的0电平,理论上程序应该一直读为0电平,在开机的前10s,程序内部读取该引脚为0,可是10s后始终读取为1,而且问题可以重复再现。按照常规,首先检查24号引脚是否连接正常,粗看了一下,和外部的输入连接正常,再查看原理图,24号引脚的功能标注有两个,普通IO和RUP,这个RUP功能我之前从没用过,猜想可能是这个功能导致的,用户手册对RUP的解释是:作为近端端接时自动校准匹配电阻,此处省略一千字关于校准匹配的功能,关键是该引脚的上拉电阻只有50欧姆,"有可能是这个引脚上拉能力太强了把外部输入的低电平给拉高了吧?"我猜测到。。。。。于是接下来的一天,我的调试重点被这个看似神秘的RUP功能牵引到了分析24号引脚如何自动校准上去了,以为这应该和前面诡异的问题有关。
 
半天过去了....
 
一天过去了....
 
诡异的现象依然存在,实在没辙了,重新梳理了下思路,再从最基础的问题入手排查,再次怀疑24号引脚是否连接正常,结果着实让我崩溃-----的确是引脚连接错误,外部的输入信号连接的是27号引脚,而不是24号引脚,所有内部程序一直检测的是27号引脚的电平,而我一直在排查24号引脚。这么一个极其低级的错误,尽然耗费了一天的时间,让我陷入无限的自责和反省中。
 
工作几年了,排查的问题的一些套路早已熟烂于心,所以一开始,我就怀疑过引脚连接问题,不过当时只是粗看了一遍,漏网了,接下来就一直沉陷于那个神秘RUP功能的漩涡中。你可以将此简单的解释为“太粗心了”,然后告诫自己"没事,下次仔细点就ok啦,不要想太多了,早点去睡吧”。如果第一次碰到这种状况,这种告诫还可以平复我对时间浪费的愧疚感,可是细细回想起来,刚工作时这种状态很少出现,近年来,类似刻骨铭心的低级错误却渐渐的多了,“太粗心”的解释听起来更像是个自我安慰的借口,不能说我工作的后两年就变成马大哈了吧,应该是自己的调试心态在这几年里发生了一些微妙的变化——从惧怕问题,尽快解决问题,到享受问题的转变。
 
惧怕问题
 
刚进入公司,解决问题的心态尚不成熟 ,碰到问题的第一感觉是,怎么还有问题?对问题有着一种莫名的惧怕感,生怕不能按时完成,挨老大批,期望问题千万不要太难,尽快把它搞定吧,在这种速战速决的处理导向下,容易把问题想的过于简单,前期对问题假设判断也多是些低级错误,所以那时基本不会在低级错误上纠缠太多时间,基本都是秒杀,因为脑海里优先考虑的都是各种低级错误的可能,不过话也说过来,刚来时也缺乏经验,能想到的解决思路也只能是这些。
 
尽快解决问题
 
随着工作的深入,自己也多少积累了一些经验,将其归纳成了葵花宝典,由于自己资历尚浅,宝典里大部分的必杀技都源于老员工的经验之谈,自己总结的并不多。不过宝典的作用显著,手握宝典后,相比刚来公司,面对问题的压力感和惧怕感释缓了许多,但是工作任务依然繁重,每天都会解决很多问题,但又会碰到更多的问题,此时处理问题的心态转为:首先从自己的葵花宝典里搜寻既往的经验,招招试之,有时能一招制胜,有时碰到实在搞不定的疑难杂症,还得求助于老员工。这个时期,由于对葵花宝典的极度崇拜和严格执行,低级错误的根除也都不会花费太多时间,快速解决问题让我感受到了自信,但这只是一时的快感,由于事后缺乏对问题的反刍和进一步消化,快感消逝后,自己的知识库依旧空虚寂寞。
 
享受问题
 
渐渐的,我以不满足于这种浮光掠影式地处理问题所带来的快感,一个问题给你带来的成就感并不仅限于解决的那一刹,过程中,问题的来龙去脉,处理的思维导向等等都是可以值得去回味和思考的,能把这些彻底想明白之后的酣畅淋漓绝不亚于最终的那个结果。特别是调试中,发现了问题背后蕴藏的一些全新的知识点,过去的盲点,甚至厂家的bug,这些增值体验都让我倍加珍惜每一个问题,想一想能从调试一个问题收获这么多东西,你还惧怕问题吗?还图那尽快了之问题后的一时快感吗?现在调试问题的心态演变为:把每一个问题都当成一次全新探索的开始,不局限于葵花宝典里的那些有形的招式,设想多种的可能,尝试些无形的章法,入手解决,如果遇到任务加急的情况,先将调试中的疑惑点冷冻,待解决后,再从冰箱取出,慢火烹饪享用。习惯这样的调试心态后,自己的知识库一天天的丰富起来,开始也能独当一面,解决一些诡异难解的问题了。
 
又进入另一个误区
 
工作这几年,面对问题,从最初的惧怕到现在的享受,实现了华丽的转身,但这并不是转变的终点。当我带着“享受问题”的心态,具体执行时,发现自己又不小心走入了另一个误区。
 
我现在是把解决问题当作享用美食的过程,既然比作美食,就希望能将舌尖上的美食都尝个遍,吃完了这一顿,总期待下一次能有点不一样的,每天让你吃工作餐,总会反胃的那一天。虽然现在比以前更注重解决的思考过程,但过程中学到的新知识,找到的盲点可能才是自己真正的企图,调试的动机还是结果导向,只不过从“把问题搞定”这个结果变向了“要在解决过程收获知识”这个结果。遇到一个诡异的现象,更倾向于认为这背后应该又有一个诱人的知识点在等着我,结果是将问题想象化,妖魔化,而对低级错误的敏感度大大降低了,尤其当自己在一个问题上花费了很长一段时间时,多么期望自己长时间的付出能收获等额的回报啊—— 一个全新的知识点,往往此时,god就会下凡来给你一个玩笑—— 又一个低级错误...
 
当在兴庆自己调试心态的逐渐成熟——不再以完成任务,快速解决为最终结果时,自己又开始无意识的追逐起调试过程中的成就感,两者的通病都是目的性太强,容易对一个问题失去应有的客观判断,扰乱调试时的那份内心的平静,今天在引脚连接的低级错误上的纠缠,又一次印证了这种调试心态的弊端。
 
深究问题的习惯不可丢,但还得先放低姿态,弱化那些成就感,专注于调试本身,和手中的工作融合为一,保持内心的安宁,这应该是我下一步需要调整的心态。
PARTNER CONTENT

文章评论2条评论)

登录后参与讨论

用户377235 2012-6-19 18:49

超赞。博主是个很有心的人,工程师的各种心态都体验过,学习一下。

用户377235 2012-6-19 17:33

为什么不用示波器观察一下管脚的电平呢,沉迷于新的知识点,忘了调试的目的。
相关推荐阅读
用户419742 2016-06-16 11:06
【博客大赛】cache,你给我听话点
在上一篇“为什么程序越优化越慢?”里,详述了程序指令在cache里发生冲突后另运行效率变的完全不可预测的问题,并提出了两种将不老实的cache变乖的良方。本以为cache已经完全被驯服了,没过多久...
用户419742 2013-05-14 20:57
[博客大赛]程序为什么越优化越慢?
正在开发一个基于Nios II内核的项目,使用的开发环境是nios for eclipse,编译器是GCC,整体功能实现后,开始优化速度。默认没有开启gcc的优化选项,一段关键函数Key的运行...
用户419742 2012-06-02 20:07
【博客大赛】马克思教我们优化时序之补全if else
  时序优化中重要的一项就是提高模块的最高工作频率,工作频率由关键路径决定,通常的提高工作频率的步骤是:利用时序分析工具找到关键路径,分析关键路径主要延迟是布线延迟还是逻辑延迟,然后再轮番十八...
用户419742 2012-05-24 21:09
【博客大赛】TimeQuest约束外设之诡异的Create Generated Clocks用法
最近在altera FPGA里设计一个外设的驱动模块,模块本身逻辑很简单如下图所示,但是模块和外设之间的时序约束问题搞的很头疼,今天先讲讲总结的一些Timequest下外设约束方法,特别是那毫无用...
用户419742 2012-05-18 20:45
【博客大赛】TimeQuest之delay_fall clock_fall傻傻分不清楚
  这篇我想分享一个之前在用TimeQuest约束双边沿模块的input delay时犯得一个错误,有人看了可能会觉得傻傻的,什么眼神,delay_fall和clk_fall怎么会分不清呢,字...
EE直播间
更多
我要评论
2
12
关闭 站长推荐上一条 /3 下一条