谈谈我在研发生涯中碰到的甩锅侠

作为一个合格的研发工程师，不但要像斯图尔特·布兰德讲的那样：Stay hungry, stay foolish，还必须要有开放的心态，实事求是的精神。

以探索为乐的大部分研发工程师，他愿意拿出几乎所有的时间去探索未知，研究问题，这其实就是英文的RD的本意：

Research and Development engineer，研发工程师，对某种不存在的事物进行系统的研究和开发并具有一定经验的专业工作者,或者对已经存在的事物进行改进以达到优化目的的专业工作者。

不过，现在越来越多的RD，变得有些浮躁，缺乏Research的动力，也懒得Development项目，日常工作中更多地变成了design engineer，变成了单纯的“设计，绘制”项目。

越来越多的研发人员，失去了专研的精神，不再享受寻求真理的过程，碰到问题时动不动就找个借口，甩个锅，草草结案。

他们不愿意承认自己的设计缺陷，觉得“老子天下第一”，做得很棒，只要有问题，一定是别人的原因。

这其实是典型的婴儿思维：自己是全世界的中心，所有的对错真假都由自己的意志决定，这样的人注定成不了优秀的研发工程师，甚至不是合格的研发工程师，充其量只是一个甩锅侠。

下面就举几个例子。

我没错，一定是MCU设计缺陷：

我碰到太多的设计新人，费了九牛二虎之力，终于设计出一个可以动的Demo，但是发现偶尔关机电流偏大——正常情况下关机电流是几个uA，但是他设计出来的，有时候几个uA，有时候几十几百个uA。

几百个uA是什么概念？

一节碱性电池的电量一般是2000 mAH左右，如果是关机状态下500uA，也就是0.5mA时，电池能用
2000 / 0.5 = 4000小时。也就是关机状态下电池在半年以后就没电了。

问题倒是不大，但关键作为产品的父亲，研发工程师必须找出所有不确定的问题，才可能让自己的产品问题最少。

一个不负责任没有研究精神的工程师，面对这个未知的多出来的电流，在确认一些简单的可能性还找不到答案之后，往往会选择忽略：

虽然MCU的技术手册里面说休眠模式状态下的电流是1uA以下，但是，我们都知道，IC行业都有产品合格率问题，我现在碰到的这个关机休眠电流偏大的问题，应该就属于设计或生产缺陷。

肯定不是我的设计问题，因为硬件线路没有问题，我都检查过，该断电的都断了；如果软件程序有问题，因为休眠后程序停在固定的地方，没有道理有些电流大，有些电流小。

这一定是MCU的缺陷！！ 我竟然找到了原厂的设计缺陷！！！ 我好牛逼！！！！！！！

哈哈哈，每次我碰到这种问题，只能笑笑。

因为当初我也遇到过这种问题，我也认为自己比IC原厂的设计人员都牛逼——直到我的责任心驱使着我用示波器把MCU的引脚一根一根地量着来看。

这是我设计的一款产品的PCB图，IC的引脚如此细密，用示波器探头接触时手不能抖，眼不能花，一根一根量过来，没有责任心，是做不到的：

你会发现，在你用示波器探头量到某个引脚时，电流会减小，甚至于恢复正常。探头拿开，电流就又开始任性乱变了。

这可以用非常标准的科学原理来回答：
现在IC几乎都是复杂庞大的CMOS线路集成，而COMS管有一个特点：MOS管输入阻抗很大（栅极源极之间有一层氧化层），输入阻抗大，对微弱信号的捕捉能力非常强，所以悬空时很容易受周围信号的干扰。

CMOS电路有一个设计的原则，就是—— 任何输入口都不要悬空。

只要悬空，由于上述特性，就会造成MOS管的开关状态不稳定，从而引起IC消耗电流异常。

而没有经验的工程师，往往会让没有用到的MCU引脚空在那里，程序上又没有做任何处理，导致悬空引脚处于输入状态，引发异常。

看到没有？这就是经常被年轻人甩的锅，那些IC原厂，每年估计能够收到数以亿计的黑锅~~

---

还有一种是这样的：

我没错，一定是编译器/烧录器有问题：

上面说到，IC设计厂家经常会被冤枉，同样的，程序编译器，仿真器的提供厂家，下场也不会比窦娥好到哪里去。

相对来说，硬件问题比较容易确定，软件有bug的话，那可是千奇百怪，毫无规律可言了。

有些时候，bug很隐秘，同一批产品生产出来，有的始终没有问题，有的就经常出问题。

一个不负责任没有研究精神的工程师，如果碰到这种问题，一般会这样想：

肯定不是我的设计问题。如果是设计问题，这一批产品应该都有问题。而现在是A，B，C都很正常，只有D老是出错。

不是D用的元件有问题，就是D在烧录程序的时候，烧录器出错了，把程序给烧坏了。

有时候，重新烧录程序确实能解决问题，这就会更加坚定新手的信念——你看你看，重烧程序就好了，我就说是原来烧录过程中有问题么！

实际上，有些bug本就不是稳定规律地出现，可能是重烧程序以后，问题刚好没有出现而已。

以一个MCU测量信号周期/频率的例子来看：

从图上来看，MCU内部TIMER的第三次寄存器溢出发生在测量周期结束之后，因此在整个测量周期中，TIMER实际溢出了2次。

这里要介绍一个概念：

MCU的内部中断有好几种甚至于好几十种，这些中断是有优先级的，优先级低的中断，会被优先级高的中断打断，MCU优先处理中断优先级别高的中断服务程序。

上图中，因为中断1和中断2的时间间隔非常地短，如果中断2的优先级比中断1的优先级高的话，即使中断1实际是先发生的，但是程序优先处理了中断2，这样，在测量周期结束之后，程序判断TIMER溢出了3次。

就这样，实际的2次被记录成了3次，那么计算结果当然是错误的。

只是这样的问题发生的概率很小，不但和MCU内部程序周期有关，还和被测信号的频率有关，所以产品最终的表现就是不稳定，时好时坏，难以调试。

这种问题，就常常被新手甩给了编译器，烧录器等厂家，真的是六月飞雪啊！！！

结论：

这里只举了2个很典型的例子，一个硬件问题，一个软件问题。

我想说的就是：IC设计公司，和各种编译器/烧录器的设计厂家，特别是业界大厂，大公司，他们的研发能力相对于我们这些应用层面工程师的研发能力，高的不是一点点，有些差距可能要以“光年”来论。

设计了这么多年，我所看到的，听到的那些甩锅侠甩出的黑锅，99.99%都是自己的问题，和这些大公司毫无关系。

这是铁的事实，作为使用他们产品的研发工程师，只有保持虚心，保有责任感和清醒的头脑，严肃认真，大胆假设，小心求证，才能不停地打破自己的认知，求得最后的真相。

愿所有的研发工程师实事求是，不再当甩锅侠~~

---

希望喜欢我文字的人，去看看这个吧，说说对我的看法，请我吃星星

，谢谢啦~
我的 @ReviewMe 凭证留言板!

Posted using Partiko iOS