企业官网建设流程全解析

做嵌入式开发这些年，通讯这块几乎每个项目都要碰一遍。不管是读传感器、烧Flash、点屏幕、连接车间设备，还是让板子和手机对上话，归根到底都是同一件事：数据怎么在芯片和芯片之间、设备和设备之间稳定高效地传。平时也常看到新人一上来就问“用串口还是I2C”，其实这个问题背后不是选哪个“好”，而是哪个“合适”。下面我就把实际工程里常用的几类通讯方式串起来聊一遍，包括UART、I2C、SPI、CAN、USB、以太网，以及蓝牙、WiFi、ZigBee、LoRa这类无线方案，重点放在选型思路、关键参数、硬件设计和调试排障上，希望对正在做板级开发或者准备系统梳理通讯框架的你有参考价值。

1. 先理清思路：嵌入式通讯到底在解决什么问题

1.1 从“芯”到“芯”的对话：为什么需要这么多通讯方式

很多没接触过的人会有个疑问：为什么嵌入式里有这么多种通讯协议，统一用一种不行吗？我的看法是，通讯方式的选择本质上是在距离、速度、功耗、成本、可靠性这几件事之间做取舍。比如主板上的传感器距离主控只有几厘米，那么I2C、SPI这种板级总线最合适，成本低、布线少；而车间里两台设备相距几十米，还要抗电磁干扰，那CAN、RS485这类差分总线就比普通串口可靠得多。至于要让设备联网、传视频、做OTA升级，又得上USB、以太网甚至无线方案。理解了这个底层逻辑，看到某种通讯方式时就不会觉得“多”，而是能够判断它解决了哪些具体问题。

除了距离和速度，通讯方式还决定了“谁和谁说话”的规则。UART是典型的点对点，两个人之间打电话；I2C是一条总线上挂很多设备，靠地址区分，像公交车按站停靠；SPI更像一对一专线，效率高但占线多；CAN则是多主总线，谁都能发言但按优先级来，类似会议室里的排队举牌发言。每一种规则都有它独特的适应场景，没有绝对的优劣，而是在特定约束条件下的最优解。这也是为什么成熟项目的通讯方案往往不止一种，甚至同一个系统里几种通讯方式协同工作，各自承担不同层次的数据传输任务。

1.2 选型的第一原则：通讯不是越高级越好

我见过不少开发者容易陷入一个误区：觉得USB比UART“高级”，以太网比CAN“高级”，于是不管干什么都往高速上靠。结果呢？成本上去了、功耗下不来、调试还变得复杂，最后稳定性反而不如老老实实用低速总线。通讯选型的第一原则，应该是“满足需求的最简方案”。比如只是给一个温湿度传感器做数据采集，每秒更新一次，数据量几十字节，那I2C或者UART绰绰有余，根本不需要上SPI或者USB。这时候选高速方案不仅浪费，还可能引入新的电磁干扰、时序复杂的麻烦。

另一个容易被忽视的选型维度是团队维护成本。主控上有没有现成的硬件外设？代码库里有没有成熟的驱动？工具链能不能方便地抓包分析？这些都会直接影响项目节奏。比如某平台上I2C外设寄存器配置特别复杂，但UART用DMA惯得很顺手，那么在没有强需求的情况下，用UART方案往往更务实。我的经验是：选型阶段多花十分钟列一下通讯距离、数据量、实时性要求、节点数量、供电预算、调试工具这六个条件，基本就能把方案锁定在很小的范围里了。真要遇到需要细分的特殊场景，再针对具体协议做专项对比，比一开始就纠结“到底哪个最强”要高效得多。

2. 最基础的两位：UART与I2C

2.1 UART：调试救急的第一选择

UART（通用异步收发器）应该是嵌入式开发者最早接触的通讯方式了。它的原理很简单：一根发送线TXD、一根接收线RXD，双方事先约定好波特率，然后按位把数据发出去。因为是异步通讯，没有独立的时钟线，靠的是波特率以及起始位和停止位来对齐数据，所以它天生就是点对点的。实际项目里最常见的用途有三类：一是打印调试日志，二是接GPS模块、蓝牙模块、指纹模块这类现成的串口设备，三是在两个MCU之间传指令或者小型数据包。

用UART的时候有几个细节直接影响稳定性。首先是电平匹配，TTL电平的UART一般是3.3V或者5V逻辑，跟RS232、RS485虽然都叫“串口”，但电平定义完全不同，接错就会烧接口或收不到数据。我的习惯是：凡是板内近距离通讯，直接用TTL串口；凡是远距离、工业环境，一律转成RS485差分信号，抗干扰能力强很多，通信距离能到千米级别。其次是波特率偏差，如果两边时钟精度不够，长时间大数据传输就会出现乱码。实际测试中，两边波特率误差超过2%就可能开始丢字节，超过5%基本没法稳定通信，所以量产品里我一般选带晶振的MCU做串口，内部RC振荡器在高波特率下不太靠谱。

还有个容易被忽略但很实用的操作：串口接GND。很多新手只接了TXD和RXD，发现数据发不出来，其实就是缺了共地。通讯两边必须以同一个“地”为参考，才能保证电平判断正确。这个问题在USB转串口模块上尤其常见，因为电脑USB地跟板子地不一定完全等电位。顺便说一句，长期做嵌入式的话，我强烈建议备一个带逻辑分析仪解码功能的USB转串口工具，可以直接看到波形而不仅是数据，排查收发时序问题会快很多。

2.2 I2C：两线制与地址机制的巧妙设计

I2C是非常经典的板级总线协议，硬件上只需要两条线：时钟线SCL和数据线SDA。它的设计思想很好：所有设备都挂在同一条总线上，主机通过设备地址来寻址，从机收到与自己匹配的地址后才响应。这种“一条总线多设备”模式，在PCB布局上能省大量走线，特别适合传感器比较多的小板子。I2C常见的运行速率标准模式是100kbps，快速模式400kbps，高速模式能到3.4Mbps，实际板级应用中400kbps用得最多，再快就要非常注意走线和上拉电阻了。

I2C里有一个必须弄懂的设计：开漏结构和上拉电阻。所有设备的SDA和SCL引脚都是开漏输出，只能拉低不能主动拉高，所以总线必须通过上拉电阻接到电源，才能实现高电平。这个上拉电阻阻值很有讲究：太大，边沿上升太慢，高速通讯会失败；太小，灌电流过大，设备可能拉不动。一般低速率、器件少可以用4.7k到10k，高速率或者线上设备多，则要降到1k到2.2k。具体选多大，最好用示波器看上升沿，确保满足对应模式的最小时钟低电平时间的要求。我在一个挂了8个传感器的板子上用2.2k上拉，配合400kbps，实测波形干净利落，几乎没有信号完整性问题。

另一个常见的坑是I2C总线死锁。如果某个从机在通信中途把总线拉低且不放掉，整条总线就卡死了，后面所有命令都无效。遇到这种情况，先别急着换芯片，可以用示波器看SDA是不是一直为低。排障思路很简单：先给SCL额外切换9个时钟周期，大多数从设备会被这个“伪结束条件”复位；还不行就查从机是不是供电异常，或者复位时序有问题。我自己的习惯是，在驱动代码里加一个“总线恢复”函数，检测到SCL空闲但SDA被拉低超过一定时间，就主动触发恢复序列，这个处理在实际项目中救过很多次。

2.3 基础通讯的常见坑位

UART和I2C看起来简单，但恰恰是这些“简单协议”最容易出隐蔽问题。我梳理几个高发坑位，给后来者提个醒。

第一，UART的“假空闲”。有些单片机默认引脚为上拉输入，不初始化时TXD引脚可能是高电平，这对于UART来说刚好是空闲状态，会产生一种“通讯正常但实际没工作”的错觉。调这种问题得靠示波器看引脚是否有真实波形，而不要只看串口软件有没有收到数据。

第二，I2C的地址冲突。同一型号的传感器往往有可配置的地址引脚，例如把某个引脚拉高或拉低来切换地址。如果板子上并了两颗同型号芯片，而地址又配成一样，总线上的寻址就会混乱，数据就串了。我遇到过一次，排查了很久才发现是地址引脚漏接了上拉电阻。

第三，共地问题在高负载下特别明显。板子上有大功率电机或者开关电源时，数字地平面会有较大噪声，UART和I2C的波形都会被污染。这时除了布线上做单点接地，必要时还可以在信号线串联几十欧姆的小电阻，对边沿做一定程度的整形。这个问题在电机驱动板或电源板上尤其常见，第一次碰到的朋友可能会怀疑是代码问题，实际却是电气噪声问题。

3. 追求速度与可靠：SPI与CAN

3.1 SPI：四线全双工，速度首选

SPI（串行外设接口）在嵌入式里是当之无愧的速度担当。它一般用四根线：时钟线SCLK、主机输出从机输入MOSI、主机输入从机输出MISO，以及片选线CS。和I2C最大的不同是：SPI是同步全双工，发送和接收同时进行，而且每个从机都有独立的片选信号，主机只管拉低目标设备的CS，就可以点对点通信，效率非常高。常规SPI速率从几百kHz到几十MHz都常见，在一些接口、Flash、SD卡、显示屏、高速ADC上应用非常广。

SPI有一点特别容易踩坑：时钟极性（CPOL）和时钟相位（CPHA）的匹配。CPOL决定空闲时时钟是高还是低，CPHA决定数据是在时钟上升沿还是下降沿采样。主从双方必须配置一致才能正确读数据，而很多从机芯片手册对这一块的描述并不直白。我的做法是：拿到新器件先看时序图，按图里数据的建立和采样时刻来反推CPOL和CPHA，而不是凭感觉乱试。如果实在不确定，也可以用逻辑分析仪抓一次主机的写操作，再和器件手册时序图对比，基本能确定参数。

另外一个经常出问题的是MISO引脚的处理方式。在多个SPI从机共用一个MISO的情况下，如果某些从机不支持三态输出，它不工作时MISO仍会被拉高或拉低，导致总线冲突。解决办法要么选支持三态的从机，要么在MISO线上加隔离电阻。我在一个多从机系统里遇到过MISO数据随机错乱，排查到最后就是有个从机在片选无效时仍驱动MISO引脚，导致其他从机数据被干扰。这个细节在选型阶段就要注意，不要等画完板子才发现。

SPI的布线同样值得讲究。高速SPI（比如10MHz以上）时，信号线之间如果太近且没有回流地平面，就容易出现串扰和反射。我建议SPI时钟线和数据线尽量短，不要走太细的过孔，且最好在连续地平面的同层走线。再就是末端串联一个22到33欧姆的电阻做阻抗匹配，在较长走线上效果非常明显。低速场合这些无所谓，但一旦上高速，信号完整性的差别立刻就能看出来。

3.2 CAN：差分总线与工业级可靠性

CAN（控制器局域网络）在汽车电子、工业控制、机器人领域几乎是标配。它的物理层用的是差分信号：CANH和CANL两根线，靠两根线的电压差来表示显性位和隐性位。由于是差分传输，共模干扰对它的影响比单端信号小很多，所以抗干扰能力强，通信距离和节点数量也远超UART和I2C。CAN总线是真正的多主通讯，任何节点都可以主动发报文，报文自带的ID决定了优先级，多个节点同时发送时，低ID的报文会自动赢得仲裁，这种机制非常适合实时性要求高的控制系统。

用CAN做工程落地时，有几个硬件设计上的关键点值得认真对待。第一是终端电阻。CAN规范要求在总线两端各接一个120欧姆的终端电阻，用来匹配阻抗、抑制信号反射。很多人只在主控板一端接了电阻，结果总线一长波形就振铃，出现偶发错误帧。正确做法是确认总线的物理两端各有一个120欧姆，而不是在每个节点上都接，否则总线等效阻抗过低，驱动能力会不足。第二是波特率一致性。CAN总线上所有节点的波特率必须完全一致，通常由晶振精度和采样点配置决定，采样点推荐设在75%到85%之间，能更好容忍总线传播延迟。预设定的采样点位置太靠前或太后，都会在特定拓扑下出现误码。

实际用CAN的时候，我还会规划好报文ID和报文周期。不要只从功能角度随便分配ID，要考虑实时性等级：要求几十毫秒内响应的控制报文优先级最高，用最小ID；周期性状态报文居中；诊断和配置报文优先级最低。这样设计的好处是，当总线负载率升高或者多个节点同时发报文时，系统仍然能保证关键控制信号不被延迟。很多人忽视这一点，总线负载不高时没事，等以后慢慢加节点、加报文，总线仲裁冲突就会变多，偶发问题就开始冒头了。

3.3 高速通讯的参数选择与调试经验

SPI和CAN这一类高速通讯，硬件的“工程参数”比协议本身更值得重视。SPI这边，速率不一定是越高越好，很多从机标称能跑50MHz，实际配合长线和大负载电容后，波形已经严重畸变，数据在临界点来回横跳。我的建议是：选速率时留至少30%的裕量，比如器件标称30MHz，实际工程用10到20MHz就好。这样既能满足吞吐量，又给信号完整性留了余地，系统更皮实。

CAN这边，我常用的波特率覆盖范围大约从125kbps到1Mbps。低速总线（比如250kbps以下）物理层容错高，可以用简单双绞线，但也要注意线缆的绞合质量，最好用带屏蔽层的CAN专用线；高速1Mbps时，线缆很短、线径足够、连接可靠这三条几乎缺一不可，否则很容易收到错误帧。调试阶段，把CAN控制器的错误计数器读出来是非常有效的定位手段，如果错误计数持续攀升，说明物理层有问题，先查终端电阻、线缆长度和接头压接，往往比改软件更快见效。

我调试高速通讯的一个通用思路是“先看物理，再看协议”。不管软件逻辑看起来多么可疑，只要总线上波形细节不对，一切上层解码都是无源之水。因此我会在样板阶段就用示波器把波形抓出来保存，比如SPI时钟高电平宽度、数据建立时间、CAN的显性和隐性电平幅度，这些第一手记录在后续改板或者故障分析时都是宝贵的对照基准。没有这个习惯的人，出了问题往往只能瞎猜，有了波形档案，很多疑难杂症几分钟就能定位到根因。

4. 大吞吐量场景：USB与以太网

4.1 USB：从枚举到类协议

USB在嵌入式里扮演的角色比较特殊：它既是调试接口，也是数据传输通道，还能充当供电来源。只要用到USB，就绕不开“枚举”这个概念。主机在设备接入后，会通过一系列标准请求来获取设备的描述符，比如设备是键盘、串口、还是大容量存储。整个枚举过程是主机主导的，设备端只需要按协议响应即可。很多从单片机裸机转过来的朋友，第一次接触USB都会觉得中断描述符、端点描述符这东西特别抽象，确实需要一点时间消化。

实际项目里，USB最常见的形态是CDC类虚拟串口。它最大的好处是无缝衔接PC应用：在电脑上看到的就是一个COM口，可以用现成的串口调试软件通信，不用装特殊驱动，非常方便。CDC类虚拟串口适合中等速率的数据传输，比如日志输出、参数配置、固件升级，稳定性和易用性都很好。如果数据量更大，就要考虑USB的批量传输端点，典型应用是UVC摄像头和U盘。做过图像采集的项目，基本都会用到USB的高速批量传输来搬运图像帧，这个时候端点数、端点大小、缓冲区策略、DMA通道安排都要提前规划好。

USB调试的难度比串口高一个量级。最简单的定位手段是用低速分析工具抓包，看设备响应主机请求的情况。很多时候设备没反应，不是代码跑飞，而是描述符返回有误，或者端点配置没有及时使能。我建议初学者把USB枚举的每个阶段都打印出来，对照协议文档走一遍，能非常直观地理解整个链路。另外一个常见坑是USB线缆和接触问题。很多“设备无法识别”的故障，换个质量好的线、换一个直连主机背后的端口就解决了，没必要一开始就在固件里反复折腾。

4.2 以太网：嵌入式网络化的必经之路

以太网在嵌入式领域越来越常见，从工业网关、智能家居中控到视频传输设备，几乎都要联网。相比USB和串口，以太网最大的优势是通行的TCP/IP生态，设备接上交换机或路由器就能融入局域网和互联网。嵌入式以太网一般有两条路线：一是MCU自带的MAC控制器加上外部PHY芯片，比如配合常见PHY和变压器做RJ45；二是使用带硬件协议栈的网络芯片。前者灵活、吞吐量高，但驱动和协议栈的集成成本大；后者开发简单、稳定性好，适合快速出产品。

TCP/IP协议栈选型是嵌入式以太网开发的重要决策。自研协议栈工作量太大，我不建议从零开始，除非是纯粹的学术练习。现实项目中，要么用成熟的轻量级协议栈，要么用带硬件协议栈的专用芯片，把TCP/IP处理卸载到芯片内部。这两条路我都走过，经验是：如果项目对数据吞吐要求不高、主要做MQTT或HTTP这类轻应用，专用协议栈芯片开发效率很高，几乎不会遇到底层协议栈疑难杂症；如果项目需要高速数据流，比如视频推流或者大文件传输，那必须用MCU原生MAC加高性能协议栈，并且要仔细调优中断和DMA机制。

以太网调试里，我最常看到的问题反而不是代码逻辑，而是物理链路。MDI差分线的绕对、变压器中心抽头接法、PCB阻抗控制，这些做不好，就会出现“网口能link但丢包严重”的诡异现象。手边常备一个简单的网络抓包工具很关键，抓包能快速判断数据是根本没发出来、还是发出来了但内容不对。另外，给设备一个固定的静态IP并在同一网段下直连测试，能够排除路由器、DHCP等多变量干扰，这对单板调试效率提升非常明显。

5. 摆脱线缆：无线通讯的方案取舍

5.1 蓝牙与WiFi：消费级产品的双子星

蓝牙和WiFi几乎是消费级电子产品默认的无线方案。蓝牙这里，现在基本都在用低功耗蓝牙（BLE）。BLE的特点是省电和应用灵活，它不像传统蓝牙那样做持续的数据流导向，而是通过广播、扫描、连接、然后以GATT服务的方式读写特征值。智能手环、心率带、门锁、Beacon基本都是走这条路线。BLE的GATT模型是一个“属性”的表格，服务、特征值、描述符在逻辑上层层嵌套。刚上手的人容易觉得这个模型绕，我的建议是先画清楚属性表，再动手写代码，否则后面要维护会非常吃力。

WiFi这边，特点是大带宽和成熟IP网络协议栈。嵌入式设备连上WiFi后，可以像普通电脑一样发起HTTP请求、建立TCP或UDP套接字，非常适合做数据上云、远程控制和固件OTA。WiFi也分两条路线：像模块一样用AT指令操作，或者直接通过SDK在模组上写程序。前一种上手极快，适合后端业务为主、不想深究射频的团队；后一种灵活性高，能够直接处理大量数据，但射频校准和天线设计就得自己扛了。多数小团队我更推荐模块化方案，把射频的不确定性交给模块厂商，自己把精力集中在应用层。

无线产品有一点和有线直觉完全不同：无线链路的“不确定性”。有线通讯只要物理连接正常，丢包率基本为零；无线则会受到同频干扰、遮挡、多径效应的影响，丢包和延迟是常态。所以在做蓝牙或WiFi产品时，应用协议本身要设计成“允许重传和状态校验”的模式，不能假设一发就通。比如状态上报每隔一段时间重发一次，或者关键指令做应答确认，这些看似冗余的设计，能让产品在实际家庭环境中稳定得多。我在多个无线项目里都遇到过“实验室好，用户家不稳定”的案例，根因几乎都出在没考虑无线链路的不可靠性。

5.2 ZigBee与LoRa：物联场景下的低功耗远距方案

如果蓝牙和WiFi属于“通用型”无线方案，那ZigBee和LoRa则更像是为特定物联网场景定制的专用工具。ZigBee核心特点是低速率、低功耗和自组网。它工作在2.4GHz，可以组建大规模网状网络，一个协调器下面挂几十上百个节点是很常见的。ZigBee更适合智能家居传感器网络、楼宇自动化这类多点、低数据量、要求低功耗的场合。不过自组网听起来美好，实际工程里网关选型、信道规划、设备入网策略都需要经验，否则会影响网络稳定性。我第一次做ZigBee项目时低估了信道干扰的影响，结果在WiFi密集的办公环境里组网体验大打折扣，后来把ZigBee信道调整到和WiFi错开，情况立刻好了很多。

LoRa则主打“远距离、低功耗、低速率”。它的物理层技术决定了在郊区开阔环境下通信距离可以做到数公里甚至更远，非常适合智慧农业、水电表计、资产追踪这类需要把传感器散布到很大范围、又不方便布线的场景。LoRa网络的数据速率非常有限，通常只有几kbps，但正因为慢，传输所需的能量也极低，一个电池供电的节点工作几年是可以做到的。使用LoRa时，占空比和发送策略要非常克制，不能按以太网的思路频繁上传数据。另一个要留意的点是LoRa网关很贵，组网成本比蓝牙或ZigBee高不少，整体方案需要量级足够大才划算。

无线方案选型时，我常提醒团队做一个“无线链路预算”的粗算：发射功率、天线增益、接收灵敏度、路径损耗这几项一算，就能大致判断覆盖范围是否够用。很多人只看厂商标称的“空旷距离”，到真实环境往往大打折扣。尤其是穿墙场景，楼层隔断和金属结构对2.4GHz频段的衰减非常明显，标称几百米的产品可能隔两三面墙就没信号了。所以做无线产品，最好先租或借一套样机到现场做场地测试，把数据和预期对比后再定方案，这才是靠谱的路线。

6. 几年调通讯攒下的实战排查经验

6.1 波形与时序：学会看会调才叫入门

通讯问题排查，说一千道一万，最后都会落到“看波形”这件事上。我见过不少人只依赖串口软件收到的字符串来做判断，这远远不够。真正的排查是从示波器或者逻辑分析仪上开始的。比如UART乱码，看波形能立即判断是不是波特率偏差或者电平不对；I2C卡死，看SDA是不是一直被拉低一清二楚；SPI数据错乱，看时钟沿和数据变化时间关系就能找到是采样点的问题还是从机响应问题。我的建议是，手边常备一台四通道示波器，带宽不必太高，100MHz就足够应付绝大多数板级通讯调试；逻辑分析仪则适合多路协议解码，尤其在分析I2C、SPI、UART同时出现时，协议解码功能能极大提升效率。

看波形不是看懂高低电平那么简单，几个关键指标要会看：上升沿是否过缓、信号过冲是否过大、毛刺是否频繁、低电平是否拉得足够低。如果上升沿太缓，就要检查上拉电阻、走线长度、输入电容；如果过冲明显，就要考虑串阻和走线阻抗；如果毛刺频繁，多半是电源噪声或者邻近信号串扰。把这几板斧掌握到位，面对通讯概率性问题就有章可循了。我还习惯在看波形时同步拍下软件配置界面，这样两边对照，可以快速排除“软件配置乱了还是物理链路坏了”的争议。

6.2 电平、干扰与地：电气层面的隐形暗坑

通讯调不通，很多时候不在协议而在于电气规格。最典型的是电平不匹配：3.3V系统接了5V的传感器，或者反过来，5V逻辑的TX直接进3.3V的MCU引脚，轻则读不到高电平，重则打坏引脚。所以接任何外设前，先查器件手册或模块资料，确认接口电平范围，该用电平转换芯片就用芯片。电平转换不是只在特殊场合才需要，很多开发板的排针默认都是3.3V，却有很多现成模块是5V逻辑，不少“串口乱码”的故障就是电平问题被误判成软件问题。

干扰则是另一个大头。电机启动、继电器吸合、电源纹波，都可能让通讯线上出现大量毛刺，导致数据错误。对付干扰有几个基本功：电源入口加大电容、通讯线尽量远离高频开关节点、关键信号用屏蔽线或双绞线、地平面保持完整。这些属于硬件设计层面的问题，代码再优化也救不回来。我记得有个用CAN总线的项目，现场偶发报错，查了很久发现是设备接地不良，机壳电位漂移导致共模电压超高，重新做好接地后问题彻底消失。这类经验提示我们：问题远不止协议栈和驱动代码，工程现场的电气环境同样是系统的一部分。

6.3 通讯调试的通用方法论

我总结过一套高效的通讯调试流程，分享出来可以少走弯路。第一步，确认物理层是否健康。用示波器在接收端测量信号波形，确认幅度、边沿、毛刺都正常。第二步，用回环测试验证外设本身。很多芯片支持串口或SPI的环回模式，短路TX和RX或者配置寄存器，看自发自收是否成功，这样可以把外设和外部链路切开，快速划分责任范围。第三步，缩小数据量观察收发。先发固定的字节或者预设长的重复数据，看接收端能不能稳定还原，再逐步增加数据量和复杂度。第四步，借助协议分析工具解码，把波形层的信息翻译成协议层的数据，直观对比预期结果。这四步下来，绝大多数通讯问题都能定位到一个较小的范围内。

我在实际项目里，还有一个小习惯：把每次调试的关键配置和现象记录下来，形成一份“通讯调试笔记”。里面记录波特率、时钟极性和相位、终端电阻阻值、示波器截图、波形参数等等。短期来看，好像多花了点时间，但长期收益非常大。因为通讯问题最麻烦的地方是概率性、偶发性和环境相关性，笔记积累多了，很多新项目的疑难杂症能在老记录里直接找到答案。通讯调试本质上就是一个不断排除变量、逼近根因的过程，方法论和积累缺一不可。