1. 为什么说嵌入式工程师都是柯南干了八年嵌入式我越来越觉得这行跟侦探没什么两样。一个Bug摆在面前现象就是“尸体”日志就是“现场痕迹”你得从一堆看似无关的线索里推理出真凶到底藏在哪一行代码、哪一个寄存器、甚至哪一根走线上。标题说“嵌入式工程师都是柯南”真不是自嘲是写实。嵌入式开发和纯软件开发最大的区别在于纯软出问题你至少有完整的调用栈、有core dump、有断点随便打。嵌入式呢板子跑飞了串口可能都没输出JTAG可能连不上你手上只有一块发热的芯片和一个“昨天还好好的”的传说。这时候你靠什么靠逻辑推理、靠经验直觉、靠对系统每一层的理解一层一层缩小嫌疑范围最后精准定位。这篇文章我想聊的就是这套“破案”方法论。不管你是刚入行的嵌入式新人还是干了几年还在跟Bug搏斗的老兵我都会把我在Linux嵌入式开发中积累的故障分析思路、常用命令、排查套路尽可能完整地摊开来讲。涉及Linux常用命令、内核日志分析、硬件接口调试、进程与内存问题定位这些核心场景也会穿插一些真实的“破案”案例。目标很简单让你下次面对一个诡异Bug时不再靠玄学重启而是有一套可复用的推理路径。2. 破案前的现场保护与信息采集2.1 第一反应决定破案效率很多新手遇到问题的第一反应是“重启试试”。我理解这种冲动但在嵌入式领域重启等于破坏现场。你想想柯南到了案发现场第一件事是把所有东西复原一遍吗当然不是他先观察、先记录、先保护证据。嵌入式系统跑飞之后最宝贵的信息往往在易失性存储里——寄存器状态、内存残留、内核环形缓冲区里的最后几条日志。你一断电这些全没了。所以我的习惯是只要系统还能响应哪怕只是部分响应先别动电源先把能抓的信息抓下来。具体来说我会按这个优先级采集信息串口输出如果串口还有输出立刻打开终端软件开始记录哪怕只是乱码也有价值。乱码本身可能说明波特率变了或者时钟出了问题。内核日志如果系统还能登录第一时间执行dmesg /tmp/dmesg.log把内核环形缓冲区的内容保存下来。这个缓冲区大小有限新的日志会覆盖旧的晚了就没了。进程状态ps aux /tmp/ps.log保存当前进程快照看看有没有僵尸进程、有没有CPU占用异常的进程。内存信息cat /proc/meminfo /tmp/meminfo.log和cat /proc/slabinfo /tmp/slabinfo.log内存泄漏和内核对象泄漏的重要线索。网络状态如果涉及网络netstat -anp /tmp/netstat.log和ip addr /tmp/ip.log也一并保存。这些操作加起来不超过三十秒但可能就是破案的关键。我踩过的坑是有一次系统偶发死机我重启之后再也复现不了后来才知道是某个驱动在特定时序下会踩内存而那个时序跟开机时长有关。如果当时保留了现场可能半天就定位了结果花了两周才重新构造出触发条件。2.2 日志系统的搭建与使用说到信息采集就不得不提日志系统。嵌入式Linux里最常见的日志方案是syslog或者rsyslog但在资源受限的板子上很多人直接用printk往串口打。这两种方式各有优劣我的建议是分场景使用。printk的好处是简单直接不需要额外的守护进程而且可以在系统还没完全启动起来的时候就用。坏处是日志级别混乱、没有时间戳除非你配了、输出量大了会阻塞系统。我一般会在驱动调试阶段大量使用printk但产品化阶段会把它收敛到关键路径上。syslog的好处是日志有级别、有时间戳、可以远程发送、可以轮转。坏处是需要配置而且如果日志量太大写flash会伤存储。我的做法是在板子上挂一个tmpfs分区专门放日志重启就丢但运行期间可以随便写。需要持久化的关键日志再单独处理。这里有个实操细节printk的日志级别和syslog的级别不是一一对应的很多人会搞混。printk的级别是0到7数字越小优先级越高。KERN_EMERG是0KERN_DEBUG是7。你可以在/proc/sys/kernel/printk里看到当前的控制台日志级别和默认日志级别。如果发现某些printk打不出来先检查这个文件。cat /proc/sys/kernel/printk # 输出类似4 4 1 7 # 第一个数字是控制台日志级别只有优先级高于这个值的才会打到控制台 # 第二个数字是默认消息日志级别 # 第三个是最低控制台日志级别 # 第四个是默认控制台日志级别如果你想让所有printk都打到控制台可以这样echo 8 /proc/sys/kernel/printk但注意这会让日志量暴增可能影响系统实时性。调试完记得改回去。2.3 硬件层面的“不在场证明”软件层面的信息采集很重要但嵌入式工程师不能只盯着代码。很多时候Bug的根源在硬件。电压不稳、时钟抖动、信号完整性差、温度漂移这些都会表现为软件异常。所以破案的时候硬件排查是必不可少的一环。我一般会先确认几个基本问题电源纹波是否在允许范围内晶振频率是否准确复位信号是否干净这些用示波器一测就知道。如果手头没有示波器至少用万用表量一下关键电压点。还有一个容易被忽略的点地线。我遇到过好几次系统偶发死机最后发现是地线没接好导致信号参考电平漂移。这种问题在实验室里可能不明显一到现场就各种诡异现象。所以如果你的板子有多个接地点确保它们都可靠连接。另外温度也是个大变量。有些芯片在低温下时序会变慢高温下漏电流会增大。如果你的产品要在宽温范围内工作高低温测试是必须的。我习惯在-40度和85度各跑一遍压力测试很多常温下隐藏的问题会在这时候暴露出来。3. 从现象到本质的推理链条3.1 现象分类与初步判断嵌入式系统的故障现象千奇百怪但大致可以归为几类系统完全不启动、启动到一半卡住、运行中死机、运行中重启、功能异常但系统还活着、性能下降。每一类现象对应的排查方向不同先分类再动手能省很多时间。系统完全不启动串口没有任何输出电源指示灯可能亮也可能不亮。这种情况优先查硬件供电是否正常、复位电路是否工作、启动模式引脚是否正确、晶振是否起振。如果硬件没问题再考虑bootloader是否损坏。启动到一半卡住串口有输出但停在某个位置不动了。这时候要看最后一条输出是什么。如果是内核启动阶段卡住可能是设备树配置有问题、驱动初始化失败、根文件系统挂载失败。如果是用户空间启动卡住可能是init脚本有问题、某个服务起不来。运行中死机系统突然不响应串口也没输出。这种最麻烦因为现场信息最少。我的经验是先看门狗有没有触发。如果看门狗触发了说明系统确实死了如果没触发可能是某个高优先级任务霸占了CPU导致其他任务饿死。运行中重启系统自己重启了。先查重启原因寄存器很多SoC都有这个功能能告诉你上次重启是上电复位、看门狗复位、还是软件复位。然后查内核日志里有没有panic或者oops。功能异常但系统还活着比如网络不通、串口不收数据、某个外设不工作。这种相对好查因为系统还在你可以用各种工具去探测。性能下降系统变慢、响应延迟变大。这种通常是资源问题CPU占用高、内存不足、IO瓶颈、中断风暴。3.2 二分法与排除法实战分类之后下一步是缩小范围。我最常用的两种推理方法是二分法和排除法。二分法的思路很简单把系统分成两半先确定问题在哪一半。比如系统启动卡住你可以先确定是内核之前还是内核之后。怎么看看串口输出。如果连bootloader的输出都没有那问题在bootloader或者更早如果有bootloader输出但没有内核输出问题在内核加载阶段如果有内核输出但没有用户空间输出问题在内核初始化或者根文件系统。排除法更适合功能异常的场景。比如网络不通你可以按OSI模型从下往上排除物理层网线插了吗、PHY芯片工作吗、数据链路层MAC地址对吗、自协商成功吗、网络层IP配了吗、路由对吗、传输层端口监听了吗、应用层服务起来了吗。一层一层排除很快就能定位。我举个真实的例子。有一次一块板子网口不通我按这个思路查先看PHY芯片的LED发现link灯不亮说明物理层就没通。换网线、换交换机都没用。后来用示波器量MDIO总线发现时钟信号幅度不对只有1.2V正常应该是3.3V。查原理图发现MDIO的上拉电阻焊成了10K而总线电容又比较大导致上升沿太慢。换成1K之后问题解决。这个案例里如果一上来就查TCP/IP协议栈可能一天都查不出来。3.3 时间线分析法还有一种很有效的方法是时间线分析法。把故障发生前后的所有事件按时间顺序列出来看看有没有相关性。比如系统每运行24小时就重启一次那可能跟某个定时任务有关比如每次插拔USB设备就死机那可能跟USB驱动或者电源管理有关。时间线分析的关键是精确的时间戳。如果你的日志没有时间戳赶紧加上。内核日志可以用printk的KERN_DEBUG级别配合dmesg -T显示时间戳。用户空间日志可以用syslog的时间戳。如果精度不够可以在关键路径上加ktime_get()或者clock_gettime()打点。我遇到过一个案例系统每隔一段时间就丢一帧串口数据。查了很久没头绪后来把串口中断和系统定时器中断的时间戳都打出来发现每次丢数据都发生在系统定时器中断处理时间超过某个阈值之后。原因是定时器中断处理里有一段代码关中断时间太长导致串口中断被延迟FIFO溢出。把那段代码优化之后问题解决。如果没有时间线分析这种问题很难定位。4. Linux嵌入式常用破案工具与命令4.1 系统状态侦查命令Linux给了我们很多现成的“侦查工具”关键是要知道什么时候用什么。我按使用频率排个序这些都是我几乎每天都会用到的。dmesg是第一个要掌握的。内核的所有打印都在这里包括驱动初始化、硬件探测、错误报告。常用参数dmesg -T显示人类可读的时间戳dmesg -l err只看错误级别dmesg -w实时跟踪。dmesg -T | tail -50 # 看最近50条带时间戳的内核日志 dmesg -l err,crit,alert # 只看错误及以上级别 dmesg -w # 实时监控内核日志top和htop看CPU和内存占用。嵌入式板子上可能没有htop但top一般都有。重点看几个指标%CPU里sys和usr的比例%MEM里哪个进程占得多load average是否超过CPU核心数。free看内存使用。注意buff/cache那一列Linux会把空闲内存拿来做缓存所以free少不代表内存不够。真正要看的是available那一列。free -h # 关注 available 列这才是应用程序真正能用的内存vmstat看系统整体状态。vmstat 1每秒刷新一次重点看r运行队列长度、b阻塞进程数、si/soswap换入换出、us/sy/idCPU时间分布。iostat看IO状态。如果系统变慢先排除是不是存储IO瓶颈。iostat -x 1看每个设备的%util和await。netstat或ss看网络状态。ss -tulnp看所有监听的TCP/UDP端口和对应的进程。lsof看文件打开情况。lsof -p pid看某个进程打开了哪些文件lsof /dev/ttyS0看谁占用了串口。4.2 进程与线程问题定位进程相关的问题主要有几类进程卡死、进程崩溃、进程占用资源过高、进程间通信异常。进程卡死先用ps看进程状态。D状态是不可中断睡眠通常是等IOR是运行S是可中断睡眠T是停止Z是僵尸。如果是D状态说明在等IO可能是存储或者网络出了问题。如果是R状态但CPU占用不高可能在等锁。ps -eo pid,ppid,stat,pcpu,pmem,comm | grep -v \[ # 查看所有进程的状态、CPU、内存要看进程在干什么用strace。strace -p pid附着到运行中的进程看它正在执行什么系统调用。如果进程卡在某个系统调用上一眼就能看出来。strace -p 1234 -T -tt # -T 显示系统调用耗时-tt 显示时间戳如果strace不够可以用gdb附着上去看调用栈。嵌入式板子上可能没有gdb但可以在开发机上用交叉编译的gdb配合gdbserver。# 板子上 gdbserver :1234 --attach pid # 开发机上 aarch64-linux-gnu-gdb (gdb) target remote board_ip:1234 (gdb) bt线程问题用top -H -p pid看每个线程的CPU占用或者ps -eLf看所有线程。如果某个线程CPU占用100%用gdb附着上去看它在执行什么。4.3 内存问题排查套路内存问题是嵌入式Linux里最头疼的一类因为现象往往很随机而且定位困难。常见的内存问题有内存泄漏、内存越界、内存碎片、OOM。内存泄漏的排查思路先确认是不是真的泄漏。用free看available内存是否持续下降用cat /proc/meminfo看MemFree和MemAvailable的变化趋势。如果确认泄漏再定位是哪个进程泄漏。# 每隔一段时间记录一次内存信息 while true; do date /tmp/mem.log cat /proc/meminfo | grep -E MemFree|MemAvailable|Slab|SReclaimable|SUnreclaim /tmp/mem.log sleep 60 done如果Slab里的SUnreclaim持续增长说明内核对象泄漏通常是驱动的问题。如果某个进程的RSS持续增长那就是用户空间的内存泄漏。用户空间内存泄漏可以用valgrind查但嵌入式板子上跑valgrind比较重。轻量级的方法是mtrace或者自己在malloc/free上加钩子。内核内存泄漏用kmemleak。内核配置里打开CONFIG_DEBUG_KMEMLEAK启动后echo scan /sys/kernel/debug/kmemleak然后cat /sys/kernel/debug/kmemleak看报告。内存越界是最难查的因为可能踩了别人的内存但当时不报错过很久才出问题。KASANKernel Address Sanitizer是利器但需要内核支持而且性能开销大。用户空间可以用AddressSanitizer编译。OOMOut Of Memory看内核日志里的oom-killer输出它会告诉你哪个进程被杀了、当时内存什么情况。dmesg | grep -i oom\|out of memory4.4 硬件接口调试命令嵌入式工程师经常要跟各种硬件接口打交道I2C、SPI、UART、GPIO、MDIO。Linux给每个接口都提供了用户空间的操作方式掌握这些命令能省很多事。I2C用i2cdetect、i2cget、i2cset。先看总线上的设备地址i2cdetect -y -r 0 # 扫描I2C总线0上的设备 i2cget -y 0 0x50 0x00 # 读地址0x50的寄存器0x00 i2cset -y 0 0x50 0x00 0x12 # 写地址0x50的寄存器0x00为0x12SPI用spidev接口通常需要自己写个小程序或者用spi-tools。UART用stty配置echo和cat收发stty -F /dev/ttyS0 115200 cs8 -cstopb -parenb echo test /dev/ttyS0 cat /dev/ttyS0GPIO用sysfs或者gpiod# sysfs方式旧 echo 12 /sys/class/gpio/export echo out /sys/class/gpio/gpio12/direction echo 1 /sys/class/gpio/gpio12/value cat /sys/class/gpio/gpio12/value # gpiod方式新 gpiodetect gpioinfo gpiochip0 gpioset gpiochip0 121 gpioget gpiochip0 12MDIO用mdio-tools或者直接操作寄存器。如果PHY不支持MDIO而用I2C控制那就用I2C的命令去读写PHY寄存器。5. 典型故障案例复盘5.1 案例一系统随机重启这是我早期遇到的一个经典案例。一块基于ARM的板子运行几个小时到几天不等就会重启。重启时间不固定负载高的时候更容易出现。现场保护先查重启原因寄存器。SoC有个PMU寄存器记录上次复位原因读出来是“看门狗复位”。说明系统确实死了看门狗没被喂。信息采集打开内核的panic和oops打印确保串口能收到。同时把看门狗的超时时间从默认的60秒改成120秒给系统更多时间打印信息。推理过程看门狗复位说明系统在某个时刻完全卡死了。可能的原因中断风暴、死锁、内存耗尽、硬件故障。先排除硬件电源和温度都正常。然后看内核日志发现死机前没有任何异常打印说明不是软件主动panic。二分法把系统负载降低只跑最基本的服务发现还是重启。说明问题在底层不在应用层。然后关掉所有非必要驱动只留串口和看门狗还是重启。最后怀疑是看门狗驱动本身的问题。定位查看门狗驱动代码发现喂狗是在一个内核定时器里做的。定时器回调里有一段代码会调用msleep而msleep在原子上下文里是不允许的会导致调度异常。在某些时序下这个异常会导致系统卡死看门狗超时复位。解决把msleep改成mdelay或者把喂狗放到工作队列里。改完之后跑了一周没再重启。经验看门狗复位不一定是系统真的死了也可能是喂狗逻辑本身有问题。另外内核定时器回调里不能睡眠这是基本规则但很容易被忽略。5.2 案例二串口丢数据一块板子通过串口跟外设通信偶尔丢一帧数据。丢数据的时间间隔不固定有时候一天几次有时候几天一次。现场保护在串口驱动里加统计记录接收中断次数、FIFO溢出次数、帧错误次数。同时用逻辑分析仪抓串口波形。信息采集统计发现FIFO溢出次数在丢数据的时候会增加。逻辑分析仪显示外设发送的数据是完整的但板子这边没收到。推理过程FIFO溢出说明中断响应不及时。可能的原因中断被关闭时间太长、中断优先级太低、中断处理函数执行时间太长。时间线分析在串口中断和系统定时器中断里都打时间戳发现每次丢数据都发生在系统定时器中断处理时间超过200微秒之后。正常情况这个中断处理应该在50微秒以内。定位查系统定时器中断处理代码发现里面有一段循环在等某个硬件状态位没有超时机制。在特定条件下这个循环会执行很久导致关中断时间过长。解决给循环加上超时超时后直接返回错误。同时把串口中断优先级提高。改完之后丢数据现象消失。经验中断处理函数要尽可能短不能有不确定的等待。如果必须等待一定要有超时。5.3 案例三内存泄漏导致OOM一个网关设备运行几天后内存耗尽OOM killer杀掉关键进程系统功能异常。现场保护在OOM发生前系统已经变慢这时候登录进去保存了/proc/meminfo、/proc/slabinfo、ps aux等信息。信息采集/proc/meminfo显示SUnreclaim持续增长从几十MB涨到几百MB。/proc/slabinfo显示某个内核对象数量异常多。推理过程SUnreclaim增长说明内核对象泄漏。查slabinfo里增长最快的对象发现是某个网络驱动的skb相关对象。定位查网络驱动代码发现在错误处理路径上有些skb没有被正确释放。正常路径没问题但特定错误条件下会漏掉。解决修复错误处理路径确保所有skb都被释放。同时加上kmemleak定期扫描防止类似问题再次出现。经验内核对象泄漏比用户空间内存泄漏更隐蔽因为free命令看到的used可能不高但Slab里的SUnreclaim会暴露问题。定期监控slabinfo是个好习惯。6. 破案高手的自我修养6.1 建立自己的工具箱嵌入式调试工具很多但你不必每个都精通。我的建议是先精通几个最常用的再根据需要扩展。必备工具清单串口终端minicom、picocom、screen至少会一个。逻辑分析仪Saleae或者便宜的山寨版都行抓I2C、SPI、UART时序非常有用。示波器看电源纹波、时钟质量、信号完整性。万用表量电压、通断。JTAG调试器OpenOCD GDB能单步调试bootloader和内核。交叉编译工具链根据你的SoC选ARM的一般用arm-linux-gnueabihf-或者aarch64-linux-gnu-。软件工具perf性能分析看热点函数。ftrace内核跟踪看函数调用关系和耗时。bpftrace动态跟踪功能强大但学习曲线陡。valgrind用户空间内存检查。kmemleak内核内存泄漏检查。6.2 培养系统思维嵌入式系统是一个整体软件和硬件相互影响。破案的时候不能只盯着一个层面要有系统思维。比如一个I2C通信失败可能的原因包括I2C控制器驱动问题、I2C从设备问题、上拉电阻问题、总线电容问题、电源问题、时钟问题。你得从系统层面去考虑而不是只查驱动代码。我习惯画一张系统框图把CPU、内存、存储、外设、电源、时钟都画出来然后标出信号流向。出问题的时候沿着信号流向一段一段查很快就能定位。6.3 记录与复盘每次破案之后我都会写一份复盘报告。内容包括问题现象、排查过程、根本原因、解决方案、经验教训。这份报告不仅是给自己看的也是给团队看的。下次遇到类似问题直接翻报告就行。复盘的时候要问自己几个问题这个问题能不能提前发现有没有更好的排查方法有没有类似的隐患怎么防止再次发生我还会维护一个“坑列表”把所有踩过的坑记下来。比如“内核定时器回调不能睡眠”、“中断处理不能等硬件状态位”、“错误处理路径容易漏释放资源”。这些坑看起来简单但在实际开发中很容易再犯。6.4 保持好奇心与耐心最后说点虚的但很重要。嵌入式调试很多时候是枯燥的你可能花几天时间就为了找一个空指针。这时候好奇心很重要为什么这里会空什么条件下会空怎么构造这个条件有了好奇心你才能坚持下去。耐心也很重要。有些Bug就是很隐蔽你急也没用。我的经验是遇到卡住的时候先放一放去喝杯水或者跟同事聊聊。很多时候换个思路问题就迎刃而解了。还有一点不要怕犯错。嵌入式开发里犯错是常态。关键是从错误中学习下次不再犯同样的错误。我干了这么多年还是经常踩坑但踩过的坑越来越少这就是进步。7. 一些实用的排查技巧与避坑指南7.1 快速定位问题的几个窍门窍门一先看日志再看代码。很多人一遇到问题就翻代码这是效率最低的做法。日志里往往已经告诉你了问题在哪只是你没注意。我习惯先把dmesg从头到尾看一遍把错误和警告都标出来然后再看代码。窍门二从最近改动的地方查起。如果问题是最近才出现的那大概率是最近的改动引起的。用git log看最近提交用git diff看改了什么。我遇到过好几次查了半天发现是同事改了一行配置。窍门三用二分法缩小范围。如果不知道问题在哪就把它一分为二。比如系统启动卡住先确定是内核之前还是之后如果是内核之后再确定是驱动初始化还是根文件系统挂载。每次排除一半很快就能定位。窍门四构造最小复现。如果问题能稳定复现就尝试构造一个最小的复现环境。关掉所有不必要的功能只保留触发问题的最小集合。这样不仅能加快排查速度还能帮你理解问题的本质。窍门五善用搜索引擎。你遇到的问题大概率别人也遇到过。把错误信息的关键部分复制到搜索引擎里往往能找到答案。但要注意甄别有些答案可能不适用于你的场景。7.2 常见误区与避坑误区一重启解决一切。重启只是掩盖问题不是解决问题。而且重启会破坏现场让问题更难查。除非万不得已不要重启。误区二只看应用层不看内核。很多问题根源在内核或者驱动应用层只是受害者。遇到问题要往下查不要停留在表面。误区三忽略硬件。嵌入式工程师不能只懂软件硬件也要懂。很多软件问题其实是硬件问题引起的。误区四不记录不复盘。踩过的坑不记录下次还会踩。建立自己的知识库比什么都重要。误区五过度依赖调试工具。工具是辅助不是万能。有时候最简单的printk比复杂的工具更有效。7.3 一些容易忽略的细节细节一时钟配置。很多外设问题其实是时钟配置不对。比如I2C速率不对、SPI时钟相位不对、UART波特率不对。查问题的时候先确认时钟。细节二引脚复用。SoC的引脚往往有多个功能配置错了就会导致外设不工作。查原理图和设备树确认引脚复用正确。细节三电源域。有些外设有独立的电源域如果电源没打开外设就不工作。查电源管理配置。细节四复位时序。有些外设需要特定的复位时序复位时间不够或者顺序不对都会导致问题。查数据手册。细节五中断优先级。中断优先级配置不对会导致中断丢失或者响应延迟。查中断控制器配置。细节六缓存一致性。DMA和CPU共享内存的时候缓存一致性是个大问题。该刷缓存的时候要刷该无效化的时候要无效化。细节七字节序。不同架构的字节序可能不同通信的时候要注意转换。细节八对齐。有些架构要求内存访问对齐不对齐会触发异常。这些细节看起来琐碎但每一个都可能导致诡异的问题。我踩过的坑里至少有一半是这些细节引起的。8. 从柯南到福尔摩斯的进阶之路8.1 从解决问题到预防问题新手关注的是怎么解决问题老手关注的是怎么预防问题。预防问题比解决问题更有价值因为问题不发生就没有损失。预防问题的方法包括代码审查、静态分析、单元测试、集成测试、压力测试、长时间老化测试。这些手段能在问题上线之前就把它找出来。我现在的习惯是每写一个驱动都要写测试用例。测试用例覆盖正常路径和异常路径确保每个分支都走到。虽然写测试花时间但比上线之后出问题再查要划算得多。8.2 从个人能力到团队能力一个人再厉害也干不过一个团队。把个人的破案经验沉淀成团队的排查手册价值会放大很多倍。我所在的团队有一个共享的Wiki里面记录了所有踩过的坑、排查方法、工具使用技巧。新人进来先看Wiki能少走很多弯路。每次破案之后当事人负责更新Wiki把新的经验加进去。我们还定期做故障复盘会把最近的故障拿出来大家一起分析。不仅分析技术原因也分析流程原因。比如为什么这个问题没在测试阶段发现测试用例是不是有遗漏流程上怎么改进8.3 保持学习与更新嵌入式技术更新很快新的SoC、新的内核版本、新的工具层出不穷。保持学习是必须的。我的学习渠道包括内核邮件列表、技术博客、开源项目、技术会议。不一定要每个都深入但要知道有什么新东西需要的时候能快速上手。另外基础知识要扎实。操作系统原理、计算机体系结构、数字电路、信号与系统这些基础课的东西在工作中会反复用到。基础扎实了学新东西就快。8.4 一些个人体会干了这么多年嵌入式我最大的体会是耐心比聪明重要方法比经验重要记录比记忆重要。耐心比聪明重要因为嵌入式调试很多时候就是体力活你得一遍一遍试一遍一遍查。聪明人可能找到捷径但耐心的人一定能找到答案。方法比经验重要因为经验会过时但方法不会。掌握了系统的排查方法遇到新问题也能应对。记录比记忆重要因为人脑记不住那么多细节。把踩过的坑、用过的方法记下来需要的时候翻一翻比什么都强。最后嵌入式工程师确实像柯南但柯南也不是天生的。每一个诡异的Bug背后都有一套可复用的推理方法。掌握了这套方法你也能成为破案高手。