简介STM32F4的I2C通信例程包面向嵌入式开发初学者与需要快速实现I2C读写EEPROM的工程师。例程演示了通过I2C1接口向24LC02 EEPROM写入256字节数据、再读出并经RS232发送验证的完整流程代码结构清晰函数封装到位便于移植和二次开发。资源包共1028个文件核心代码以C源文件.c和头文件.h为主包含完整的I2C、GPIO、USART驱动模块及标准外设库同时带有工程配置文件.uvproj、.uvopt、编译产物.axf、.hex和芯片说明文档另有大量HTML、JS、PNG文件提供图形化参考整体大小约6.92MB。已有2461人学习下载适合用于理解STM32F4的I2C协议、寄存器操作及EEPROM读写时序也可作为实际项目的底层驱动模板。 做STM32F4开发I2C可能是你第一个感到头疼的外设。我也一样当年在F407上调一个EEPROM例程整整花了两天最后发现是上拉电阻没焊。后来接触了大量基于STM32F4的I2C项目从温湿度传感器、OLED屏到AT24C02掉电保存踩过的坑不计其数。这篇文章我尽量把例程背后的原理、常见的坑和排查链路一次讲清楚适合准备调I2C的朋友也适合那种例程明明下载了、编译了、烧录了但设备就是没反应的人。注意我接下来讲的不是简单的CtrlC、CtrlV式例程展示而是从协议底子、选型逻辑、代码实现到调试方法的一条完整链路。把这条链路捋顺了你以后遇到任何I2C设备——不管它是EEPROM、加速度计还是触摸芯片——都能自己写出能跑的例程。1. I2C协议的几个关键概念从地址到时序1.1 7位地址和8位地址的坑I2C通信规则里每个从设备都有一个地址。但很多人第一次用HAL库写I2C例程时会被地址格式绕晕。AT24C02这个最经典的EEPROM它的设备地址是1010开头加上硬件引脚A0、A1、A2的电平最后补一位读写标志位。当A0/A1/A2全部接地时写地址是0xA0读地址是0xA1。这里有个关键区别I2C协议规范里地址本身是7位的但实际传输时从机地址是以8位形式出现在总线上的最后一位用来表示读还是写。所以你在HAL库的HAL_I2C_Master_Transmit函数里传的DevAddress参数要传0xA0这种8位格式而不是什么0x50。很多新手把7位地址和8位地址混着传结果一直返回超时错误。1.2 起始条件、停止条件和应答位I2C总线上有两个电平信号时钟线SCL和数据线SDA。总线空闲时两线都被上拉电阻拉到高电平。起始条件就是SCL保持高电平期间SDA从高变低停止条件则是SCL高电平期间SDA从低变高。这里有一个非常实用的理解方式SDA这根线只允许在SCL为低电平的时候跳变SCL一旦变成高电平SDA必须保持稳定。这个规则保证了数据传输的时序不会错乱也是你后面用示波器或逻辑分析仪看波形时判断通信是否正常的依据。另外I2C总线上每次传输8位数据后从设备会回一个应答位ACK。从设备正常接收到数据会把SDA拉低如果从设备忙或者地址不匹配SDA保持高电平主机收到的是NACK。这些细节在调试I2C时非常重要因为总线卡死、通信失败很多时候就出在应答环节上。1.3 数据有效性和时钟频率I2C协议对数据有效性有明确要求SDA上的数据必须在SCL的高电平周期内保持稳定数据只能在SCL低电平期间改变。这也是为什么很多I2C例程里发送一个字节要循环8次——每次发送一位先准备好数据位再拉高SCL然后拉低SCL准备下一位。时钟频率方面标准模式是100kbps快速模式是400kbpsSTM32F4的硬件I2C甚至支持1Mbps的快速模式。但实际项目中除非你用的是短距离、低负载的总线否则我建议老老实实用100kbps。总线频率越高对上拉电阻、走线寄生电容的要求越苛刻一根10厘米的飞线就可能让400kbps模式下的通信变得不稳定。2. 硬件I2C与模拟I2C为什么不少老手选择后者2.1 STM32硬件I2C外设的历史包袱在STM32开发圈里流传着一句话STM32的硬件I2C有bug。这个说法其实有点历史了。早期标准外设库时代的硬件I2C确实存在总线锁死、状态寄存器异常等问题让不少工程师吃了亏。到了HAL库时代ST官方把这个问题修了不少但并不能说完全消失。我自己在F4上用硬件I2C碰到过一种情况系统运行一段时间后HAL_I2C_Master_Transmit一直返回超时但只要复位一下又能正常跑一段时间。排查到最后发现是总线上出现了某种异常时序导致从设备进入了错误状态而硬件外设没有自动恢复机制。相比之下软件模拟I2C遇到这种情况时你可以随时重置时序把总线掰回来。2.2 模拟I2C用GPIO手工敲时序模拟I2C的思路很简单把SCL和SDA配成开漏输出然后用GPIO的置高置低操作一句一句地把起始条件、数据字节、停止条件敲出来。核心代码大概长这样void I2C_Start(void) { SDA_HIGH(); SCL_HIGH(); delay_us(5); SDA_LOW(); delay_us(5); SCL_LOW(); } void I2C_Stop(void) { SCL_LOW(); SDA_LOW(); SCL_HIGH(); delay_us(5); SDA_HIGH(); delay_us(5); }模拟I2C最大的优势是可控性极强。总线异常时你可以逐个GPIO翻转观察是哪一步出了问题也可以随时插入延时兼容那些时序要求很奇怪的从设备。缺点是占用CPU资源速度有限——但I2C本身就不适合传大数据传感器读几个字节、屏显刷一帧几十字节模拟模式完全够用。2.3 项目里到底该用哪个一个实用判断准则我的习惯是这么判断的如果项目里只有一两个I2C从设备而且数据量不大比如温湿度传感器、EEPROM直接上模拟I2C调试省心代码也好移植。如果总线上挂了多个设备或者需要持续高速读写比如频繁刷大尺寸OLED就用硬件I2C但要留好总线超时检测和错误恢复逻辑。最实用的建议是先跑通一个基于模拟I2C的例程把协议吃透然后再切到硬件I2C。这样即使硬件I2C出了问题你也知道底层时序应该是什么样排查起来心里有底。3. 一个可运行的HAL库例程读写AT24C02全程拆解3.1 硬件连接别小看这两根线以STM32F407和AT24C02为例I2C1的默认引脚是PB6SCL和PB7SDA。AT24C02的A0、A1、A2都接地WP写保护引脚直接接地VCC接3.3V。关键在于SCL和SDA上必须接上拉电阻。上拉电阻的阻值选择是有讲究的。3.3V系统、总线设备不多、走线短4.7kΩ是万金油选择如果总线速率跑到400kHz或者总线上挂了多个从设备建议换成2.2kΩ保证上升沿足够陡峭。10kΩ也可以用但上升沿会偏慢高速模式下容易出问题。具体选多大最好用示波器看波形后再定。3.2 引脚与CubeMX配置用CubeMX配置F407的I2C1时打开I2C1外设Pinout视图会自动把PB6/PB7配置为I2C1的SCL/SDA。参数设置里Clock Speed填100000Duty Cycle选I2C_DUTYCYCLE_2Addressing Mode选7位地址模式。生成的初始化代码大致如下static void MX_I2C1_Init(void) { hi2c1.Instance I2C1; hi2c1.Init.ClockSpeed 100000; hi2c1.Init.DutyCycle I2C_DUTYCYCLE_2; hi2c1.Init.OwnAddress1 0; hi2c1.Init.AddressingMode I2C_ADDRESSINGMODE_7BIT; hi2c1.Init.DualAddressMode I2C_DUALADDRESS_DISABLE; hi2c1.Init.GeneralCallMode I2C_GENERALCALL_DISABLE; hi2c1.Init.NoStretchMode I2C_NOSTRETCH_DISABLE; if (HAL_I2C_Init(hi2c1) ! HAL_OK) { Error_Handler(); } }这里的OwnAddress1是主机自己的地址因为F4作为主机不需要被寻址填0就行。3.3 写数据地址格式与写周期等待向AT24C02写一个字节流程是先发设备写地址0xA0再发目标存储地址最后发数据。HAL库的写法如下uint8_t buf[2]; buf[0] 0x00; // EEPROM内部存储地址 buf[1] 0xA5; // 要写入的数据 if (HAL_I2C_Master_Transmit(hi2c1, 0xA0, buf, 2, 100) ! HAL_OK) { // 超时或者NACK就在这里体现 } HAL_Delay(5); // 等待EEPROM内部写周期完成注意最后的HAL_Delay(5)。AT24C02每写完一个字节内部需要大概5ms的写周期来把数据真正烧录进存储单元。在这期间EEPROM不会响应任何I2C请求。如果不等待就立刻读大概率读到的是旧数据或者直接NACK。3.4 读数据随机读的完整流程读EEPROM比写稍微绕一点因为需要先告诉从设备你想读哪个地址。正确顺序是先发设备写地址发存储地址发停止条件然后重新发起起始条件发设备读地址0xA1最后接收数据。uint8_t addr 0x00; uint8_t data 0; HAL_I2C_Master_Transmit(hi2c1, 0xA0, addr, 1, 100); HAL_I2C_Master_Receive(hi2c1, 0xA1, data, 1, 100);有些芯片设计得比较聪明不需要中间的这个停止条件但AT24C02的随机读必须走这个流程。如果你在别的例程里看到多了一行HAL_I2C_Master_Transmit不要觉得多余那是在设置读指针。3.5 自测函数让例程自己证明自己写完读写函数后建议加一个自测逻辑往某个地址写入一个已知值读回来比对是否一致。如果一致点亮LED或者串口打印PASS不一致打印错误地址和期望值。这个自测函数看着不起眼但能帮你快速区分是通信链路问题还是业务逻辑问题。我的实际经验是像下面这种回环测试在I2C例程里几乎是必需品uint8_t test_addr 0x10; uint8_t write_val 0x5A; uint8_t read_val 0; EEPROM_WriteByte(test_addr, write_val); HAL_Delay(10); read_val EEPROM_ReadByte(test_addr); if (read_val write_val) { printf(I2C EEPROM test PASS\r\n); } else { printf(FAIL: addr0x%02X, expect0x%02X, got0x%02X\r\n, test_addr, write_val, read_val); }4. I2C调试的常见坑与完整排查链路4.1 排查第一步从硬件电平开始I2C调试最忌讳一上来就翻代码。我的排查顺序永远是先硬件后软件。上电后先用万用表量SCL和SDA的对地电压——正常情况下总线空闲时两线都应该是高电平3.3V或者VCC。如果量出来是0V先查上拉电阻有没有焊错、虚焊再查从设备是不是把总线拉死了。还有一种情况也常见从设备的VCC没供上SDA被从设备内部钳位到低电平。这时候换一个外接电源或者检查电源电路问题立刻消失。别问我为什么知道我在这上面浪费过整整一个下午。4.2 地址扫描5分钟确认设备是否在线确定硬件没问题后下一步不是急着读数据而是先确认设备地址对不对。写一个地址扫描循环让MCU遍历所有可能的7位地址看哪个地址能收到ACKfor (uint16_t addr 0; addr 128; addr) { if (HAL_I2C_IsDeviceReady(hi2c1, addr 1, 1, 10) HAL_OK) { printf(Device found at 0x%02X\r\n, addr); } }这段代码在实际调试中太有用了。它能直接验证MCU和从设备之间的物理链路是否通、从设备地址到底是几、上拉电阻是否有效。如果扫描结果一片空白说明问题在硬件或者初始化环节如果能扫到设备但读写还是失败问题就缩小到了具体的读写时序。4.3 总线锁死最吓人也是最常见的问题I2C总线锁死的现象是SCL和SDA中有一根被拉低总线永远无法空闲所有通信全部超时。最常见的原因是通信过程中主机在中途异常停止——比如代码跑飞、看门狗复位——而此时从设备正在往总线上发送数据SDA被从设备拉住主机这边却再也没有发时钟让从设备吐完剩余位。解决方法是给总线来一次复位用GPIO把SCL翻转9个周期等效于发送9个时钟脉冲让从设备释放SDA然后再发送一个停止条件。这个操作可以用模拟I2C的方式实现也可以直接操作GPIO寄存器。代码不复杂但要在死锁发生前把GPIO模式切到开漏输出否则硬件I2C外设占用引脚时会冲突。更根本的解决办法是在代码里加总线错误检测。每次I2C操作前先检查总线上是否空闲如果发现SDA一直被拉低就自动执行上面说的复位流程。这样至少能保证系统不会因为一次I2C异常直接挂死。4.4 工程环境Keil5怎么识别STM32F4这个坑虽然和I2C本身无关但几乎每个用Keil5做STM32F4开发的人都遇到过打开例程后编译Keil提示找不到stm32f4xx.h或者Device选择列表里根本没有STM32F407VE。原因是Keil5和Keil4不一样MDK5的设备支持包Device Family Pack需要单独安装。在Keil5里正确添加STM32F4设备支持的操作是打开Pack Installer找到STMicroelectronics目录下的STM32F4 Series设备包点击Install。装完后Device列表里就会出现STM32F405/F407等型号。如果例程是从别人那拷贝的还需要注意芯片型号要和工程配置一致——比如F407VE和F407VG的Flash大小不同选错型号会导致烧录和调试异常。这个小问题足以让一个新手卡住半天。最后说一个我个人的调试习惯拿到任何I2C例程不要急着改业务逻辑先把地址扫描跑通再写一个单字节读写自测确认链路没问题后再上真正的功能代码。这个流程看起来多花了几分钟实际上能帮你省下数不清的排查时间。I2C这个东西绝大多数问题都出在硬件连接和基础时序上把地基打牢了上层应用怎么搭都稳。本文还有配套的精品资源点击获取