1. I2C协议基础与STM32实战意义

大家好，我是超哥，在嵌入式行业摸爬滚打十多年了。今天咱们来聊聊STM32的I2C通信，特别是如何用GPIO模拟I2C驱动24C02 EEPROM。我刚开始接触I2C的时候，也被那些时序图搞得头晕，但后来发现只要理解了核心机制，其实并不难。

I2C是一种双线制串行通信协议，只需要两根线：SDA（数据线）和SCL（时钟线）。这种设计特别适合板内器件之间的短距离通信，比如传感器、EEPROM等。为什么我们要用软件模拟I2C呢？原因很简单：硬件I2C虽然方便，但有时候会遇到兼容性问题，特别是不同型号的STM32芯片。软件模拟则更加灵活，不受硬件限制，而且调试起来更直观。

我记得第一次用硬件I2C驱动24C02时，遇到了各种奇怪的问题，后来改用软件模拟，反而一举成功。这就是为什么我推荐初学者先从软件模拟入手，彻底理解I2C的底层机制。

2. I2C通信协议核心机制详解

2.1 物理层连接规范

I2C总线的物理连接有几个关键点需要注意。首先是上拉电阻，通常选择4.7kΩ，这个值不是随便选的。我曾经试过用10kΩ的上拉电阻，结果通信距离稍长就出现数据错误。后来换成4.7kΩ，问题就解决了。为什么呢？因为上拉电阻的大小决定了信号上升时间，电阻太大会导致上升沿太缓，容易产生时序问题。

拓扑结构也很重要。I2C要求链式连接，绝对不能使用环形或星形连接。有一次我在一个项目中犯了低级错误，采用了星形连接，结果信号质量极差。后来发现是因为星形连接会产生信号反射和阻抗不匹配，导致波形畸变。正确的做法是所有设备都挂在同一条总线上，等距、等宽、等长布线。

2.2 协议层关键信号

起始信号和停止信号是I2C通信的"开场白"和"结束语"。起始信号是在SCL高电平期间，SDA从高到低的跳变；停止信号则是在SCL高电平期间，SDA从低到高的跳变。这里有个细节：这些信号都是电平跳变，而不是静态电平。

应答机制是I2C的精髓所在。每传输一个字节，接收方都需要发送一个ACK信号。我在调试时经常用这个机制来判断通信是否正常。如果某个设备没有返回ACK，通常意味着地址错误或者设备不存在。

数据有效性规则也很重要：只有在SCL低电平时，SDA才能变化；SCL高电平时，SDA必须保持稳定。这个规则保证了数据采样的准确性。我曾经遇到过因为毛刺导致的数据错误，后来增加了适当的延时就解决了。

3. 软件模拟I2C驱动实现

3.1 GPIO初始化配置

软件模拟I2C的第一步是配置GPIO。这里有个关键点：SDA线需要双向操作，所以我们要能够动态切换输入输出模式。在STM32中，我们可以通过修改GPIO的CRL或CRH寄存器来实现。

// GPIO初始化代码
void IIC_Init(void)
{
    GPIO_InitTypeDef GPIO_InitStructure;
    
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE);
    
    // SCL线配置为开漏输出
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_6;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_OD;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_Init(GPIOB, &GPIO_InitStructure);
    
    // SDA线同样配置
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_7;
    GPIO_Init(GPIOB, &GPIO_InitStructure);
    
    // 初始状态拉高
    IIC_SCL = 1;
    IIC_SDA = 1;
}

开漏输出模式很重要，这样可以实现线与功能，多个设备可以共享总线。我记得有一次用了推挽输出，结果设备之间互相"打架"，总线电平乱跳。

3.2 起始与停止信号生成

起始和停止信号的实现要严格遵循时序要求。这里分享一个技巧：在产生起始信号前，先确保SDA和SCL都是高电平，这样可以避免意外的起始信号。

// 起始信号生成
void IIC_Start(void)
{
    SDA_OUT();
    IIC_SDA = 1;
    IIC_SCL = 1;
    delay_us(4);        // 保持时间
    IIC_SDA = 0;        // 起始信号：SCL高时SDA从高变低
    delay_us(4);
    IIC_SCL = 0;        // 钳住总线，准备数据传输
}

停止信号也是类似的原理，但是顺序相反。在实际应用中，我建议在每个信号之间加入适当的延时，特别是对于不同速度的设备。我曾经因为延时不足导致24C02无法识别停止信号。

4. 24C02 EEPROM读写实战

4.1 器件寻址与操作码

24C02的器件地址是0xA0（写操作）或0xA1（读操作）。这里有个容易混淆的点：24C02的地址引脚A0-A2可以用于设置从机地址，允许同时连接多个EEPROM。

写操作时序包括：起始信号、器件地址（写）、应答、存储地址、应答、数据、应答、停止信号。读操作稍复杂一些，需要先发送写操作来设置地址指针，然后再发起读操作。

我在实际项目中遇到过地址对齐的问题。24C02的存储地址是8位的，但有些更大的EEPROM需要16位地址。这时候就要注意发送地址的顺序（先高字节后低字节）。

4.2 单字节与多字节读写

单字节读写相对简单，多字节读写需要注意地址自动递增的特性。24C02支持页写操作，一页通常是16字节。如果写入数据跨越页边界，需要特别处理，否则会从页开头覆盖。

// 单字节写入函数
void AT24CXX_WriteOneByte(u16 WriteAddr, u8 DataToWrite)
{
    IIC_Start();
    
    if(EE_TYPE > AT24C16) {
        IIC_Send_Byte(0xA0);
        IIC_Wait_Ack();
        IIC_Send_Byte(WriteAddr >> 8);    // 发送高地址
    } else {
        IIC_Send_Byte(0xA0 + ((WriteAddr/256) << 1));
    }
    
    IIC_Wait_Ack();
    IIC_Send_Byte(WriteAddr & 0xFF);      // 发送低地址
    IIC_Wait_Ack();
    IIC_Send_Byte(DataToWrite);           // 发送数据
    IIC_Wait_Ack();
    IIC_Stop();
    delay_ms(10);                         // 写入需要时间
}

注意最后的delay_ms(10)，这是必须的，因为EEPROM写入需要时间。我曾经因为没加这个延时，导致连续写入时数据丢失。

5. 常见问题与调试技巧

5.1 硬件连接问题排查

硬件问题是最常见的I2通信故障来源。首先检查电源和地线，确保所有设备共地。然后检查上拉电阻，我用的是4.7kΩ，但根据总线电容可能需要调整。

用示波器观察波形是最直接的调试方法。正常的I2C波形应该干净整齐，上升沿和下降沿陡峭。如果看到波形圆滑或者有振铃，说明总线阻抗不匹配。

有一次我遇到一个奇怪的问题：某些地址能读写，某些不能。后来发现是地址引脚没有正确接地，处于浮空状态。教训是：所有不用的地址引脚都要明确接地或接电源。

5.2 软件时序调试

软件模拟I2C的时序调试很关键。我常用的方法是在关键位置添加调试输出，或者用GPIO引脚输出调试信号，用逻辑分析仪捕捉。

延时的设置很重要，太快了设备跟不上，太慢了影响性能。24C02通常支持100kHz和400kHz两种速度。我建议开始时用较慢的速度，稳定后再尝试提高。

// 可调整的延时函数
void IIC_Delay(void)
{
    // 根据实际需要调整延时
    for(int i = 0; i < IIC_SPEED; i++) {
        __NOP();
    }
}

应答超时处理也很重要。我遇到过因为设备故障导致总线死锁的情况，后来在等待应答的地方加了超时判断，问题就解决了。

6. 性能优化与高级应用

6.1 通信速率优化

虽然24C02最高支持400kHz，但在实际应用中要考虑总线长度和设备数量。长总线需要降低速率，否则信号完整性会变差。

我通常先用100kHz调试，稳定后再尝试400kHz。切换速率时要注意所有设备都要支持该速率。有一次我提高了速率，但某个老型号传感器只支持100kHz，导致通信失败。

批量读写时可以优化性能。24C02支持页写操作，一次可以写入16字节。合理使用这个特性可以大大提高写入效率。

6.2 多设备管理

当总线上有多个设备时，需要仔细规划地址分配。24C02通过A0-A2引脚设置地址，最多可以连接8个24C02。

我建议在系统设计阶段就做好地址规划，避免冲突。可以使用一个表格来记录每个设备的地址和功能。

中断方式处理I2C通信可以提高系统效率，但实现起来更复杂。需要正确处理中断优先级和资源共享问题。在实时性要求高的系统中，中断方式是值得考虑的。

7. 实战经验与总结

经过多个项目的实践，我总结出一些软件模拟I2C的经验。首先是要有严格的时序控制，特别是延时的精度。我遇到过因为中断干扰导致延时不准的问题，后来在关键时序段禁用中断解决了。

代码封装很重要，良好的接口设计可以让I2C驱动更容易移植和重用。我将所有I2C操作封装成统一的接口，不同器件只需要实现各自的读写函数即可。

最后是要有完善的错误处理机制。I2C通信可能因为各种原因失败，良好的错误处理和恢复机制可以提高系统稳定性。我通常在通信失败后尝试复位总线，重新初始化。

最深刻的教训是：不要低估硬件问题的影响。曾经花了两天时间调试一个软件问题，最后发现是上拉电阻虚焊。现在我的调试流程总是硬件优先，先确保硬件连接正确再调试软件。

软件模拟I2C虽然比硬件方式慢一些，但更加灵活可控。对于大多数应用来说，软件模拟的性能已经足够，而且调试起来更加直观。建议初学者先从软件模拟入手，彻底理解I2C机制后再考虑使用硬件I2C。