我们和一家公司合作，对方派来个写代码的程序员。他敲代码的本事还不错，但沟通起来总是有点费劲。
这种沟通问题倒不是说他代码写得不行，而是一起干活的时候，理解和执行任务的效率不太够。举个例子，我让他写文档，特别强调要写得谁看都能懂，毕竟我们有同事在外地，文档是大家远程合作的重要工具。可他第一次交上来的文档，根本没法看，我反复和他说了好几次要求，才总算改得能看明白。
还有一次，项目加了新需求，他给的接口我一测试就出问题。没办法，我只能让他把代码发过来检查，最后发现是初始化的时候没弄好。
这些小问题，其实都说明了单片机开发对细节要求有多高。我们用的这块单片机芯片，连调试串口都没有，出了问题只能接调试板慢慢排查，特别麻烦。要是换成 Linux 开发板，用 printk 就能很快找到问题，效率不知道高多少。
别以为单片机的接口用起来很容易。
像 AD/DA、电压比较器这些模拟接口，要是不懂电路原理，根本不敢乱动；PWM 接口看着普通，其实和算法关系很大，而且对实时性要求特别高，一个小小的中断冲突，都可能出大问题，毕竟后面连接的设备功率很大。
另外，隔离、接地、电磁兼容性、电源质量这些也都是必须掌握的知识。就算是最简单的 UART 接口，也可能因为底层 API 函数有隐藏问题，引发 DMA 冲突，导致莫名其妙的故障。前段时间我们就遇到过这种情况，代码看起来没问题，最后只能通过跟踪寄存器状态，才找到问题。
CAN 总线就更复杂了，汽车电子领域用的 CAN 总线工具，一套就要上千万；普通的 USB 接口 CAN 调试器，好一点的也要上百万（主要是配套软件太贵）。现在又出了 10BASE-T1S 车载以太网，还能供电，技术难度越来越高。
我记得之前遇到过一个特别的问题，严格来说，这不算软件的问题。
当时的情况是这样的：单片机用异步串口通信时，接收 DMA 空闲后会触发中断，让 CPU 来取数据。可偏偏这时候，定时器控制的发送 DMA 启动了，空闲中断会把接收 DMA 锁住，不让它接收数据，得等发送 DMA 完成才能解锁。这就导致接收 DMA 丢数据了。
普通数据丢了还好说，可我们接收的是操作指令，一旦丢了，可能会出大事故。我们查了好久，发现代码就三行：设置定时器中断、启动接收 DMA、启动发送 DMA，都是调用单片机自带的库函数，表面上看没问题（毕竟空闲中断和 DMA 锁定是硬件自动操作，代码控制不了）。
最后，我们接上调试设备，在丢数据的时候，实时查看代码和 CPU 里 DMA 相关寄存器的状态，才找到问题。解决办法也简单：在定时器启动发送 DMA 之前，先把空闲中断关掉，等发送 DMA 完成了，再打开。这样只会让空闲中断晚几微秒，不影响数据接收。当然，也可以直接改单片机的库函数，在空闲中断里把接收 DMA 解锁，但不了解底层设计就随便改，可能会引发更多问题，所以我们没敢这么做。
解决这个问题，其实已经用到汇编级的寄存器调试了。C 语言其实就是简化版的汇编，写代码的时候，得时刻关注内存地址和寄存器的变化，才能发现这类问题。
所以说，单片机编程可不只是写代码那么简单。你得吃透硬件特性，还要懂很多行业知识，就像在迷宫里找路，每一步都得小心翼翼。短短几行代码背后，是对硬件原理的深入理解、对细节的严格要求，还有无数次调试积累的经验，缺一不可。
