原帖 ｜ Jack ｜ 2025-01-08 12:42 ｜ 👍2 ｜ 阅读约1
嵌入式提问的技巧的视频下的粉丝回答：
小公司里面的工程师和刚毕业的大学生工程师，往往容易说出“烧录了程序后，LED怎么不亮？”这一类问题，并不是说他们故意不讲清楚，而是他们除了烧录之外，没做其他排查工作。
大学生还尚且可以解释为经验少，出现问题无从下手，可以理解，通过学习可以提升排查问题的能力。
但小厂里面，向你提问的人，一般都是想让你解决问题，而不是给他们提供技术支持，协助他们解决问题。比如我亲身经历的一个事：
A：主板出问题了，你技术比较厉害，你帮我解决一下。
你拿到问题后遇到的状况是：任何排查工作都没做，电压没量过，电流没测过，信号不知道，代码也不整理，所有代码全放在main里面，各种莫名妙的变量，串口接口也没接出来，芯片参数一问三不知，传感器不知道好坏。
你帮他调的时候他的话：你这里修改的代码我怎么看不懂？IIC这里1M电阻为什么改10k，不都是上拉吗？我以为这个工程不用串口输出数据，所以就没接？这些明明只是编译器的警告，又不是报错，不影响什么，为什么要改？这个函数是什么作用，我不知道呀，我只是copy过来的，能运行不就可以了吗？你刚刚说的那些话呀，我都记在脑子里了。
我在那里计算，验证，测试，他站在那里一个劲问，我一个劲回答和画图解释给他听，他点点头继续问。整个过程下来，我写了一整张纸，他说他记了一脑子知识。回过头来想想：我在干嘛呀？
所以这里也提供一些容易犯的禁忌：
(1). 如果是当面向别人请教问题，无论你觉得有没有必要，都请带一个本子，表明你是来讨教的，而不是来布置任务的。
(2). 你可以问一些很低级的问题，但你不能用“为什么不可以”“难道不可以吗”这种反问的方式，和“我以为某某某”这种听起来很主观臆断的答复。
(3). 别人在帮你的时候，不要走心，不要掏出手机看，哪怕没事干，光看着他就行。
(4). 别人说的话，解释的东西，哪怕再简单，拿支笔写下来，一是可以给人的感觉“”我的答复和解释没有白费口舌”，二是没人不喜欢上进的人，“你这个学生是在学习和进步的”。三是你的脑子其实远远不如你想的那么强大，好记性不如烂笔头。
(5). 同样的问题，如果你无意犯了第二次(一般表现为相同的异常现象，而你忘了上次如何解决的)，不要找同一人请教，会让人觉得你不思进取，同时你也该反思。
开发流程上：
任何软硬件的开发过程都不可能一帆风顺，往往都是经过模块功能设计——模块组装调试修改——PCB测试样板制作与程序烧录——功能上机试跑——样机组装与试用——小量试产——批量试产等等多道工序，每一个环节都可能出现问题，出现问题后，相比在线调试或者RTT，串口调试是最容易实现的情况下的最不容易出错的方案，是最有可能在以上全部流程的调试中都能派上用场的方案。
另外，对于偶发性故障，串口在不打断系统运行的情况下可以持续记录日志信息并报存在电脑端，也就是让系统一直跑，并用串口输出日志信息到PC端保存，持续跑一个月，从这一个月的日志中查bug。
消费类电子的开发基本离不开串口(串行通信接口)，设计者不应该一开始就自大的认为自己技术高可以抛弃串口，未来的事谁说的准呢？
我上面遇到的情况就是：他的BGA芯片使用jlink烧录程序，但芯片设计上或者PCB走线上存在问题，导致debug无法使用，jlink飞线直接连接芯片引脚所在线路，并降低通信速率后，点击debug后显示win7系统不支持。主板上没有实体led没有实体按键。
“因为串口用不到就没接”
“我又不能未卜先知，我要是早知道debug有问题，我肯定会接串口”
就这样，上帝给他关闭了一扇叫debug的门，他自己关闭了最后一扇叫串口的门，断送了所有调试接口(因为程序卡死，屏幕甚至都没来得及初始化，我后来是想到LCD背光本质上也是一颗led，用这颗led做调试排查出来问题的[笑哭]，别提多难受了)
相关笔记