干了这么多年嵌入式，我最后悔的几件事

大家好，我是仲一。

整理东西翻出刚入行时的笔记本。上面全是寄存器地址、时序图、各种命令。翻了几页，那时候是真有热情，但有些事现在看，确实走了弯路。

写下来算个记录吧。如果你刚入行或者还在读书，也许能少踩几个坑。

后悔一：头两年只看代码，不看原理图

刚工作的时候，我总觉得软件工程师就该只搞软件。拿到新板子就问硬件同事要 SDK 和 demo，原理图基本不翻。

有一次调 I2C 设备，从机一直不回 ACK。我在软件上查了两天——时钟极性、传输速率、驱动加载顺序，能试的都试了。没用。

后来硬件同事过来看了一眼原理图，拿万用表量了两分钟，说了一句我现在都记得的话：

这个 Pin 的上拉电阻没焊。

从那以后，凡是涉及到外设的问题，我都会先看一眼原理图。确认电源、上拉、电平匹配这些基础的东西没问题再动软件。统共花不了十分钟，能省好几天排查时间。

嵌入式开发和纯软件不一样的地方就在这里——你绕不开硬件。不一定非要会画板子，但一定要能看懂原理图。很多软件问题的根在硬件上，反过来也一样。

后悔二：笔记记了一大堆，但没有体系

我习惯遇到问题记笔记。几年下来攒了几百篇记录：某天怎么配 UART DMA、某个内核编译报错怎么处理、某个芯片的勘误注意什么。

记的时候觉得挺充实。过半年回去看，完全想不起来当时怎么写的。有些问题甚至踩了两次——第一次记了，第二次忘了自己记过，又查了一遍。

后来我发现效率高的人跟我记笔记的方式不一样。他们不是记录，是在建索引。一个问题搞定了，不只记答案——还记怎么查出来的、用了什么命令、背后的原因是什么。下次遇到类似问题，脑子里能跳出排查链路，而不是一个孤立的命令。

我现在改成按子系统整理笔记。比如"调试工具"一个目录，从 OOPS 信息解读到 ftrace 到 kdump，串成一条线。不再是今天记一条 strace 用法，明天记一条 perf 命令，各管各的。

后悔三：不敢拆别人的代码

刚工作的时候拿到一份老代码，宏的嵌套、结构体的套娃，看着就头疼。第一反应是"这代码写得真烂"，然后绕道走了。

现在回头看，应该问的是：这段代码为什么长这样？哪些是自己没看懂的设计？看起来很丑的部分，有没有在解决什么实际问题？

后来跟一个做驱动的前辈做项目，他每次提交的代码，命名、错误处理路径、注释位置，像同一个模子刻出来的。我问他怎么做到的，他说他早期把内核里某个驱动源码抄了三遍。

不是读，是抄。一行一行抄，边抄边想为什么这么写。

代码很多时候不是看会的，是写会的。抄过、改过、跑过、崩过，下次遇到自然就知道怎么处理。

后悔四：太晚意识到英语的重要

做嵌入式 Linux，好一点的资料基本全是英文的。芯片手册是英文的，内核邮件列表是英文的，Stack Overflow 上高质量的回答也是英文的。现在调芯片驱动，第一件事就是翻 Reference Manual，全英文，动辄好几百页。

中文博客不是没有好东西，但搜到的很可能是一手的、不完整的、甚至过时的信息。芯片勘误表更新了，中文博客不会跟着更新。内核版本迭代了，中文教程不会跟着改。

我现在遇到不熟的芯片，官方文档翻一遍，比自己瞎搜一堆中文笔记管用得多。

后悔五：太晚建自己的 demo 平台

前两年做项目都是基于公司开发板。能跑，但每次换平台就要重新搞一遍环境。后来自己花了几百块买了一块二手的 i.MX6ULL 板子，周末折腾。从 U-Boot 移植到内核编译到驱动加载，完整走了一遍。

走完这一遍，对启动流程和系统构成的理解，比看半年书都深。

自己折腾的好处在于：一是没压力，崩了大不了重刷；二是能接触到公司项目里不会遇到的分支——比如从零移植内核、从头写驱动框架。这些看起来用不上的东西，恰恰是理解系统最缺的那块拼图。

说来说去，嵌入式开发别把自己框死在代码里。原理图要看，硬件同事要多聊，英文文档要硬读。笔记要有体系，代码敢拆。

这些事都不难，难在早点开始做。

你在嵌入式路上踩过最大的坑是什么？留言说说，给后面的同学提个醒。