前几天整理测试记录翻到一个以_A结尾的老工程命名是USB TO I2C_(Excel)_Scan ---- 3400KHz总线速率测试。这个命名方式一看就是当时随手起的_A表示第一版等踩完一轮坑改成_B再改就是_C。但标题背后其实是一个很实用的工具组合——用Excel表格做I2C扫描终端通过USB转I2C适配器去读从设备还要在3.4MHz高速模式下验证总线速率。这类需求在产线测试、FAE快速验证、芯片选型评估里非常常见。本文就把这套方案的完整思路、硬件选型、软件链路、实测过程和踩坑记录整理出来给要做类似测试工具的朋友一个可以直接参考的样本。1. 这个命名背后把Excel当I2C扫描终端的设计动机1.1 一个_A后缀的测试工程引出的工具思路很多硬件工程师和测试工程师手里都有USB转I2C的小工具但绝大多数人只用配套的PC软件点几下按钮、读几个寄存器就关了。等到要批量测试、重复扫描、记录数据的时候就要么人工一条条点要么回头用C或Python现写一个上位机写完了还要面对界面、打包、部署的一堆破事。这个项目做法不一样的地方在于把Excel当成I2C扫描的终端界面。底层是USB转I2C适配器中间用DLL把适配器操作封装起来上层用Excel的VBA去调用DLL然后在工作表里展示扫描到的设备地址、寄存器值、速率统计结果。我最早看到这种组合是在一条产线测试工位上操作员不会用命令行也不想装Python环境但Excel人人都会。于是测试工具的主界面就是一张Excel表格第一列填设备地址第二列填寄存器地址第三列填期望值点一下宏按钮I2C扫描结果就回填到后面几列。非研发人员也能直接上手测试记录天然就是表格归档和追溯都不用另外导数据。1.2 为什么选Excel而不是重写上位机这得分场景。如果是做完整的自动化测试系统那当然该用Python、LabVIEW或者C#写独立上位机界面、线程、报表都能做得很漂亮。但如果只是以下这类场景Excel作为壳子反而是最优解产线初测需要快速验证一批板子的I2C挂载设备是否存在、寄存器是否可读写方案选型要对比某颗I2C器件在不同总线速率下的表现FAE支持现场给客户演示“这个设备在3.4MHz下ACK正常”打开Excel跑一下即可固件联调主控I2C控制器还在调试中用PC侧工具先把从设备摸清楚。这种情况下写独立上位机的成本远大于收益。Excel自带表格展示、条件格式、图表、日志导出VBA虽然不算最强语言但调DLL收发I2C数据绰绰有余。这个项目的核心定位也就在此Excel只是壳I2C通信的逻辑全部下沉到底层DLLVBA负责参数组织和结果展示。1.3 这个工具适合谁来用我建议三类人参考这套方案一是硬件测试工程师需要快速验证I2C设备二是产线测试设备开发人员想把测试界面做成低门槛的表格形态三是刚接触I2C协议、想搞一套可视化扫描工具来学习协议时序的人。对于最后一类人这套方案的好处是扫描过程中随时可以在Excel里看到每个地址的ACK响应比空对空读协议文档直观得多。2. 3400KHz不是随便选高速模式的硬件门槛与信号完整性2.1 适配器选型FT232H/FT2232H为什么是首选标题里的3400KHz总线速率换算一下就是3.4MHz正好对应I2C协议里的高速模式Hs-mode。I2C有很多速率档位标准模式100kHz、快速模式400kHz、快速模式1MHz、高速模式3.4MHz。4MHz以上的速率不属于I2C标准范畴所以3.4MHz基本就是标准允许的“顶配”。要实现这个速率适配器本身得有足够高的时钟生成能力。市面上几十块钱的CH341之类的USB转I2C方案通常只能稳定跑100k~400k到了1MHz时序就已经歪得没法看更别说3.4MHz。这个项目用的方案是FTDI的FT232H或者是同系列的FT2232H原因是它们内置了MPSSE引擎Multi-Protocol Synchronous Serial Engine可以通过USB命令配置时钟分频来模拟I2C时序。FT232H内部主时钟在60MHz左右通过分频可以生成较高频率的SCL实际操作中把分频系数调到很小才能勉强摸到3.4MHz的门槛。下表是我手头几种常见USB转I2C方案的对比方案实测稳定速率上限是否支持3.4MHz备注CH341约400kHz不支持便宜胜在入门官网上限标得也不高FT232H/FT2232H MPSSE约3.4MHz可以尝试有官方DLL封装方便需注意时序抖动Cypress FX2/FX3取决于固件可以但开发成本高需要自己写固件一般项目用不到Aardvark I2C/SPI主机适配器800kHz左右不支持工具软件好用但速率上限不够FT232H也不是一插上就万事大吉。MPSSE的时钟分频寄存器是整数分频实际生成的SCL频率会和3.4MHz有偏差。当时测试记录里显示实际量到的SCL大概在3.2MHz~3.5MHz之间浮动这个偏差取决于分频系数取整和USB调度的抖动。关于这一点后文“实测与排查”一节会展开。2.2 上拉电阻、线缆与总线电容高速I2C的物理基础很多人忽略I2C是开漏总线SCL和SDA都需要外部上拉电阻把电平拉高。标准模式下面4.7kΩ上拉电阻很常见到了400kHz一般推荐2.2kΩ而3.4MHz高速模式下上拉电阻通常需要进一步减小甚至到几百欧姆同时总线上电容要严格控制。上拉电阻和总线电容共同决定了RC时间常数也就是边沿爬升速度。如果上拉电阻太大、总线电容又大时钟线的高电平边沿就会变缓3.4MHz的周期才294ns左右高电平时间可能只有100ns上下边沿要是占了三四成周期从机采样时电平还没稳定通信直接失败。当时测试用的最小配置是SCL/SDA各接1kΩ上拉电阻到3.3V总线总电容控制在几十pF以内测试线用非常短的杜邦线整体不超过10厘米。这个组合在3.4MHz下勉强稳定。如果换成长线缆哪怕只是20厘米波形上就能看到明显的振铃和过冲扫描经常出错。高速I2C到了3.4MHz这个量级PCB走线的意义大于线缆飞线能用转接板直连就别图方便拉长线。2.3 HS-mode的切换机制主设备码与重复起始3.4MHz不是直接拉高SCL频率那么简单。I2C的Hs-mode有一套完整的切换机制主机必须先以F/S模式400kHz或100kHz发送一个主设备码0000 1XXX加方向位从机收到并ACK后主机再发出重复起始条件这时候总线才正式进入高速模式SCL才能提升到3.4MHz。换句话说一次完整的高速模式传输开头是低速率握手之后才是高速数据阶段。这套机制的目的是让总线上的老设备也能兼容它们会在高速模式下忽略后续传输。所以做3.4MHz速率测试时不能只把采样频率调到3.4MHz就完事还要关注适配器是否完整实现了“F/S模式发主设备码→ACK→重复起始→高速传输”这个握手流程。FT232H的MPSSE引擎本身是基于命令序列生成时序的能不能正确模拟出这个主设备码切换过程、切换到高速模式后时序是否还能稳定是实测时需要重点观察的东西。如果逻辑分析仪抓到的波形里主设备码响应正常但重复起始后SCL频率或占空比变了多半是MPSSE命令流切换IC的阶段没处理好得靠调整命令间隔或DLL侧加延时来缓解。3. DLL到VBA的调用链Excel扫描工具的软件骨架3.1 C侧DLL的导出函数设计Excel本身是不能直接操作USB适配器的必须通过DLL。工程上正确的做法是把I2C的所有时序操作封装在一个独立的DLL里VBA只做参数组织和结果呈现。这样I2C逻辑可以复用以后想在Python或者C#里调用同一套DLL也行。DLL的导出函数可以按功能拆成几组// 初始化和关闭 int i2c_init(void); void i2c_close(void); // 地址扫描遍历指定地址范围返回有ACK的地址列表 int i2c_scan_addr_range(unsigned char start_addr, unsigned char end_addr, unsigned char *ack_list, int max_count); // 寄存器读写addr为7位从机地址reg为寄存器地址 int i2c_write_read(unsigned char addr, unsigned char reg, unsigned char *write_buf, int write_len, unsigned char *read_buf, int read_len, int rate_khz, int *ack_flag); // 速率测试连续读写指定次数返回总耗时、平均耗时和错误次数 int i2c_speed_test(unsigned char addr, unsigned char reg, unsigned char *read_buf, int read_len, int loop_count, double *avg_time_us, int *error_count);这里有个关键点rate_khz参数直接透传到驱动层DLL内部按这个值配置MPSSE的分频寄存器。在3.4MHz测试时DLL可以先查询设备支持的最大时钟再自动把分频系数调到最接近3400的值。另一个设计细节是缓冲区。地址扫描结果、寄存器读取结果都用调用方传入的缓冲区来承接返回个数由函数返回值或max_count控制。这样做的好处是VBA可以事先定义好足够大的Byte数组避免DLL内部动态分配内存导致跨语言内存管理混乱。3.2 VBA声明与32/64位Office的坑VBA调DLL的语法本身不复杂但有两个坑非常典型一是声明方式。Office有32位和64位之分64位的VBA里Declare语句必须带PtrSafe关键字32位则不需要。为了兼容通常会写条件编译#If VBA7 Then Private Declare PtrSafe Function i2c_init Lib I2CScan.dll () As Long Private Declare PtrSafe Function i2c_scan_addr_range Lib I2CScan.dll _ (ByVal startAddr As Byte, ByVal endAddr As Byte, _ ByVal ackList As LongPtr, ByVal maxCount As Long) As Long #Else Private Declare Function i2c_init Lib I2CScan.dll () As Long Private Declare Function i2c_scan_addr_range Lib I2CScan.dll _ (ByVal startAddr As Byte, ByVal endAddr As Byte, _ ByVal ackList As Long, ByVal maxCount As Long) As Long #End If二是指针传递。VBA的数组和C语言数组在内存布局上不是一回事直接把数组变量名传给DLL是不可靠的。正确做法是把DLL参数声明为指针类型LongPtr/Long然后在VBA里用VarPtr取出数组首地址再传进去或者干脆用CopyMemory把结果拷回数组。这一步在第一次调通时最容易卡住现象是程序不报错但返回的数据全是乱码或空值本质上就是指针没传对。3.3 批量读写在DLL层完成Excel只做展示VBA是解释执行的循环效率很低。如果设计成“Excel循环1000次、每次调DLL读一个寄存器”那3.4MHz测试基本没法看因为USB命令往返和VBA函数调用的开销远远大于I2C传输本身。所以这个项目在架构上做了一个关键决策所有耗时的批量操作都在DLL内部完成Excel只负责发起和收结果。比如速率测试VBA只需要调用一次i2c_speed_testDLL底层连续读写1000次内部计时、内部统计错误最后把平均耗时和错误次数返回给Excel。这样的话即使VBA界面有点慢也不影响测试数据的准确性。同样的原则也适用于地址扫描DLL内部循环发送地址读ACK把有响应的地址列表一次返回。Excel的宏按钮本质上只是“点一下等结果填表格”。这个架构让整个工具用起来相当顺手扫描过程基本上是被查询的等待时间主导而不是被VBA的执行速度拖后腿。4. 实测3.4MHz速率时的坑从“扫不到设备”到波形验证4.1 测试环境与扫描步骤记录实测环境尽量做到“干净”FT232H适配器直接插在PC的USB口上SCL/SDA/GND三根线用最短的杜邦线连接到目标I2C从设备。从设备用了一颗支持高速模式的EEPROM然后接上逻辑分析仪采样率设为100MHz这样可以用足够的采样点去还原3.4MHz的波形细节。完整的扫描步骤记录可以这样分解先用400kHz快速模式做一轮完整地址扫描确认最小系统能通、从机设备能ACK作为基准把速率参数配置到3400kHz再跑同一轮地址扫描观察是否有地址消失、超时或错误返回对已知地址做连续读写测试从某个起始寄存器开始连续读N个字节统计耗时和错误数用逻辑分析仪抓取SCL/SDA波形测量SCL频率、高电平时间、低电平时间、上升沿/下降沿时间确认波形是否满足高速模式的时序要求保存扫描结果到Excel记录速率、设备列表、错误汇总。4.2 排查链路设备不响应、超时、速率上不去第一次在3.4MHz下跑扫描“全军覆没”——所有I2C地址都扫不到但切回400kHz一切正常。这个现象非常典型等于告诉排查人员两件事硬件接线没问题、DLL调用链没问题问题出在高速模式这件事本身。排查链路是这样的第一反应是怀疑MPSSE分频配错了。把逻辑分析仪放上去发现SCL实际频率只有几百kHz根本没到3.4MHz。问题定位到DLL里分频参数的计算方式整数分频取整方向不对3400kHz分频时算出来的实际值差了一大截。修正分频后SCL到了大约3.1MHz~3.3MHz但扫描还是不稳定偶尔能扫到、偶尔全灭。第二层怀疑是信号质量。示波器探头换成带宽更高的型号直接在适配器引脚附近测量发现上升沿比较平缓。原因是1kΩ上拉电阻在3.3V电源下对总线电容的充电速度不够快。把上拉电阻换成680Ω同时把测试线剪短缩短长度波形边沿明显改善。第三层怀疑是设备本身。这颗EEPROM的数据手册标称支持3.4MHz但实际测试发现它在高速模式下对时序的裕量并不大。重新读手册里Hs-mode的时序参数对照实测波形发现SCL高电平时间比手册要求的下限高不了多少加上MPSSE的时序抖动偶尔就会落到规格之外导致设备不ACK。这一步属于器件个体的实际表现只能通过降一点速率或者调整上拉来留出裕量。4.3 逻辑分析仪波形与数据对比最终稳定状态下逻辑分析仪抓出来的波形和400kHz模式有明显区别。3.4MHz下SCL频率约3.3MHz高电平约130ns低电平约170ns上升沿约30ns下降沿约20ns。虽然这个占空比不是标准的50/50但高速模式下主机驱动SCL的能力更强只要高低电平均满足手册的最小时间要求从机就能正常识别。数据对比也要做。同一台设备、同一个寄存器范围400kHz下连续读1000次没有任何错误平均一次读操作含I2C地址、寄存器地址、数据字节大约消耗不到1ms3.4MHz下同样1000次I2C总线上传数据本身快了不少但由于适配器和设备之间的时钟裕量不足偶尔会出现NACK或超时。这些错误不是每次都出现而是呈“概率性闪断”的状态这也说明了为什么速率测试不能只跑十几次就下结论至少要跑到几百上千次统计错误率才有参考价值。这里必须多说一句USB转I2C适配器这种方案测速率时得到的“总线速率”和“实际吞吐率”是两码事。逻辑分析仪看到SCL是3.3MHz那是总线时钟但Windows下USB调度、FTDI驱动缓冲、DLL调用开销都会影响实际完成一次读写的时间。如果你的项目想测的是“设备能在多快时间内完成一整个I2C事务”那么建议在DLL侧做精确计时而不要用Excel的Timer函数去测后者精度完全不够。5. 扫描数据的Excel化处理从原始记录到测试报告5.1 原始数据的整理逻辑Excel的价值在测试后端才真正体现出来。扫描完成后DLL把结果返回给VBAVBA按固定格式写入工作表。建议每个测试轮次占一个SheetSheet名带日期时间比如400k_20230115_1402、3400k_20230115_1410。每一行记录一个设备地址的扫描结果列结构大致是设备地址Hex格式便于和规格书对照ACK状态正常/失败/超时首寄存器读取值连续读N字节耗时循环次数内错误数备注用Hex格式显示I2C地址是很多新手容易忽略的细节。7位地址和8位读写地址混在一起容易看错我习惯在同一列里同时标注两种格式比如0x50 (8bit:0xA0)后面做产线报告或和FAE沟通时不容易产生歧义。5.2 速率统计口径实际吞吐率 vs 标称时钟报告的第二个核心内容是速率统计。这里要算两个数据一是标称时钟频率来源于逻辑分析仪量到的SCL频率代表总线本身的信号速率。二是实际传输速率用总数据字节数÷总耗时算出代表整个链路的吞吐率。这个值和标称时钟的比值会受到地址字节、寄存器地址字节、应答位、USB延迟等多方面影响通常在百分之几十到百分之八十之间浮动不要拿实际吞吐率和标称3.4MHz直接对比否则会觉得“怎么差了这么多”。生成统计表时Excel本身就是最合适的工具。用条件格式标出错误率超过0.1%的测试行用表格透视汇总不同速率档位下的平均耗时时长。标题上带_A后缀的那个测试工程当时最后生成的报告就是这样一页汇总表加若干明细页发给同事和客户一眼就能看出3.4MHz下哪些地址稳定、哪些地址有风险。5.3 报告生成与后续扩展到这一步整个“Excel驱动的I2C扫描3.4MHz速率测试”流程就跑通了。每次执行宏之后Excel自动保存快照相当于把整个测试过程的关键数据固化在表格里后续审计或者对比不同批次板子时有据可查。这个工具还可以做几处扩展一是把扫描到的设备地址自动去和配置文件里的期望地址表比对不一致时直接标红产线工人不用看细节只看颜色二是把DLL换成支持SPI或UART的版本同一套Excel骨架可以复用三是在DLL里加一段日志输出每次调用都记录时间戳和返回值排查问题时比Excel界面上的信息更可靠。做这类项目的个人体会是方案的关键不在于用了多高级的技术栈而在于把合适的工具按合理的边界切开。USB转I2C适配器啃下时序这层硬骨头DLL扛住性能和数据正确性Excel消化掉展示和记录的需求——每一层都做自己最擅长的事整体才会又稳又好用。如果直接拿Excel去操作底层适配器性能撑不住如果全用高级语言重写上位机非研发人员又用不起来。这个三层结构是这次测试工程里最值得沉淀的经验。