从事嵌入式开发的人基本都遇到过这种情况新拿到的板子上有一颗IIC设备死活不知道具体地址多少翻遍了数据手册也没写清楚最后只能对着datasheet里的表格一页页猜。或者更头疼的明明手册上写的是0xA0结果代码里用0xA0读写怎么都不通换成0x50反而正常。这种问题连老手偶尔都会翻车。所以我一直觉得掌握一个IIC自动寻址的方法也就是俗称的I2C scanner是嵌入式调试的必备技能。它的原理很简单实现也不复杂但在STM32F1这种老当益壮的平台上把它跑通、跑稳中间还是有一些值得说道的细节。这篇文章就把我自己的实现思路、踩过的坑、以及一些不太容易在标准文档里看到的经验一起整理出来希望能给正在被地址问题折腾的人一个参考。1. IIC寻址原理与硬件背景很多人写IIC代码用HAL库的函数一调收发数据都正常就默认自己懂了IIC。一旦涉及到设备地址就只知道照着例程抄。真到了要自己找地址的时候连从哪里下手都不知道。1.1 IIC地址到底是怎么构成的先说基础。IIC总线上每个从设备都有一个地址通信的时候主机发起起始信号之后要发送一个字节这个字节的高7位是从机地址最低位是读写标志位0表示写1表示读这正好凑够8位。举个例子最常见的OLED屏驱动芯片7位地址是0x3C那么在总线上实际发送的字节就是0x78写操作或者0x79读操作。很多国产模块的说明书上标的0x78其实就是包含读写位的8位地址而数据手册里写的0x3C才是纯粹的7位地址。这一点必须分清否则配置寄存器地址时填错事情就全乱了。STM32F1的I2C外设配置中寄存器里填的也是7位地址除非使能了10位地址模式。HAL库的I2C结构体里有I2C_Address_1这个字段官方注释说传入的是7位地址千万不要在这里填0xA0这种东西。另外IIC总线的地址空间是有限制的0x00到0x07以及0x78到0x7F这些区域是保留地址用于广播、10位寻址等特殊用途。真正能用于一般从设备的是0x08到0x77之间的大约104个地址。这个范围就是我们扫描器要遍历的空间。1.2 STM32F1的I2C外设特点STM32F1的硬件I2C模块在圈子里名声其实不太好很多人说它不稳定容易卡死在总线忙状态。实际上这个说法要分两面看。F1的I2C是一个比较老的外设事件处理流程确实繁琐如果操作不当会有问题。但正因为它老资料特别全用的人特别多各种避坑指南也特别成熟。用HAL库开发时F1的I2C主要是阻塞式调用。每次调用HAL_I2C_Master_Transmit它会自己处理起始条件、地址发送、数据移位、停止条件函数返回时这一轮通信就完成了。这种封装很适合我们做地址扫描因为我们的需求很简单往某个地址发起一次写请求看看有无应答有应答就记录没应答就跳过仅此而已。说到应答这是扫描的核心判断依据。IIC协议规定从设备收到正确地址后会在第9个时钟周期把SDA拉低作为应答信号ACK。主机如果没收到ACK就说明这个地址上没有任何设备在响应。我们扫描的逻辑说白了就是在每一个可能的地址上发起通信等待ACK有ACK就是找到了设备。2. 三种主流的I2C扫描实现方案扫描IIC设备地址网上能搜到很多版本的代码归根结底划分为三类直接操作寄存器、基于HAL库的封装、纯软件模拟时序。三种方案各有各的适用场景我都实际用过直接说结论。2.1 方案一直接操作寄存器这是我最早用的方式。F1标准外设库时代的做法直接操作I2C_CR1、I2C_DR这些寄存器用轮询方式检测EV5、EV6这些事件标志。当年很多人用标准外设库写出来的I2C代码都会自己在主循环里查事件的忙标志。优点就是代码体积小速度极快几乎不依赖库的额外逻辑而且能精确控制每一个时序细节。缺点也很明显工程量大可读性差稍有疏忽就容易出无头绪的时序问题对新人非常不友好。除非是那种对代码体积有极致要求的场景或者纯粹想练手否则我不太建议直接用寄存器点亮轮询方式。2.2 方案二基于HAL库的阻塞式发送这是我现在用得最多、也最推荐新手入门的方式。核心就是反复调用HAL_I2C_Master_Transmit这个函数把目标地址填进去他内部会帮助我们完成所有事务我们只需要关注返回结果。如果返回值是HAL_OK就说明设备给了ACK如果是HAL_ERROR就说明在超时时间内没有等到应答这个地址是空的。用这种方式写扫描器代码真的是又短又清晰uint8_t i; HAL_StatusTypeDef status; for (i 0x08; i 0x77; i) { status HAL_I2C_Master_Transmit(hi2c1, (uint16_t)(i 1), temp, 0, 10); if (status HAL_OK) { printf(Found device at 0x%02X (7-bit)\r\n, i); } HAL_Delay(2); }这里有个细节HAL_I2C_Master_Transmit的第二个参数是DevAddress官方要求传入的必须是8位格式即左移一位后的地址。所以上面代码里用i 1把7位地址换算成8位总线地址。很多人扫描不到东西就是直接传了7位地址进去由于HAL库内部只发送了7位地址总线上的地址不匹配自然没有任何应答。还有一点扫描的时候第二个参数Size发送数据长度填0是合法的操作。因为我们的目的是仅仅发出地址并不需要真的发送数据只要地址对了从机就会应答这个操作就被主机认为传输成功所以长度填0完全没有问题。2.3 方案三软件模拟I2C实现第三种方式是彻底放弃STM32的I2C外设用两个GPIO模拟时序。好处是不受硬件外设的种种脾气限制没有总线忙标志卡死的烦恼想怎么扫就怎么扫而且代码逻辑从bit级开始由自己掌控排查问题的时候非常直观。缺点是CPU占用率高代码体积较大速度也慢。但是在扫描这个场景里慢恰恰不是问题反正就是几十个地址慢慢扫就是了。软件模拟扫描的代码网上也有大量现成模板核心在于发起起始条件发送8位地址含写位然后释放SDA并释放时钟在读时钟周期内判断从机是否拉低SDA。一旦判断到了ACK信号就可以停止通信记录该地址。实际写程序时我通常是把软件模拟的I2C底层起始、停止、收发字节、应答判断封装好然后扫描逻辑就是简单的for循环。这类代码最大的优势是内聚度高换芯片平台只需要改GPIO底层扫描逻辑一层不变。这就是为什么很多老工程师至今调试IIC仍然优先选择软件模拟的原因。3. 完整代码实现与细节注释理论说了一堆还是直接上代码最实在。考虑到大多数人用的还是CubeMX生成的HAL库工程我就在这里给出一份完整的扫描实现可以直接嵌入工程里用。这段代码是用串口输出结果的如果不想用串口改成点亮LED或者存储到变量都可以。3.1 准备工作与CubeMX配置先说工程的初始化配置这个直接影响扫描能不能跑通需要认真对待。打开CubeMX选择自己的F1芯片型号将I2C1或者I2C2的模式设置为I2C也就是I2C外设启用。I2C速度模式默认是Standard Mode100kHz即可。F1的I2C可以跑到400kHz也就是Fast Mode但我们要扫描的是未知设备保守一点用100kHz最稳因为有些传感器最高只支持100kHz和不支持400kHz的快速模式。打开对应的GPIO配置如果使用默认的PB6和PB7作为I2C1的SCL和SDACubeMX会自动帮我们配置为开漏输出模式。别忘了配置一个串口比如USART1波特率设为115200用来打印扫描结果。关于波特率越高越好因为后面的printf格式化输出在低速串口下会成为瓶颈。时钟树可以默认即 72MHz主频这样I2C外设时钟也符合分频要求。pin脚方面F103系列默认I2C1就是PB6SCL和PB7SDA如果因为板子布局原因要换引脚CubeMX里也支持引脚复用。但有个很重要的经验F1的I2C引脚建议直接使用默认复用引脚尽量不要随便换到其他GPIO上去用因为F1芯片上支持I2C复用的引脚是有限的不像软件模拟那么随意。我曾经在一颗特定的F103板子上尝试把I2C复用映射到其他引脚折腾了一上午事件标志就是不正常。最后老老实实换回PB6和PB7。3.2 main函数中的地址扫描代码CubeMX生成初始工程后在main函数的while循环之前加入如下代码即可实现一次完整的扫描#include stdio.h #include string.h void i2c_scan(void) { uint8_t temp 0x00; uint8_t index 0; printf(I2C Bus Scan Start...\r\n); // 0x08 ~ 0x77 是标准7位地址可用范围 // 不扫0x00~0x07是因为这是保留地址广播地址等 // 不扫0x78~0x7F是因为这是10位地址模式保留段 for (index 0x08; index 0x77; index) { // 左移一位转换成8位总线地址含写位 HAL_StatusTypeDef ret HAL_I2C_Master_Transmit(hi2c1, (uint16_t)(index 1), temp, 0, 10); if (ret HAL_OK) { printf(Found device at 7-bit address: 0x%02X\r\n, index); } HAL_Delay(2); } printf(I2C Bus Scan Finished.\r\n); }上面这段代码的工作过程也很好了解对于每一个可能地址它都会向总线发出一次一个字节的写请求长度为0。如果从机应答它就输出如果主机没收到应答会在超时时间内返回非OK状态继续下一个地址。运行这段代码后测得的全部有效地址会依次打印出来。超时时间参数我填的是10毫秒。对这个扫描任务来说10ms是相当充裕的因为一个周期的ACK判断在100kHz下也就几十微秒稍长的时间。如果板子走线有问题导致NACK响应变慢超时时间还可以适当放大但不建议太大否则扫描一轮要好几秒钟太拖沓。3.3 双地址识别与优化很多IIC设备不止有一个地址常见的是通过硬件引脚电平来配置低地址位。比如EEPROM设备地址引脚A0、A1、A2决定低三位地址所以同一型号的EEPROM在一根总线上可以挂接8片各自的地址都不同。扫描结果如果出现了多个地址要仔细判断是多个设备还是同一个设备因为引脚配置不同导致的可变地址范围。这时候推荐把扫描地址和扫描到的器件物理位置对应起来用排除法判断。另外还有一个经验性优化大多数IIC设备的人群是集中在0x30~0x70区间的而0x08~0x2F这个区间虽然存在但碰到的概率偏低。如果只想快速定位常见传感器可以优先扫描0x30~0x77。但如果要做严格的地址普查就不应该跳过任何地址老老实实全扫。我的工程里还会加一个可选的readback验证当扫描到地址后直接再发出一个读命令如果能正确读到至少一个字节说明这个地址确实有效而不只是偶然被拉低应答。虽然IIC从机如果地址匹配必然应答有人会送一个应答信号但做一次读验证确实能把不存在的伪地址过滤掉不少尤其在一些引线较长、干扰较大的板子上很有用。3.4 基于逻辑分析仪的验证代码写的再信心满满接线和硬件上的问题也总是会突然出现。我在调这类工程时习惯把逻辑分析仪挂到SCL和SDA上看扫描时的实际波形。这个习惯能帮我快速确认三件事起始条件是否正常输出、地址字节是否发送正确、从机应答位是低还是高。稍微提一下便宜的8通道逻辑分析仪配上开源上位机软件就够用了不需要很高端的东西。解出来的波形中每个地址扫描周期会形成一个完整的起始-地址-停止序列观察从机响应的地方就能清楚设备确实存在于总线上。逻辑分析仪可以说是调试IIC总线最重要的工具没有之一。4. 实操过程中的典型问题与排查真的在项目里跑扫描器会遇到各种各样的问题。有些问题与代码无关也有些问题隐隐约约跟代码有关看完下面的经验说不定能帮你省好几个小时。4.1 扫描不到任何设备这是最常见的情况。代码跑了一遍打印出来的结果是“Scan Finished”从头到尾没有任何设备地址。可能的原因有好几种按出现频率排序一是I2C引脚配置错误。CubeMX如果没把GPIO配置为开漏输出而是配置成了推挽输出IIC总线就工作不正常。开漏输出是IIC总线的硬件基础要求因为有外部上拉电阻将线路拉高设备通过开漏输出拉低来实现通信。用推挽的话主机主动输出高电平的同时如果从机也在输出低电平就会引发针脚电流异常。在CubeMX的GPIO设置中务必要确认GPIO模式是开漏Open Drain并且没有额外开启内部上拉。这里补充一点开漏模式下STM32内部的上拉电阻其实是可以在外部上拉不足时提供补救的但标准I2C要求外部上拉内部的上拉阻值其实偏大且不稳定为调试省心最好还是外接4.7k上拉电阻。二是外部上拉电阻缺失。STM32F1的I2C引脚内部上拉并不是在所有型号上都默认启用的如果板子上没有外部上拉电阻SCL和SDA会因为缺少驱动上拉不足导致通信异常。这个问题在开发板上较少见但自制板卡上很容易翻车。三是地址发送格式错误。这个前面提过了往HAL_I2C_Master_Transmit的DevAddress参数里传7位地址导致不匹配。在扫描程序里17位地址必须左移一位再传。不少人是用网上抄来的旧代码里面可能直接传了7位地址在别的平台行得通在STM32的HAL库里就死翘翘了。四是从设备地址本身就是保留地址。如果某个设备把地址引脚配置成了0x00扫描范围是从0x08开始自然扫不到它。排查的方式先用逻辑分析仪看波形。如果波形完全干净连起始条件都没有肯定是代码调用层面的问题如果有波形但没有任何ACK重点检查上拉电阻和从机供电如果部分地址有波形部分地址没有就要检查地址发送格式。4.2 扫描结果地址与实际不符有时候扫描到了设备但报出来的地址和datasheet上对不上号。这种情况多半又是7位地址和8位地址的锅毕竟不同的厂家、不同的模块商家习惯不一样就成了这样。另外有些模块在硬件上集成了多个器件比如把OLED和温度传感器都接在同一根总线上扫描时会显示多个地址需要对照原理图确认。说实话这个问题我在初学阶段碰过不止一次。明明SSD1306的手册写着0x7A含写位我在I2C_InitStructure里填了0x7A结果显示0x3D7位。后来我对自己的地址换算规则做了彻底梳理凡是datasheet或模块标记上带有A0~A2、SA0这种地址引脚说明的默认它给的是7位地址的基础值应该左移后再用。凡是商家模块标记的十六进制地址一定要区分它是否已经包含读写位。列个常见的地址对应表器件类型7位地址8位写地址备注OLEDSSD13060x3C0x78很多模块默认EEPROMAT24C020x500xA0A0/A1/A2可改六轴传感器MPU60500x680xD0AD0引脚可改气压计BMP2800x760xEC部分模块为0x77RTCDS32310x680xD0固定地址如果你扫出来的地址和表里不一样先别急着怀疑扫描器去检查模块上的地址跳线或引脚电平很可能只是配置不同而已。4.3 扫描过程卡死或总线死锁用HAL库的阻塞方式偶尔会出现程序卡在HAL_I2C_Master_Transmit里不返回的现象。这是HAL库内部一直在等待总线事件完成结果总线因为某种异常被锁死了SCL处于高电平SDA被某个设备拉低这时主机再发起起始条件就永远等不到总线的空闲状态。可能的原因之一是I2C总线被设备意外拉低而主机不知情比如在运行过程中从机复位了而总线状态混乱。另一个典型情况是高速通信时从机没有正确处理快速模式下的时序把总线锁住了。解决总线死锁有几种常规办法最简单的是在扫描前让总线复位一次。软件模拟I2C可以用GPIO把SCL翻转9次来释放被锁死的总线硬件I2C的话重新初始化I2C外设也是一种方式但往往治标不治本。还有一个很有效的办法是给HAL的调用加上更多重试机制比如发现超时后立即调用HAL_I2C_DeInit与重新初始化把外设彻底复位再扫描下一个地址。更彻底的角度是从硬件上保证稳定性。我自己的项目里I2C外部上拉电阻通常选择4.7k如果总线上的设备数量较多会考虑降为2.2k保障驱动能力。总线长度也是不可忽视的因素哪怕是一根杜邦线超过20cm都很容易在快速模式下出问题所以扫描模式建议一路固定100kHz。4.4 总线上挂多个同类型设备时的冲突识别有时候调试的板子挂了好几片EEPROM或者好几片温度传感器它们都支持地址引脚配置。扫描出来如果有多个地址看起来是“全部找到了”实际有可能意味着引脚配置出现短路或者悬空导致多个设备映射了同一个地址。这种情况最典型的现象是扫描出来少数几个地址但实际板子上挂了8个相同型号的设备。排查方法很简单依次改变某一片的地址引脚电平再看扫描结果是否跟着变化。如果改了一片扫描结果中立刻多出来一个地址或少了一个地址说明地址引脚连接到片选逻辑起效了如果怎么改都只有一个地址大概率是引脚配置没被正确读取。另外如果多个设备共享同一个地址它们在扫描时都会同时应答主机收到的实际上是多个从机的叠加信号数据大概率是乱的。遇到这种情况扫描结果可能会显示“有一个设备在地址0x50”但它可能一片都不能正常工作。这大概率是硬件地址冲突这个时候即使扫描器再聪明也无法自动排解只能人工调整引脚。4.5 一个好用的增强自动重复检测与汇总输出基础的扫描是一次性的但实际项目里我更习惯把它做成循环扫描每2秒自动扫一次总线打印当前存在的设备表。这样做有几个用处一是验证热插拔设备能否被正确识别二是在设备上电初始化时间不一致时也能捕捉到晚到的设备地址三是长时间运行可以用来监控总线设备的稳定状态如果某个设备偶发掉线扫描输出会直接暴露出来。实现上非常简单在while(1)循环里反复调i2c_scan()然后加个延时。如果要更精细一点可以把上一次扫描结果保存下来每次对比差异并打印变化这样监控效果更好。while (1) { i2c_scan(); printf( re-scan in 2 seconds \r\n); HAL_Delay(2000); }这种轮询监控模式在实际项目中偶尔会在工装上也用到产线测试时用同样的扫描逻辑配合夹具快速判断哪些IIC模块装配上去了哪些漏装或者错料。5. 嵌入式场景下的地址避坑指南把扫描器跑通只是第一步在整个项目开发周期里和设备地址相关的坑远比想象中多得多。我根据自己的实际项目经验把这些坑整理成几条规则照着做能省很多事。5.1 不要盲目信任模块标记地址市面上大量传感器模块并不是直接把芯片引脚引出而是中间加了一级LDO、电平转换甚至逻辑门。有些商家为了统一硬件会在板上硬拉或硬接地一些地址引脚导致模块标签纸上的地址与芯片原始地址不符。比如某款气压传感器模块芯片原始地址是0x76但模块设计者把SDO引脚接地地址变成了0x77标签上却还是写着0x76。这种错误在开源硬件圈特别常见。所以拿到任何模块的第一件事不是看标签而是查找对应芯片的数据手册看地址引脚的电平配置逻辑再去量板子上相关引脚的电压。养成这个习惯以后会少踩很多坑。5.2 I2C地址冲突的软件层面补救如果说两个芯片的地址确实冲突了硬件引脚也都已经固定无法更改软件上不是完全没有办法。有些芯片支持通过软件配置寄存器来改变应答地址虽然这种情况不多见但我在少部分传感器上确实碰到过。比如某些触摸芯片可以通过配置寄存器切换通信地址。多数情况下地址冲突最有效的解决办法是硬件隔离使用I2C多路复用器比如TCA9548A这类芯片把总线的不同分支物理隔离分别使能不同分支来访问不同地址的设备。这种情况下扫描器的角色就变成对分支进行扫描逐个分支确认设备是否存在。这类芯片在大型项目中极其常用值得了解一二。如果不能用复用器还有一个更朴素的思路把两个地址冲突的设备错开使用时间段用I2C总线的特性——在需要访问设备A时关闭设备B的供电或者在设备B的SDA线上加一个模拟开关进行隔离。这种方案虽然土但在成本敏感的项目里屡试不爽。5.3 总线电平与电源域匹配多设备IIC总线上经常存在不同供电电压的芯片混搭。比如主控是3.3V某个从设备是5V供电它的IIC引脚输出高电平可能是5V。这种情况下若直接相连轻则信号识别异常重则烧坏主控引脚。扫描器跑在这种总线上有时也能发现“幽灵地址”某些并非真实存在的地址却时而出现应答。这种诡异现象多半是电平不匹配导致SDA线上的电压阈值处于临界状态从机误判了起始条件。遇到这种情况建议不要急着改代码先用万用表量一下总线上的高电平电压和低电平电压再考虑是否要加电平转换芯片。我在自制的小板子上曾经吃过亏一个3.3V主控和一片5V的EEPROM直连扫描到了许多奇怪的地址换电平转换后一切恢复正常。从此以后凡是有多个电源域的设备挂同一根IIC总线我必定先处理电平匹配的问题再看软件。5.4 关于上拉电阻的选取一个总线上挂了多个设备并联的输入电容会变大上拉电阻如果太大信号上升沿就会变缓导致100kHz下都无法正常应答。我常用的经验值是总线电容推荐上拉电阻100kHz推荐上拉电阻400kHz小 100pF4.7kΩ2.2kΩ中100~300pF2.2kΩ1kΩ大 300pF1kΩ680Ω需要说明的是这只是一个参考基准实际阻值还要结合从机驱动能力和电源电压来微调。电阻太小总线低电平时灌入电流大可能超出从机的吸收能力电阻太大上升沿太慢时序不过关。这也是为什么扫描器跑不通的时候我第一件事往往是拿示波器看SCL的上升沿是否圆润。对于很多人忽略的这步反而往往是所有问题的症结。6. 把扫描器扩展成通用调试工具扫描器本身只是一个很短小的函数但把它思路延伸一下其实可以做成一个非常顺手的IIC调试小工具箱。我在自己的工程里会放几个常用的扩展函数都是基于同样的HAL库非常实用。6.1 寄存器读取快照扫描到设备地址后紧接着想知道这个设备是什么一个粗暴但有效的方法就是把它的寄存器全部读出来打印成快照。IIC设备内部寄存器往往有非常明确的特征比如芯片ID寄存器、厂商ID寄存器读出来后一查手册就知道是什么芯片。实现方式就是利用HAL_I2C_Mem_Read函数在扫描到地址后循环读取0x00到0x7F范围内的寄存器。很多设备寄存器地址是从0x00开始的以256字节为界。这么做一次快照相当于把设备的“指纹”记录了下来对于逆向分析和排查板子问题非常有帮助。6.2 读写压力测试自制设备时总线稳定性是最让人担心的。写一个简单的压力测试函数反复对某个从设备的寄存器进行写入再读回比较统计错误次数这样能在极短时间内发现总线时序问题或上拉不足问题。配合扫描器的轮询模式还可以把压测数据和设备掉线数据一起记录到缓冲区方便事后回放和分析。很多人觉得扫描器就是扫个地址这么简单但把它改造成压力测试器以后它几乎算得上一个简易的IIC总线健康度检测工具了。6.3 配合FreeRTOS多任务时的注意事项有些项目上了FreeRTOSIIC扫描可能放在一个独立任务里。此时要注意HAL库的阻塞式调用会占用CPU时间在扫描过程中其他任务可能被延后。另外如果多个任务同时调用HAL_I2C_Master_Transmit一定要注意用互斥锁或信号量保护I2C外设否则一旦发生并发访问总线上会出现交错传输轻则数据错误重则总线死锁。我一般会在IIC任务里把扫描函数放到临界区或者给I2C外设加一个互斥量。如果任务比较紧急的扫描不需要很频繁也可以把扫描频率放慢到5秒一次对实时性的冲击就非常小了。7. 一个偏门的经验把扫描结果写进Flash作为产品自检依据扫描器不仅能用于开发调试在量产阶段也能发光发热。有些产品在出厂前需要进行通讯自检利用扫描器扫描总线上存在的器件地址与预期清单做比对可以判断是否有漏焊、错焊、贴反等问题。这一步对量产质量的提升帮助极大。具体做法是在产线测试固件中存储一份预期的设备地址表上电后执行一次扫描将实际扫描到的设备列表与预期的进行对比。不一致就通过提示灯、蜂鸣器或者串口报错。这样一个简单的自检流程能省掉很多人工目检的成本比起用示波器去逐个量引脚高效得多。这块逻辑也可以放到应用程序里上电后做一个地址扫描存入Flash上位机通过串口读取自检结果追溯每块板子的通讯健康状态。哪怕产品已经交付也可以通过远程指令重新扫描一次快速判断现场问题出自哪个设备。把这些经验串起来扫描器表面上只是几十行代码实际上是IIC调试中最高收益的小工具。它既能帮你扫地址还能帮你验证总线稳定性、识别硬件错误、辅助产线自检。无论你是刚接触STM32的新手还是多年开发的老师傅手边常备一个IIC scanner在很多悬案一样的通讯问题面前至少能帮你把排除范围瞬间缩小一大半。