做嵌入式这些年我最怕听到的一句话就是“这个I2C总线上到底挂了哪些设备怎么扫了半天扫不全”。尤其是板子上一挂五六个器件、总线还想跑1000KHz的时候问题一个比一个多。最近我手头一个项目就是这样主板挂了六个I2C从机主控打算直接上1MHz总线速率。我哪敢直接就写驱动跑先在调试阶段拿USB转I2C适配器把全部地址扫一遍确认设备在不在、能不能在高速下正常响应。当时建的测试工程名字就叫“USB TO I2C_(Excel)_Scan ---- 1000KHz总线速率测试_A”一眼看过去像乱码其实信息量很大USB转I2C代表硬件链路Excel代表结果输出格式Scan是扫描动作1000KHz是整个测试的速率基准最后的_A是批次标记。这篇文章我把从接线、配置、扫描到出Excel报表的完整过程盘一遍硬件工程师、嵌入式软件开发、测试人员和所有在I2C上栽过跟头的人都用得上照着做你也能跑出一份可追溯的总线扫描报告。1. 项目整体拆解一行标题里的三层工程需求1.1 USB转I2C的硬件链路为什么我选了FT2232HUSB转I2C说白了就是一个桥接器PC端通过USB发命令桥接芯片把命令翻译成I2C的SCL/SDA时序波形。市面上常见方案有好几类我直接列个表对比一下方案典型芯片I2C速率能力成本/上手难度适合场景FTDI MPSSE方案FT2232H / FT232H最高可到数MHz1MHz稳定中需要D2XX开发自研工具、产测脚本专用I2C Host方案FT4222H内置硬件I2C控制器官方支持Fm 1MHz中有现成LibFT4222快速搭建PC端测试开源调试器Bus Pirate固件决定通常400kHz稳定低开箱即用现场手工调试商业分析仪Total Phase Aardvark型号不同常见到1MHz左右高自带成熟软件实验室正式测试我这次用的是FT2232H原因有三个。其一这芯片里的MPSSEMulti-Protocol Synchronous Serial Engine是一个硬件状态机USB命令进来后直接产生时钟和数据沿不占CPU时序重复性好。其二FT2232H和FT232H的MPSSE流程几乎一样代码可以复用我手头正好有料。其三它内部时钟能扛住数MHz的SCL频率跑1MHz时留足了余量。MPSSE的原理用一句话讲PC往USB端点写一组指令字节芯片就把这些字节解析成“拉高SCL”“把SDA置为输出低电平”“读一个bit”这类原子操作按顺序执行。这和单片机里用GPIO模拟I2C不是一回事——MCU模拟受中断、任务调度影响1MHz下容易时序抖动MPSSE是硬件排队时序稳定出错可复现这对定位问题非常关键。注意FT2232H/FT232H要工作在MPSSE模式必须安装FTDI的D2XX驱动而不是虚拟串口VCP驱动。插上设备后如果只看到两个COM口说明还停在默认的串口模式这时候I2C扫不出任何东西。这是新人最容易踩的坑后面第4部分会细说。1.2 1000KHz意味着什么I2C速率模式与时序参数I2C总线协议规范里速率分三个大档标准模式100kHz、快速模式400kHz、快速模式Fm1MHz。项目标题里的1000KHz就是第三档。很多人觉得无非是把时钟调快点其实1MHz对时序的要求是成倍变严的我整理了一张关键参数对照表时序参数标准100kHz快速400kHz快速 1MHzSCL高电平最小 t_HIGH4.0 µs0.6 µs0.26 µsSCL低电平最小 t_LOW4.7 µs1.3 µs0.5 µs数据建立时间最小 t_SU;DAT250 ns100 ns50 ns数据保持时间最小 t_HD;DAT000上升沿最大 t_r1000 ns300 ns120 ns下降沿最大 t_f300 ns300 ns120 nsSTOP建立时间最小 t_SU;STO4.0 µs0.6 µs0.26 µs这张表说明了为什么1MHz难SCL高电平只剩260ns上升沿允许的最大值只有120ns。注意高电平和上升沿是两个概念——SCL周期1µs高电平半周期是500ns但协议要求最差情况高电平≥260ns、上升沿≤120ns留给中间稳定区的时间并不多。如果线上电容大、上拉电阻偏高波形变圆上升沿超过120ns从设备采样点就不满足要求通信就会时好时坏。这就引出上拉电阻的计算。I2C的上拉电阻和总线电容构成RC充电回路上升时间约等于0.8473 × R × C。1MHz下要求t_r ≤ 120ns假设PCB走线加几个器件的寄生电容总共200pF那么R ≤ 120ns / (0.8473 × 200pF) ≈ 708Ω。所以1MHz总线上拉电阻建议680Ω甚至470Ω而不是常见的4.7kΩ。但上拉电阻也不是越小越好它要满足低电平输出时的灌电流限制R ≥ (VDD - VOL) / IOL。以3.3V电源、VOL0.4V、IOL3mA计算下限约966Ω。这里就看从器件的IOL能力了我实测大部分现代传感器和EEPROM的IOL都能到20mA470Ω完全OK但老器件就得小心先查数据手册再定值。1.3 Excel后缀背后的测试报表思维“(Excel)_Scan”不是随手起的扫描这件事如果不落成文档等于白扫。测试工程名里带Excel本质上是在强调“结果要能被人直接看懂、能追溯、能对比”。我的文件名规范里_A代表批次或轮次。同一块板改版、换了上拉电阻、改了走线之后文件名依次变B、C、D扫描数据就能一笔一笔对回去。这比在桌面上堆一堆“scan1.csv”要靠谱得多——等你想知道上一版为什么稳定时翻文件名和表头就能还原现场。输出Excel的思路也有讲究。工具直接生成CSV是最省事的然后转成xlsx方便加格式但如果你后面要做多速率对比我更建议直接用Python把CSV灌进Excel工作簿每个速率一个sheet放在同一个文件里。Excel里还可以做条件格式把NACK次数异常的格子直接标红扫一眼就知道哪里不对。2. 扫描器的核心逻辑地址探测与时钟配置2.1 I2C地址探测的本质一个ACK位决定设备在不在I2C总线上挂的设备怎么被发现原理其实很简单主控发起一个START条件然后把目标地址作为一个字节发出去——7位地址左移一位最低位填读写方向填0表示写。接着释放SDA线等待第九个SCL周期。总线上的从设备会把地址字节的高7位和自己比对匹配就拉低SDA表示ACK不匹配就释放总线表现为NACK。扫描器就这么挨个地址试一遍。要扫哪些地址7位地址范围0x00~0x7F共128个但两头有保留地址0x00~0x07是通用呼叫、CBUS、高速模式主码等保留段0x78~0x7F是10位地址扩展和保留段。常规扫描一般从0x08扫到0x77共112个地址。如果你在结果里看到0x00或0x7F附近的地址出现先别高兴大概率是总线时序异常导致误判而不是真有设备。关于用读位还是写位探测绝大多数I2C从设备在地址匹配时无论读还是写方向都要回应ACK所以用W位0探测就够了。个别传感器只在特定方向响应如果扫不到可以再补一轮R位1扫描。两种方向都试过还是没有那就真没有。2.2 MPSSE时钟分频从内部时钟算出1MHz你可能会问1MHz的SCL时钟是怎么来的MPSSE引擎内部时钟是固定的FT2232H为60MHz通过一个16位分频寄存器配置。核心公式是SCL 60MHz / ((1 N) × 2)要得到1MHz代入计算N 60 / 2 / 1 - 1 29写成十六进制就是0x001D。这个除以2是因为一个完整SCL周期里高电平和低电平各占半个时钟除以(1N)则是分频器的实际分频比。注意这个配置下SCL的占空比是50%高电平500ns、低电平500ns。对照前面Fm的要求t_HIGH ≥ 260ns、t_LOW ≥ 500ns低电平刚好压线高电平还有余量整体不算宽裕。所以实际测试时我不会只看理论值而是用示波器抓一遍SCL波形确认上升沿有没有超过120ns。这也是为什么标题里叫“总线速率测试”测试的对象从来不只是工具软件而是整条物理链路。2.3 扫描策略重试、重复起始与记录格式单个地址只发一次、收到NACK就直接跳过这在低速下问题不大高速下就可能漏检。因为某些传感器上电后要自检几十毫秒或者处在复位状态还没准备好应答第一枪不响应是正常的。我的做法是每个地址连扫3次三次里只要有一次ACK就算命中同时记录ACK次数。这样既避免漏报又能通过ACK次数判断设备稳定性——三次全中说明稳两中一丢就要警惕。连续扫描多个地址时不要每个地址都走完整的START-地址-ACK-STOP。因为STOP之后有最小总线空闲时间t_BUF1MHz下也要0.5µs地址数量多起来累计就是不小的开销。我的扫描器在连续探测时用重复起始条件REPEATED START串接只有一轮扫完才发STOP既省时间又减少总线扰动。地址扫描过程我直接按CSV一行行流式输出格式固定为address, rw, ack_count, speed_khz, timestamp。这样即使中途断电之前的数据都已经落盘不会丢。CSV本身是纯文本Excel、Python、文本编辑器都能打开通用性最好。3. 实操全记录从接线到Excel出报告3.1 环境与物料清单我这次测试的对象是一块自研传感器板上面挂了六个I2C从机SSD1306 OLED地址0x3C、一颗六轴传感器0x48、AT24C02 EEPROM0x50、PCF8563 RTC0x51、TCA9548A多路复用器0x70、GT911触控IC0x5D这里属于另一个模块。物料清单很简单FT2232H转接模块一个USB线一根杜邦线若干尽量短超过20cm会影响高速时序470Ω上拉电阻两个替换板上的4.7kΩ3.3V电源测量确认稳定示波器至少100MHz带宽用来抓SCL/SDA波形PC一台Windows 10装FTDI D2XX驱动这里有个重要的坑要提前说GT911这颗触控IC的I2C接口电平域是1.8V我第一版图省事直接挂到3.3V总线上结果扫描时它时有时无NACK频率很高。后来查数据手册发现VDDIO引脚必须接1.8V中间加了一片TXS0108E电平转换之后1MHz下才稳定ACK。如果你的板上有1.8V或者2.5V的器件别直接往3.3V总线上怼先看手册确认电平域。3.2 驱动安装与MPSSE模式确认在Windows下FT2232H插上后如果只看到两个COM口说明驱动是VCP模式MPSSE工具根本打不开设备。正确做法是用FTProg工具把通道模式切换到“FT2232H Serial/MPSSE”再确保设备管理器里识别为“USB Serial Converter”而不是COM口然后才能被D2XX API调用。这个过程我遇到过好几次同事拿我的工具去用插上之后怎么也扫不到设备一看设备管理器两个COM口明晃晃地挂着。其实不是工具坏了是驱动不对。FTDI的芯片很灵活同一颗芯片既可以是USB转串口也可以是MPSSE关键看你怎么配。切到MPSSE模式之后用官方提供的FT_Prog重新枚举一次设备工具就能正常打开了。3.3 执行一次1MHz扫描工具准备好以后命令行执行扫描参数包括速率、扫描范围、重试次数和输出文件usb-i2c-scan.exe --speed 1000000 --start 0x08 --end 0x77 --retry 3 --output scan_1M_A.csv执行过程中的输出大概是这样的[INFO] FT2232H opened, channel A, MPSSE mode [INFO] SCL frequency 1000 kHz (divisor 0x001D) [INFO] scanning 0x08..0x77, retry3 0x3C ack3/3 OK 0x48 ack3/3 OK 0x50 ack2/3 WARN 0x5D ack3/3 OK 0x70 ack3/3 OK [INFO] scan done: 112 addresses, 5 found, duration 412ms扫描112个地址、每个地址重试3次总共三百多次探测耗时大概400毫秒绝大部分时间其实花在USB传输和软件循环上纯I2C波形时间只有几个毫秒。这个速度对调试来说完全够用。结果里0x50显示ack2/3说明AT24C02有一次没有正确应答EEPROM在忙或者总线被占用是常见原因这就是需要重点核查的对象。3.4 结果导出到ExcelCSV转xlsx的实操CSV文件直接拖进Excel也能看但地址列特别容易出问题——0x3C会被识别成文本或者科学计数法。我的习惯是用Python一次性转成带格式的xlsx顺便把WARN的行标黄把地址列格式化成标准的0x形式import csv from openpyxl import Workbook from openpyxl.styles import PatternFill wb Workbook() ws wb.active ws.title I2C Scan 1MHz A with open(scan_1M_A.csv, encodingutf-8) as f: reader csv.reader(f) for row in reader: ws.append(row) # 地址列A列强制设置为文本格式保留0x前缀 for row in ws.iter_rows(min_row2, min_col1, max_col1): for cell in row: if isinstance(cell.value, str) and cell.value.startswith(0x): cell.number_format # 把包含WARN的行标黄 yellow PatternFill(start_colorFFFF00, end_colorFFFF00, fill_typesolid) for row in ws.iter_rows(min_row2): if row[2].value and WARN in str(row[2].value): for cell in row: cell.fill yellow wb.save(scan_1M_A.xlsx)这样做的好处是表格给任何人看都一目了然绿色标OK黄色标WARN地址格式统一成0x日期和速率列齐全追溯的时候直接翻文件就行。4. 踩坑实录1MHz扫描不稳定的几个真问题4.1 漏检与闪烁上拉电阻和线缆电容第一次跑1MHz扫描时板子上用的是标准4.7kΩ上拉结果连扫8轮只有3轮能扫到全部设备SSD1306经常漏。用示波器一抓SCL上升沿已经400多ns远超120ns上限。当时第一反应是工具坏了后来才知道是上拉电阻太大、总线电容充放电太慢。换成680Ω后上升沿大概100ns出头再换成470Ω后稳定在70ns左右扫描结果连续20轮全绿。除了电阻杜邦线也是电容大户线越长、绞在一起越厉害电容越大。所以高速I2C调试尽量用短线或者干脆在PCB上直接联调杜邦线只用于初始验证。4.2 总线挂死SDA被从设备拉死测试中途我碰到过一次所有地址全部NACK但SDA线一直为低、SCL还在跳的情况。这就是SDA被某个从设备拉死了。I2C是开漏结构任何设备都能把SDA拉低一旦有个设备异常整条总线就废了。处理办法有三个层级先用协议层面的时钟恢复技巧——给SCL连续敲9个时钟脉冲让处于异常状态的从机释放SDA不行就断开可疑设备单独扫描定位元凶最彻底的是给出问题的从机单独断电复位。预防手段是扫描前给每个从机一个定义好的复位时序等上电稳定后再开扫尤其是GT911这类触控IC复位时序不规范就会死拽着总线不放。4.3 设备在总线上却NACKGH911电平域与复位时序GT911的案例前面提过电平不匹配这里再补充一个复位时序问题。这颗芯片的I2C从机地址是7位0x5D或者0x14由INT引脚电平决定。我最初扫描不到它以为是电平转换的问题换完电平转换后依然时有时无最后才发现它上电后必须等RST引脚按数据手册的时序拉高再拉低、INT引脚维持规定时长否则它压根不会进入正常应答状态。这给所有搞I2C的人提了个醒扫描不到设备先别急着怀疑总线多看看器件手册的电源时序要求。很多传感器、触控IC、PMIC上电后要几百毫秒才稳定扫描时机太早自然看不到。4.4 Windows下驱动与设备资源问题扫描工具打不开设备最常见的原因就是VCP驱动抢占了设备。如果设备管理器里看到的是COM口MPSSE工具是肯定打不开的必须用FTProg切模式、装D2XX驱动。还有一种情况是Windows报代码12“设备资源不足”这个在我外置USB转I2C工具上出现过一次换了一个USB口就正常了。内置HID over I2C设备报代码12则要检查BIOS里I2C控制器资源是否被占用或者更新芯片组驱动。这类问题通常和环境有关不是扫描工具本身的bug。4.5 常见问题速查表现象可能原因处理办法1MHz下设备漏检、时好时坏上拉电阻过大、线缆电容大换470Ω/680Ω缩短杜邦线SDA恒低所有地址NACK某从设备拉死总线敲9个SCL时钟释放断电复位隔离排查1.8V器件在3.3V总线上不响应电平域不匹配加TXS0108E等电平转换MPSSE工具打不开只有COM口VCP驱动抢占FTProg切MPSSE模式重装D2XXUSB设备报代码12资源不足端口/驱动冲突换USB口重装驱动更新BIOSExcel地址列变科学计数法Excel默认格式问题单元格设置为文本或用0x前缀扫描到0x00或0x7F附近地址总线时序异常检查上拉和线缆降速到400kHz验证5. 扫描数据怎么解读以及测试还能怎么扩展5.1 一张扫描表读出系统健康度回到这次的扫描结果总共扫出5个设备0x3C、0x48、0x50、0x5D、0x70和原理图上的器件地址完全对得上说明总线接线和器件配置基本正确。唯一需要关注的是0x50的ack2/3AT24C02在高速探测时偶尔不响应这在量产后就是隐患。我的建议是不要只跑一次1MHz扫描就完事而是把100k、400k、1M三档速率各扫一遍然后把三份结果放到同一个Excel工作簿里三列地址平行排列条件格式高亮差异。这样一眼就能看出哪些器件在高速掉链子哪些器件全程稳定。多速率对比特别适合验证改版后是否解决了前一版的问题。5.2 从静态扫描到长期稳定性测试标题叫“总线速率测试”单次扫描其实只是一小步。扫一次只能说明“这个时刻、这个状态”下设备存在不能说明它一直稳定。我后来写了个循环脚本让工具连续扫描1000轮每轮都记录所有设备的ACK率。这样数据出来就是一个按百分比分级的结果100%全绿95%到99%黄低于95%直接红。更进一步的玩法是扫描前记录VDD电压利用USB转I2C工具顺带读一颗板上的电源监控ADC在不同供电条件下跑1MHz扫描确认总线的速率边界在哪里。不过这些属于扩展内容这篇先留个尾巴以后再单独写一篇长期稳定性测试的实操。我在实际跑完这次1MHz扫描之后最大的感受是工程命名规范和测试习惯比工具本身更值钱。项目标题里的_A一定要保留等你做B版、C版的时候回头看第一轮的数据才能说清楚改进到底有没有用。最后再分享一个小技巧不管工具多好用扫描前先用示波器看一眼SCL和SDA的波形特别是1MHz下上升沿有没有超过120ns。波形过关了再谈地址对不对。总线速率测试这件事本质测的不是“软件能不能发1MHz”而是整条硬件链路在1MHz下还讲不讲规矩。
