1. 为什么两根线能撑起整个总线I2C这东西刚入行的时候觉得简单得不行——不就两根线嘛SCL加SDA挂一堆设备上去读读写写就完事了。但真到了板子跑不起来、波形莫名其妙、多设备抢总线的时候你才会发现这两根线背后的门道比想象中深得多。我见过太多人调I2C调到头大上拉电阻换了七八个阻值、示波器抓了几百帧波形、代码改了好几版最后发现是开漏输出没配对或者总线电容超了标。这篇东西就是把我这些年踩过的坑、翻过的数据手册、抓过的波形从头到尾捋一遍。从最底层的开漏物理层讲起一直讲到多主仲裁的机制目标是让你看完之后面对任何I2C问题都能有个清晰的排查思路而不是瞎试。适合谁看嵌入式软件工程师、硬件设计人员、驱动开发、FPGA工程师以及任何需要跟传感器、EEPROM、PMBus设备打交道的朋友。不管你是刚接触I2C的新手还是已经用过但没深究过原理的老手这里应该都有你能拿走的东西。核心关键词先摆出来I2C、开漏输出、上拉电阻、SCL、SDA、多主仲裁、物理层、时序、总线电容。这些词后面会反复出现每一个我都会拆开讲透。先说一个最基本的认知I2C不是“两根线传数据”这么简单它是一个多主多从的总线系统所有设备共享同一对信号线靠协议规则来协调谁说话、谁听、什么时候说。这就决定了它的物理层设计必须支持“线与”逻辑——任何一个设备拉低总线总线就是低电平。这个特性直接推导出了开漏输出的必然性也引出了上拉电阻、总线电容、上升时间这一系列连锁问题。下面我按物理层、协议层、仲裁机制、实操调试四个大块来展开每一块都会给出具体的参数计算、波形分析和排查方法。2. 开漏物理层为什么必须是开漏加外部上拉2.1 开漏输出的电路本质先把开漏输出的结构说清楚。一个标准的开漏输出引脚内部只有一个N沟道MOS管漏极接到引脚源极接地栅极由内部逻辑控制。它只有两种状态MOS管导通时引脚被拉到地低电平MOS管截止时引脚处于高阻态悬空此时引脚电平完全由外部电路决定。对比一下推挽输出推挽是上下两个MOS管上管导通输出高下管导通输出低引脚始终被主动驱动到某个电平。推挽输出的驱动能力强上升沿陡峭但它有一个致命问题——不能把两个推挽输出直接连在一起。如果一个设备输出高、另一个输出低上下管同时导通电源到地形成低阻通路大电流瞬间烧毁器件。I2C总线上挂了几十个设备每个设备的SDA和SCL引脚都并联在一起。如果用推挽输出只要有两个设备同时想输出不同电平立刻短路。所以I2C规范强制要求所有设备的SDA和SCL引脚必须使用开漏或开集电极结构。开漏的好处就在这里高阻态下引脚不驱动任何电平总线的电平由外部上拉电阻决定。任何一个设备拉低总线就是低所有设备都释放上拉电阻把总线拉高。这就是线与逻辑——所有输出端做逻辑与运算只要有一个低结果就是低。2.2 上拉电阻的计算不是拍脑袋上拉电阻选多大这是I2C硬件设计里最常被问到的问题。很多人直接抄别人的原理图用4.7k或者10k能用就行。但真到了高速模式或者长走线场景阻值选不对直接导致通信失败。上拉电阻的取值受两个条件约束上升时间和灌电流能力。先说上升时间。I2C总线的上升沿不是理想阶跃而是通过上拉电阻给总线电容充电的RC过程。总线电容包括PCB走线电容、引脚电容、器件输入电容通常每根线在几十pF到几百pF之间。标准模式100kHz要求上升时间不超过1000ns快速模式400kHz不超过300ns快速模式1MHz不超过120ns。上升时间的近似公式是tr ≈ 0.847 × R × C其中R是上拉电阻C是总线总电容。举个例子假设总线电容C200pF快速模式要求tr≤300ns那么R ≤ 300ns / (0.847 × 200pF) ≈ 1.77kΩ也就是说400kHz模式下200pF总线电容时上拉电阻不能超过约1.77kΩ。如果你用了4.7k上升时间会达到约796ns远超300ns的规格波形上升沿变缓接收端可能在SCL高电平期间采样不到正确的SDA数据。再说灌电流。当设备拉低总线时上拉电阻上的电流会灌入设备的开漏MOS管。I2C规范规定标准模式和快速模式下器件的灌电流能力至少为3mA快速模式为20mA但实际很少用到这么大。上拉电阻越小灌电流越大I_sink (VDD - VOL) / R假设VDD3.3VVOL0.4VR1.77kΩ则I_sink ≈ 1.64mA在3mA范围内没问题。但如果R太小比如降到500ΩI_sink就达到5.8mA超过了很多器件的承受能力。所以上拉电阻的选取是一个折中阻值要小到满足上升时间要求又要大到不超过器件的灌电流能力。实际工程中我一般按以下步骤来定估算总线电容。没有精确数据时按每根线50pF起步走线长的按100pF估算。根据通信速率确定最大允许上升时间。用公式算出电阻上限。检查灌电流是否在器件规格内。留20%余量选标准阻值。下面这张表是我常用的参考值基于VDD3.3V、VOL0.4V、灌电流上限3mA通信模式速率最大上升时间总线电容100pF时R上限总线电容200pF时R上限推荐阻值标准模式100kHz1000ns11.8kΩ5.9kΩ4.7kΩ快速模式400kHz300ns3.5kΩ1.77kΩ2.2kΩ快速模式1MHz120ns1.4kΩ0.7kΩ1kΩ注意这张表是估算值实际设计一定要用示波器测上升时间。我遇到过PCB走线特别长的情况200pF都打不住最后用了1kΩ才勉强满足400kHz的上升时间。2.3 总线电容那个容易被忽略的隐形杀手总线电容是I2C设计中最容易被低估的参数。很多人的板子原理图检查无误、代码也没问题但I2C就是时好时坏最后发现是总线电容超标了。I2C规范规定总线电容上限为400pF标准和快速模式。这个400pF包括什么所有挂在总线上的器件的引脚电容、PCB走线的分布电容、连接器的寄生电容甚至你示波器探头夹上去都会增加十几pF。实际中一个器件的引脚电容大约5-10pFPCB走线大约1-2pF/cm一个连接器大约5-20pF。如果你挂了10个器件光引脚电容就50-100pF了再加上走线和连接器很容易逼近400pF。总线电容超标的后果是什么上升时间变长波形边沿变缓在高速通信时接收端可能识别不到有效的高电平。更隐蔽的问题是电容过大导致上升沿在SCL高电平期间还没稳定SDA数据被错误采样。排查总线电容问题的方法用示波器测上升时间反推电容值C tr / (0.847 × R)如果电容超标可以考虑用I2C缓冲器/中继器把总线分段每段电容独立计算减少总线上的器件数量或者换用更低电容的器件缩短走线长度避免长距离平行走线2.4 上拉电阻小了不通信反直觉的故障分析热搜词里有一个“i2c上拉电阻小了不通信”这个现象确实存在而且很反直觉——按理说电阻小上升沿更快应该更稳定才对。但实际中上拉电阻过小会导致几个问题第一灌电流超标。前面算过电阻越小灌电流越大。当灌电流超过器件的额定值时开漏MOS管可能进入饱和区甚至损坏VOL升高低电平识别出错。第二电源跌落。多个设备同时拉低总线时总灌电流是叠加的。如果总线上有5个设备同时拉低每个灌电流3mA总共15mA如果电源走线阻抗稍大VDD会瞬间跌落导致其他设备复位或误动作。第三EMI问题。上升沿太陡会引入高频谐波长走线时形成天线效应干扰周边电路。所以上拉电阻不是越小越好必须在一个合理的窗口内。我一般的经验是先用示波器测当前波形的上升时间如果上升时间远小于规格上限说明电阻可以适当加大如果上升时间接近或超过上限说明电阻需要减小但要同时检查灌电流。3. 协议层核心时序、数据帧与SCL的角色3.1 I2C时序图到底在说什么很多人看I2C时序图觉得眼花缭乱其实核心规则就几条空闲状态SCL和SDA都是高电平。起始条件STARTSCL为高时SDA由高变低。停止条件STOPSCL为高时SDA由低变高。数据有效SCL为高期间SDA必须保持稳定SDA的变化只能发生在SCL为低期间。应答ACK/NACK每传输8位数据后接收方在第9个时钟周期拉低SDA表示ACK保持高表示NACK。这几条规则看起来简单但实际调试中大部分问题都出在对这些规则的违反上。比如起始条件不干净、数据在SCL高电平期间跳变、ACK时序不对齐等等。我用一个具体的例子来说明。假设你要往一个EEPROM写一个字节完整的时序是这样的主机发送START条件。主机发送7位从机地址1位写标志0共8位。从机拉低SDA发出ACK。主机发送8位数据。从机发出ACK。主机发送STOP条件。每一步的SCL和SDA配合都有严格的时间要求。以快速模式400kHz为例关键时间参数包括参数含义最小值最大值单位fSCLSCL时钟频率0400kHztHD;STA起始条件保持时间0.6-μstLOWSCL低电平时间1.3-μstHIGHSCL高电平时间0.6-μstSU;STA重复起始建立时间0.6-μstHD;DAT数据保持时间00.9μstSU;DAT数据建立时间100-nstSU;STO停止条件建立时间0.6-μstBUF停止到起始的空闲时间1.3-μs这些参数在调试时非常关键。比如tSU;DAT要求数据在SCL上升沿之前至少100ns就稳定如果你的上拉电阻太大导致上升沿太缓SCL到达高电平阈值的时间推迟实际留给数据建立的时间就不够了。3.2 SCL的频率不是你想设多少就设多少SCL时钟频率由主机产生但并不是主机想设多少就设多少。它受几个因素制约第一从机的最大支持频率。不是所有I2C器件都支持400kHz或1MHz。很多老式EEPROM只支持100kHz你设400kHz它根本不响应。查数据手册确认从机的fSCL最大值是第一步。第二总线电容和上拉电阻决定的上升时间。前面算过上升时间必须小于规格值否则高速通信时波形失真。第三主机的时钟分频精度。很多MCU的I2C外设通过分频系统时钟来产生SCL分频系数是整数实际频率可能偏离目标值。比如目标400kHz系统时钟72MHz分频后可能是387kHz或412kHz需要确认在从机容忍范围内。第四多主仲裁时的时钟同步。多主系统中SCL的实际频率由所有主机的低电平周期叠加决定最终频率可能低于任何单个主机的设定值。我在实际项目中遇到过一个问题MCU设的400kHz但示波器测出来只有320kHz左右。排查后发现是SCL上升沿太缓从机在SCL还没完全到高电平时就开始计时导致实际高电平时间被拉长等效频率降低。换了小阻值上拉电阻后频率恢复到接近400kHz。3.3 数据帧格式地址、读写位与应答I2C的数据帧格式是固定的起始条件后第一个字节是7位从机地址1位读写标志。读写标志为0表示写为1表示读。第9位是从机的ACK。7位地址意味着总线上最多可以有127个设备地址0x00是通用呼叫地址0x01-0x7F是普通地址。实际中很多器件地址是固定的或者只有几个引脚可以配置地址所以挂多个同型号器件时要注意地址冲突。10位地址模式也存在但用得少这里不展开。应答机制是I2C可靠性的重要保障。每次传输8位数据后接收方必须给出ACK或NACK。主机读数据时读完最后一个字节后要发NACK告诉从机停止发送然后发STOP条件。常见问题从机不响应ACK。原因可能是地址不对、从机没上电、从机复位中、总线被拉死等。排查时先用示波器看第9个时钟周期SDA是否被从机拉低如果没有说明从机没应答。3.4 时钟拉伸从机反制主机的唯一手段时钟拉伸Clock Stretching是I2C的一个独特机制。从机如果来不及处理数据可以在ACK阶段拉低SCL强制主机等待。主机必须检测SCL是否真的被释放才能继续发时钟。这个机制在软件模拟I2C时特别容易出问题。很多软件I2C实现只负责输出SCL不检测SCL的实际电平从机拉伸时钟时主机照常发时钟导致数据错乱。正确的做法是主机在释放SCL后要读回SCL引脚电平确认它真的变高了再继续下一步。硬件I2C外设通常自动处理这个逻辑但软件模拟时必须手动实现。我调试过一个PMBus设备PMBus基于I2C物理层从机在转换数据时会拉伸时钟长达几毫秒。主机如果不支持时钟拉伸读回来的数据全是0xFF。后来在软件I2C里加了SCL回读判断问题解决。4. 多主仲裁当两个主机同时开口说话4.1 仲裁的物理基础线与逻辑的天然优势多主仲裁是I2C最精妙的设计之一。它之所以能实现根本原因还是开漏输出的线与特性。想象一个场景两个主机同时想发数据。它们各自输出自己的SDA和SCL波形。由于线与逻辑总线上的实际电平是两者相与的结果。如果主机A输出高释放总线主机B输出低拉低总线总线实际是低。主机A读回SDA发现是低但自己输出的是高就知道发生了冲突立即退出仲裁转为从机接收模式。主机B继续发送不受影响。这个过程是非破坏性的赢得仲裁的主机甚至不知道发生过冲突数据继续正常传输。输掉的主机退出后可以稍后重试。仲裁可以在两个地方发生SDA线上和SCL线上。SDA仲裁决定哪个主机发送的数据优先低电平优先SCL仲裁决定时钟同步。4.2 SDA仲裁的逐位过程SDA仲裁是逐位进行的。每个主机在发送每一位时同时读回SDA线的实际电平。如果自己发的是1释放但读回是0说明有别的设备在拉低自己失去仲裁权。举个例子主机A要发地址0x50二进制1010000主机B要发地址0x48二进制1001000。从最高位开始比较第1位A发1B发1总线为1都读回1继续。第2位A发0B发0总线为0都读回0继续。第3位A发1B发0总线为0线与A读回0但自己发的是1A失去仲裁退出。B继续。最终B赢得仲裁A转为接收模式。整个过程没有数据丢失也没有总线冲突。4.3 SCL同步慢的主机说了算SCL仲裁和SDA不同它不是“赢者通吃”而是同步。所有主机的SCL输出也是线与的任何一个主机拉低SCL总线就是低。所以SCL的低电平周期由最慢的主机决定高电平周期由最快的主机决定。具体来说每个主机在拉低SCL后开始计时低电平周期时间到了就释放SCL。但如果有另一个主机还在拉低SCL保持低直到所有主机都释放。然后SCL被上拉电阻拉高所有主机开始计时高电平周期同样由最慢的主机决定何时拉低。最终效果是SCL频率等于所有主机中最慢的那个但高电平和低电平的占空比可能被不同主机影响。这就是为什么多主系统中实际SCL频率往往低于任何单个主机的设定值。4.4 仲裁失败后的处理与重试策略仲裁失败的主机必须立即释放SDA和SCL切换到从机接收模式并准备在总线空闲后重试。重试策略很关键。如果两个主机频繁冲突每次都同时重试可能永远在冲突。常见的做法是加入随机退避仲裁失败后等待一个随机时间再重试。但I2C规范没有强制要求退避算法具体实现取决于软件。我在一个多MCU系统里遇到过仲裁问题两个MCU都要读同一个传感器冲突概率很高。后来改成主从架构一个MCU专门负责读传感器另一个通过串口获取数据彻底避免了仲裁。所以有时候避免仲裁比优化仲裁更简单有效。4.5 多主仲裁的边界条件与常见误区多主仲裁有几个容易踩的坑第一仲裁不能在START条件之前发生。如果两个主机在总线空闲时同时发START仲裁从地址的第一位开始。但如果一个主机在另一个主机传输过程中发START重复起始可能产生复杂的时序。第二仲裁失败的主机必须立即停止驱动SDA。如果延迟了几个时钟周期才释放可能已经输出了错误的数据位干扰赢得仲裁的主机。第三时钟拉伸和仲裁可能同时发生。从机拉伸时钟时主机不能判断是仲裁冲突还是从机在拉伸需要结合上下文分析。第四不是所有I2C外设都支持多主模式。很多MCU的硬件I2C只支持单主软件模拟才能实现多主。选型时要确认。5. 实操调试从波形到代码的完整排查链路5.1 逻辑分析仪抓I2C波形的正确姿势逻辑分析仪是调I2C最常用的工具。但很多人抓波形的方式不对导致分析困难。首先采样率要足够。I2C快速模式400kHzSCL周期2.5μs上升沿可能只有几百ns。逻辑分析仪的采样率至少要是SCL频率的10倍以上建议用10MHz以上采样率。如果采样率不够上升沿会被采样成几个点看不出细节。其次触发条件要设对。抓I2C通常用START条件触发SCL高时SDA下降沿。这样能抓到完整的传输帧。如果要抓特定地址可以设置地址匹配触发。第三解码器要配置正确。逻辑分析仪的I2C解码器需要设置正确的地址位数7位或10位、SCL/SDA通道、时钟极性等。配置错了解码结果全是乱的。我一般会同时抓SCL、SDA和从机的中断引脚如果有这样能把总线活动和从机的实际响应对应起来。有时候总线看起来正常但从机没响应看中断引脚就知道是从机没处理还是根本没收到。5.2 示波器看上升时间和信号完整性逻辑分析仪看协议示波器看物理层。两者配合才能完整诊断。用示波器看I2C重点看几个东西上升时间从10%到90%的时间对照规格值。低电平电压VOL是否在器件规格内通常0.4V以下。高电平电压VOH是否足够高通常0.7×VDD以上。过冲和振铃上升沿是否有过冲可能引起EMI或误触发。SCL和SDA的时序关系数据是否在SCL高电平期间稳定。测上升时间时探头要用低电容探头10pF否则探头本身的电容会改变波形。我见过有人用普通10x探头测I2C上升时间测出来比实际大了一倍就是因为探头电容。5.3 常见故障速查表下面这张表是我这些年积累的I2C故障排查速查表按现象分类现象可能原因排查方法解决方案完全无通信上拉电阻缺失、电源未上、地址错误测SCL/SDA静态电平、查地址加上拉、检查电源、核对地址起始条件后无ACK从机地址不对、从机未就绪示波器看第9时钟SDA核对地址、加延时等待从机通信时好时坏总线电容超标、上拉电阻偏大测上升时间、算电容减小上拉、加缓冲器、缩短走线高速时失败低速正常上升时间不满足规格测上升时间减小上拉电阻多设备时冲突地址冲突、仲裁失败逐个断开设备测试改地址、加仲裁退避读回全0xFF从机未响应、时钟拉伸未处理看ACK、看SCL是否被拉伸检查从机、实现时钟拉伸波形有振铃走线阻抗不匹配、上拉过小示波器看边沿加大上拉、加串联电阻SCL被拉死从机复位中、总线死锁测SCL电平发9个时钟脉冲解锁、复位从机5.4 总线死锁与恢复技巧I2C总线死锁是一个经典问题从机在发送数据时被复位SDA被拉低主机等待ACK超时总线卡死。或者主机在传输过程中复位SCL和SDA状态不确定。恢复方法主机发送9个SCL脉冲不驱动SDA让从机完成当前字节的发送并释放SDA然后发STOP条件。如果从机是状态机卡死9个脉冲通常能让它回到空闲状态。具体操作配置SCL为推挽输出SDA为输入。发送9个SCL脉冲频率低于100kHz。检查SDA是否变高。如果变高发STOP条件SCL高时SDA由低变高。如果不变高可能需要硬件复位从机。很多MCU的I2C外设有总线恢复功能但软件模拟I2C需要自己实现。我在产品固件里都会加一个总线恢复函数上电初始化时先调用一次防止上次异常复位留下的死锁。5.5 软件模拟I2C的注意事项很多项目因为硬件I2C外设不够用或者引脚分配限制需要用GPIO模拟I2C。软件模拟有几个关键点第一延时精度。SCL频率由延时决定延时不准会导致频率偏差。用示波器校准延时确保SCL频率在从机容忍范围内。第二开漏配置。GPIO必须配置为开漏输出否则推挽输出会与总线上的其他设备冲突。很多MCU的GPIO支持开漏模式配置寄存器即可。第三时钟拉伸处理。前面说过软件模拟必须回读SCL电平确认从机释放了时钟再继续。第四中断干扰。软件模拟I2C对时序敏感中断可能打断延时导致时序错乱。关键传输段要关中断或者用硬件定时器产生精确延时。第五多主支持。软件模拟实现多主仲裁比较复杂需要逐位回读SDA和SCL。如果项目不需要多主可以简化实现。6. 从EEPROM到PMBusI2C生态的扩展与变体6.1 I2C读写EEPROM的典型流程EEPROM是I2C最经典的应用场景。以AT24C02为例写一个字节的流程发START。发设备地址写标志0xA0。发字节地址0x00-0xFF。发数据字节。发STOP。等待写周期完成约5ms期间EEPROM不响应任何命令。读一个字节的流程发START。发设备地址写标志0xA0。发字节地址。发重复START。发设备地址读标志0xA1。读数据字节发NACK。发STOP。注意第6步发NACK而不是ACK告诉EEPROM数据读完了。如果发ACKEEPROM会继续输出下一个字节。页写模式可以一次写多个字节通常8-32字节但跨页写会回卷到页首覆盖之前的数据。这是新手常踩的坑。6.2 PMBus与I2C的区别PMBus是建立在I2C物理层之上的电源管理协议。它复用I2C的电气规范和基本时序但增加了自己的命令集和数据格式。主要区别PMBus有标准的命令代码如0x01读输出电压、0x02读输出电流。PMBus支持PECPacket Error Checking在数据后加一个CRC字节。PMBus的时钟频率通常固定为100kHz或400kHz。PMBus设备通常支持时钟拉伸因为电源转换需要时间。调试PMBus时逻辑分析仪的I2C解码器可以直接用但命令解析需要查PMBus规范。很多电源芯片的数据手册会列出支持的PMBus命令和格式。6.3 I2C缓冲器与中继器的使用场景当总线电容超标或者需要长距离传输时I2C缓冲器/中继器是解决方案。它的原理是把总线分成两段每段独立计算电容和上拉电阻缓冲器负责在两段之间转发信号。常见的使用场景总线电容超过400pF。需要热插拔设备避免单个设备故障拉死整条总线。不同电压域之间的电平转换缓冲器同时完成电平转换。选型时注意缓冲器是否支持时钟拉伸、仲裁和双向传输。有些便宜的缓冲器只支持单向不能用于I2C。6.4 鸿蒙开发板上的HID over I2C热搜词里提到了“鸿蒙开发板带hid over i2c”这是一个比较新的应用场景。HID over I2C是微软提出的协议用于触摸屏、键盘等输入设备通过I2C与主机通信。它的物理层和I2C完全兼容但协议层有自己的描述符和报告格式。调试时先用逻辑分析仪确认I2C层通信正常再分析HID描述符。鸿蒙系统对HID over I2C有原生支持开发板上通常有对应的驱动。如果自己移植需要注意中断引脚的处理——HID设备通过中断引脚通知主机有数据主机再发起I2C读操作。7. 一些零散但重要的经验7.1 100kHz信号规格的实际含义热搜词里有“100k i2c信号规格”这里补充一下。100kHz是I2C标准模式的最大时钟频率但实际波形不是精确的100kHz。规范允许一定偏差关键是满足时序参数tLOW、tHIGH、tr、tf等。100kHz模式下SCL周期10μs低电平至少4.7μs高电平至少4.0μs。上升时间不超过1000ns下降时间不超过300ns。这些参数在调试时用示波器逐项核对。7.2 I2C编码器的概念有人搜“i2c编码器”这可能指的是两种东西一种是I2C接口的旋转编码器用于旋钮输入另一种是I2C协议编码/解码工具。前者是器件后者是调试工具。如果是器件注意它的地址和寄存器映射如果是工具逻辑分析仪自带的解码器就够用。7.3 UART、SPI、I2C、CAN的选型对比这四种总线各有适用场景总线线数速率多主距离典型应用UART2低-中否短调试串口、模块通信SPI4高否短Flash、显示屏、高速传感器I2C2中是短传感器、EEPROM、PMBusCAN2中是长汽车、工业控制I2C的优势是线少、支持多主多从、有标准协议劣势是速率中等、总线电容受限、长距离需要中继。选型时根据速率、距离、设备数量、成本综合判断。7.4 逻辑分析仪分析I2C数据的技巧除了基本的协议解码逻辑分析仪还有一些高级用法条件触发设置地址匹配触发只抓特定设备的通信。数据过滤只显示包含特定数据的帧快速定位问题。时序测量自动测量SCL频率、占空比、上升时间等参数。多通道关联同时抓I2C和从机的中断引脚分析响应时间。我用逻辑分析仪的习惯是先抓一段完整通信看协议层是否正常如果有问题再用示波器看物理层波形两者结合基本能定位90%以上的问题。7.5 最后再分享几个实操小技巧第一个上拉电阻可以分开画。SDA和SCL各用一个电阻不要共用。虽然理论上可以共用但实际布局时分开更灵活调试时也可以单独调整。第二个预留上拉电阻的焊盘。PCB设计时上拉电阻位置留两个焊盘一个装电阻一个可以装电容或直接短接。调试时可以根据需要调整。第三个I2C走线尽量短且等长。SCL和SDA并行走线长度差控制在几毫米内避免时序偏差。远离高频信号线减少串扰。第四个从机地址冲突时可以用I2C多路复用器如TCA9548A扩展。一个多路复用器可以把总线分成8路每路挂相同地址的器件通过选择通道来访问。第五个调试时先降速。如果400kHz不通先降到100kHz试试。100kHz通了说明物理层基本没问题再逐步提速找瓶颈。这些经验都是实际项目中积累的有些是踩坑后总结的有些是跟同行交流学到的。I2C看起来简单但细节非常多每一个参数背后都有它的道理。把物理层搞扎实协议层自然就通了物理层有问题协议层再怎么调也是白搭。