1. 为什么需要GPIO模拟I2C？

在实际的STM32项目开发中，我们经常会遇到硬件I2C外设不够用或者兼容性不佳的情况。比如有些STM32型号的硬件I2C存在bug，或者需要同时连接多个I2C设备但硬件I2C数量有限。这时候GPIO模拟I2C就成了一个非常实用的解决方案。

我最早接触GPIO模拟I2C是在一个温湿度监测项目中，需要同时读取4个SHT20传感器的数据。硬件I2C只有两个，根本不够用。当时尝试了各种方法，最后发现GPIO模拟I2C不仅稳定可靠，还能灵活地支持多个设备。

GPIO模拟I2C最大的优势在于灵活性。你可以任意选择可用的GPIO引脚，不受硬件I2C引脚的限制。而且调试起来也相对简单，因为你可以完全控制每一个时序细节。不过需要注意的是，模拟I2C会占用一定的CPU资源，在高速通信场景下需要谨慎使用。

2. I2C协议基础与GPIO配置

2.1 I2C协议核心要点

I2C协议本质上就是通过两根线（SDA和SCL）来实现设备间的通信。理解协议的关键在于掌握几个基本信号：起始信号、停止信号、数据有效性和应答机制。

起始信号是在SCL为高电平时，SDA从高电平跳变到低电平。停止信号则是在SCL为高电平时，SDA从低电平跳变到高电平。数据有效性要求只有在SCL为高电平时，SDA线上的数据才必须保持稳定。

在实际项目中，我最常遇到的问题是时序配合不当。比如起始信号后没有给足够的延时就发送数据，或者读取数据时没有正确释放SDA线。这些问题都会导致通信失败。

2.2 GPIO开漏输出配置

使用GPIO模拟I2C时，必须将引脚配置为开漏输出模式。这是因为I2C总线具有"线与"特性，多个设备可以同时连接到总线上。

在STM32 HAL库中，配置开漏输出的代码如下：

GPIO_InitTypeDef GPIO_InitStruct = {0};
GPIO_InitStruct.Pin = GPIO_PIN_6|GPIO_PIN_7;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_OD;
GPIO_InitStruct.Pull = GPIO_PULLUP;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

这里有几个关键点需要注意：一定要启用上拉电阻，要么使用内部上拉，要么外接上拉电阻。我建议使用4.7kΩ的外部上拉电阻，这样稳定性更好。速度配置可以根据实际需求调整，如果通信速率要求不高，使用中等速度即可。

3. 模拟I2C驱动框架设计

3.1 驱动结构体定义

一个好的驱动设计应该具有良好的可移植性和可配置性。我通常定义这样一个结构体：

typedef struct {
    void (*set_sda)(uint8_t state);
    void (*set_scl)(uint8_t state);
    uint8_t (*get_sda)(void);
    void (*delay_us)(uint32_t us);
    uint32_t delay_time;
    uint8_t dev_addr;
} soft_i2c_t;

这个结构体包含了所有需要的外部依赖：SDA和SCL的控制函数、SDA读取函数、延时函数，以及延时时间和设备地址参数。这样设计的好处是，驱动代码与硬件平台完全解耦，可以轻松移植到不同的项目中。

在实际使用中，我需要为具体的硬件平台实现这些函数指针。比如对于STM32，set_sda和set_scl函数可以这样实现：

void set_sda(uint8_t state) {
    HAL_GPIO_WritePin(GPIOB, GPIO_PIN_7, (GPIO_PinState)state);
}

uint8_t get_sda(void) {
    return (uint8_t)HAL_GPIO_ReadPin(GPIOB, GPIO_PIN_7);
}

3.2 基础信号实现

起始信号和停止信号的实现需要严格遵循时序要求。以下是起始信号的典型实现：

void i2c_start(soft_i2c_t *i2c) {
    i2c->set_sda(1);
    i2c->set_scl(1);
    i2c->delay_us(i2c->delay_time);
    i2c->set_sda(0);
    i2c->delay_us(i2c->delay_time);
    i2c->set_scl(0);
}

这里有一个容易出错的地方：在产生起始信号之前，必须确保总线处于空闲状态（SDA和SCL都为高）。我遇到过很多次因为总线状态不对导致通信失败的情况。

停止信号的实现相对简单，但同样需要注意时序：

void i2c_stop(soft_i2c_t *i2c) {
    i2c->set_sda(0);
    i2c->delay_us(i2c->delay_time);
    i2c->set_scl(1);
    i2c->delay_us(i2c->delay_time);
    i2c->set_sda(1);
    i2c->delay_us(i2c->delay_time);
}

4. 数据收发与超时机制

4.1 字节发送与接收

发送一个字节的数据需要逐位处理，从最高位开始：

void i2c_send_byte(soft_i2c_t *i2c, uint8_t data) {
    for(int i = 0; i < 8; i++) {
        i2c->set_scl(0);
        i2c->set_sda((data & 0x80) ? 1 : 0);
        i2c->delay_us(i2c->delay_time);
        i2c->set_scl(1);
        i2c->delay_us(i2c->delay_time);
        data <<= 1;
    }
    i2c->set_scl(0);
}

接收字节的过程稍微复杂一些，需要在每个时钟脉冲的上升沿采样数据：

uint8_t i2c_receive_byte(soft_i2c_t *i2c) {
    uint8_t data = 0;
    i2c->set_sda(1);  // 释放SDA线
    
    for(int i = 0; i < 8; i++) {
        data <<= 1;
        i2c->set_scl(1);
        i2c->delay_us(i2c->delay_time);
        
        if(i2c->get_sda()) {
            data |= 0x01;
        }
        
        i2c->set_scl(0);
        i2c->delay_us(i2c->delay_time);
    }
    return data;
}

4.2 超时机制优化

在实际项目中，超时机制是确保系统稳定性的关键。没有超时机制的I2C驱动很容易因为设备无响应而导致整个系统卡死。

我通常使用STM32的HAL_GetTick()函数来实现超时检测：

uint8_t i2c_wait_ack(soft_i2c_t *i2c, uint32_t timeout) {
    uint32_t start_time = HAL_GetTick();
    i2c->set_sda(1);  // 释放SDA线
    i2c->set_scl(1);
    
    while(i2c->get_sda()) {
        if(HAL_GetTick() - start_time > timeout) {
            i2c->set_scl(0);
            return 1;  // 超时
        }
    }
    
    i2c->set_scl(0);
    return 0;  // 正常应答
}

这个超时机制在我的项目中发挥了重要作用。有一次一个I2C设备因为电源问题无法正常响应，正是这个超时机制防止了整个系统的死锁。

5. 多字节读写实战

5.1 多字节写入操作

在实际应用中，我们经常需要写入多个字节的数据。比如配置传感器参数时，往往需要连续写入多个寄存器。

以下是多字节写入的典型实现：

uint8_t i2c_write_bytes(soft_i2c_t *i2c, uint8_t reg_addr, uint8_t *data, uint8_t len) {
    i2c_start(i2c);
    i2c_send_byte(i2c, i2c->dev_addr << 1);  // 写操作
    if(i2c_wait_ack(i2c, 10)) return 1;
    
    i2c_send_byte(i2c, reg_addr);
    if(i2c_wait_ack(i2c, 10)) return 1;
    
    for(int i = 0; i < len; i++) {
        i2c_send_byte(i2c, data[i]);
        if(i2c_wait_ack(i2c, 10)) return 1;
    }
    
    i2c_stop(i2c);
    return 0;
}

这里需要注意设备地址的处理。I2C设备地址通常是7位，需要左移1位后，最低位表示读写方向（0为写，1为读）。

5.2 多字节读取操作

读取操作比写入操作复杂一些，因为需要先发送寄存器地址，然后重新发起起始信号进行读取：

uint8_t i2c_read_bytes(soft_i2c_t *i2c, uint8_t reg_addr, uint8_t *buffer, uint8_t len) {
    // 先发送寄存器地址
    i2c_start(i2c);
    i2c_send_byte(i2c, i2c->dev_addr << 1);
    if(i2c_wait_ack(i2c, 10)) return 1;
    
    i2c_send_byte(i2c, reg_addr);
    if(i2c_wait_ack(i2c, 10)) return 1;
    
    // 重新发起起始信号进行读取
    i2c_start(i2c);
    i2c_send_byte(i2c, (i2c->dev_addr << 1) | 0x01);
    if(i2c_wait_ack(i2c, 10)) return 1;
    
    // 读取数据
    for(int i = 0; i < len; i++) {
        buffer[i] = i2c_receive_byte(i2c);
        // 最后一个字节发送NACK，其他发送ACK
        if(i == len - 1) {
            i2c_send_nack(i2c);
        } else {
            i2c_send_ack(i2c);
        }
    }
    
    i2c_stop(i2c);
    return 0;
}

这里有一个重要的细节：在读取多个字节时，除了最后一个字节外，其他字节都需要发送ACK信号，最后一个字节发送NACK信号。这个细节很容易被忽略，但却是确保通信正确的关键。

6. SHT20温湿度传感器实战

6.1 SHT20通信协议

SHT20是一款常用的温湿度传感器，采用I2C接口。它的设备地址是0x40，使用特定的命令字来触发测量和读取结果。

常用的命令字包括：

  • 触发温度测量：0xF3
  • 触发湿度测量：0xF5
  • 读序列号：0xFA0F、0xFCC9

在实际使用中，我发现SHT20对时序要求比较严格。测量需要一定时间，读取结果前需要等待测量完成。可以通过查询设备是否响应来判断测量是否完成。

6.2 驱动实现与优化

基于我们之前实现的模拟I2C驱动，SHT20的驱动程序可以这样实现：

#define SHT20_ADDR 0x40

float read_sht20_temperature(soft_i2c_t *i2c) {
    // 触发温度测量
    i2c_write_bytes(i2c, 0xF3, NULL, 0);
    
    // 等待测量完成
    uint32_t start = HAL_GetTick();
    while(i2c_check_device(i2c, SHT20_ADDR)) {
        if(HAL_GetTick() - start > 100) return -1; // 超时
    }
    
    // 读取测量结果
    uint8_t data[3];
    i2c_read_bytes(i2c, 0, data, 3);
    
    uint16_t raw_value = (data[0] << 8) | data[1];
    return -46.85 + 175.72 * (raw_value / 65536.0);
}

在实际使用中，我发现需要添加CRC校验来确保数据的正确性。SHT20传输的数据包含CRC校验码，可以用于验证数据的完整性。

7. 常见问题与调试技巧

7.1 典型问题分析

在GPIO模拟I2C的开发过程中，我遇到过各种各样的问题。最常见的问题包括：

  1. 时序问题：延时时间不合适导致通信失败。不同设备对时序的要求可能不同，需要根据设备手册调整延时参数。

  2. 电平问题：上拉电阻不合适导致电平无法正确拉高。我建议使用示波器观察实际波形，确保高低电平符合要求。

  3. 地址问题：设备地址理解错误。有些设备使用7位地址，有些使用8位地址（包含读写位），需要仔细阅读设备手册。

  4. 多设备冲突：多个设备同时驱动总线导致冲突。确保在任何时候只有一个设备在驱动总线。

7.2 调试与优化建议

调试GPIO模拟I2C时，我总结了一些实用的技巧：

  1. 使用逻辑分析仪：这是最有效的调试工具，可以直观地观察时序波形，快速定位问题。

  2. 添加调试输出：在关键位置添加调试信息，比如每个信号产生后输出日志，帮助理解程序执行流程。

  3. 逐步验证：先从最简单的起始信号和停止信号开始验证，逐步增加功能，确保每一步都正确。

  4. 参数优化：根据实际测试结果调整延时参数，找到最适合当前设备的参数值。

我在一个项目中曾经遇到一个棘手的问题：I2C通信偶尔会失败。通过逻辑分析仪发现，是因为SCL线的上升沿太慢，导致数据采样时间不足。通过减小上拉电阻值，问题得到了解决。

8. 性能优化策略

8.1 延时优化

延时时间是影响I2C通信速率的关键因素。过长的延时会降低通信速率，过短的延时可能导致通信失败。

我通常采用动态调整延时的方法：先使用较长的延时确保通信稳定，然后逐步缩短延时直到出现错误，最后选择一个留有裕量的值。

对于STM32，可以使用DWT（Data Watchpoint and Trace）单元来实现更精确的延时：

void delay_us(uint32_t us) {
    uint32_t start = DWT->CYCCNT;
    uint32_t cycles = us * (SystemCoreClock / 1000000);
    while((DWT->CYCCNT - start) < cycles);
}

这种方法比使用HAL_Delay()更精确，可以减少不必要的等待时间。

8.2 代码优化

代码层面的优化也很重要。比如减少函数调用层次、使用内联函数、优化循环结构等。

对于频繁调用的函数，可以考虑使用宏定义来减少函数调用开销：

#define I2C_DELAY() do { \
    for(int i = 0; i < 10; i++) { \
        __NOP(); \
    } \
} while(0)

#define I2C_SET_SDA_H() HAL_GPIO_WritePin(GPIOB, GPIO_PIN_7, GPIO_PIN_SET)
#define I2C_SET_SDA_L() HAL_GPIO_WritePin(GPIOB, GPIO_PIN_7, GPIO_PIN_RESET)

但是需要注意，过度使用宏会影响代码的可读性和可维护性，需要在性能和代码质量之间找到平衡。

在实际项目中，我还会根据具体需求选择不同的优化策略。比如对于实时性要求高的应用，优先保证通信速率；对于功耗敏感的应用，则可能选择较低的通信速率来降低功耗。

经过这些优化，GPIO模拟I2C的性能可以接近硬件I2C的水平，在大多数应用场景下都能满足需求。特别是在多设备、需要灵活引脚分配的场合，GPIO模拟I2C的优势更加明显。

Logo
乐奇 Rokid 开放社区

更多推荐

FPC与机器人的双向赋能，解锁智能装备进化新势能

如果说AI算法、算力芯片是智能眼镜的“智慧大脑”，光学模组是智能眼镜的“视觉窗口”，那么FPC就是贯穿整机、连接所有功能模块的“柔性神经脉络”。方寸之间的柔性突破，破解了智能眼镜“轻薄形态”与“全能功能”的核心矛盾，是穿戴智能设备实现形态革新、体验升级的底层核心。未来，随着AR沉浸式技术、AI大模型、穿戴硬件技术的持续进化，智能眼镜将朝着更轻薄、更智能、更多场景、更高稳定性的方向持续迭代，对高端精

avatar 乐奇 Rokid 开放社区
cover

智能眼镜新品扎堆：AR、VR、MR到底怎么分？

avatar 乐奇 Rokid 开放社区
cover

AI眼镜里面有晶振吗？智能眼镜的时钟系统

avatar 乐奇 Rokid 开放社区