只会硬件不懂软件，调试时真的容易被坑吗？
很多公司软件和硬件是分开的，各干各的。一到联调的时候就容易扯皮，出了问题，软件说是硬件的锅，硬件说是软件的锅，互相甩来甩去。
你说你测了电压，3.3V稳得一批，纹波不到20mV，晶振波形也很漂亮。但单片机就是不干活。你第一反应是什么？软件没烧对？或者程序跑飞了？
可你一旦说出这句话，软件同事下一秒就会反问：“我程序在开发板上跑得好好的，怎么到你板子上就不行了？”
你看，球又踢回来了。而且他说的有道理啊，开发板能跑，说明程序逻辑没问题。那问题在哪儿？在他的程序适配你的板子时，时序、延时、上电初始化顺序，这些他可能根本没调过。 但你不能这么说，因为你不懂代码。
你看，这就是只会硬件的尴尬，你知道问题可能出在软件，但你拿不出证据。
怎么办呢？ 咱们换个思路。
既然你不懂软件的具体实现，那你就把硬件先扒干净给他看。什么意思？就是把所有可能的硬件疑点，用数据堵死。
说个简单的场景，单片机某个IO口电平不对，你觉得可能是什么问题？
一般情况下，咱们第一反应肯定是软件的问题，对不对？IO口输出高还是低，就是软件里配一下寄存器的事儿。但真就一定是他写错代码了吗？
万一这个IO口对地的焊盘虚焊了呢？程序让它输出高，但物理上根本没连上，你能测到个啥？万一旁边那个电容短路了呢，IO口直接给拉到地了，软件再怎么配也拉不上去啊。还有更常见的，这颗芯片的IO口烧了呢？ESD打坏了，你写再多代码它也变不了高电平。
所以你看，IO口不对，不一定是软件的问题。先拿万用表戳一戳对地阻值，看看焊没焊好，再量量相邻引脚有没有连锡短路。把硬件扒干净了，再说到底是他的问题还是你的问题。
再往深了说，其实只会硬件最大的坑，不是被甩锅，而是你失去了预判问题的能力。
很多硬件问题，在画图阶段就能被软件救回来。比如软件把主频降一降，或者把大电流外设的启动顺序错开，板子也能凑合用。但你如果不懂软件的运行逻辑，你就不会在画原理图时为这些软件可调的参数留有余地。你只会照着参考设计硬搬，最后板子调不出来只能飞线。
之前遇到过CODEC音频无输出的情况，这种时候怎么查？我是这么干的，对照数据手册，用示波器把各CPU时钟输出挨个戳一遍，看频率对不对，再瞅瞅数据信号正不正常，一步一步排除。
你不懂软件没关系，但你得知道软件跑起来之后，硬件上应该产生什么结果。用硬件的测量结果去反推软件的执行结果。告诉软件，我不会写代码，也能验证代码跑得对不对。
所以最开始的问题：只会硬件，调试时是不是容易被坑？
我的回答是：如果你只把自己当成画板子的，被坑就很正常了。因为你在等别人给你答案。但如果你把自己当成系统级硬件工程师，你用硬件的手段去解剖软件的行为，那坑就不存在了，因为你能把每一个现象都量化成电压、时间、频率。 这些物理量是骗不了人的。
再退一万步说，真到最后查出来是硬件问题。比如电容焊错了，封装画反了，别赖，认栽，赶紧改，下回长记性。
找问题的时候不分软硬，但承认问题的时候要分得清轻重。 硬件的错，改板子，两周；软件的错，改代码，二十分钟。这个事实你得认，所以硬件工程师必须比软件更细心，更谨慎，更多疑。
好了，今天的分享就到这里了，咱们下期再见。
