从零构建SMBus通信：如何用GPIO“手搓”一条系统管理总线

你有没有遇到过这样的情况？项目里需要读取电池电量、监控温度，或者配置一个电源芯片，却发现主控MCU没有I²C外设——甚至连基本的硬件串行接口都挤不出来。这时候，摆在面前的路似乎只剩一条：自己动手，用软件模拟出整个通信协议。

而我们要聊的，就是嵌入式系统中那个看似低调却无处不在的“幕后英雄”——SMBus（System Management Bus）。它不像SPI那样高速，也不像UART那样直白，但它稳扎稳打地运行在无数服务器、笔记本、工业设备和智能模块中，负责着电源管理、热监控、电池通信等关键任务。

今天我们就来干一件“硬核”的事：不靠任何专用硬件，仅靠两个GPIO引脚，从头实现一套完整的SMBus通信机制。这不是理论推演，而是真正能跑在STM32、GD32、甚至8051上的实战方案。

为什么是SMBus？它和I²C到底什么关系？

先说个真相：很多人把SMBus当成“I²C的别名”，这其实是个危险的误解。

没错，SMBus确实基于I²C的物理层设计，使用相同的两根线——SCL（时钟）和SDA（数据），也采用主从架构、7位地址、ACK应答机制。但它的目标更明确：为系统管理提供可靠、标准化的通信通道。

这就意味着，SMBus对协议细节做了更严格的约束：

• 超时机制强制生效：SCL高电平持续时间不能超过35ms，防止总线死锁。
• 电平阈值更严苛：输入高电平必须 ≥0.7×VDD，低电平 ≤0.3×VDD，抗干扰能力更强。
• 必须支持ACK/NACK：每个字节后接收方都要回应，否则视为失败。
• 可选PEC校验：即CRC-8包错误检查，确保数据完整性。
• 定义了标准命令集：如Read Byte、Write Word、Process Call等，提升互操作性。

所以，如果你要对接的是TI的BQ系列电池芯片、Maxim的MAX166x电源控制器，或是Intel平台上的PCH南桥，那你面对的就是真正的SMBus设备，而不是随便一个I²C传感器。

⚠️ 重点来了：你可以用I²C控制器去驱动SMBus设备（通常兼容），但反过来不行——用I²C的宽松时序去模拟SMBus，很可能导致通信不稳定或直接失败。

没有硬件I²C？那就“位 banging”吧！

当你的MCU连最基础的I²C外设都没有时，唯一的出路就是——软件模拟，也就是常说的“bit-banging”。

原理很简单：我们找两个通用GPIO，一个接SCL，一个接SDA，然后通过精确控制这两个引脚的电平变化，手动“捏”出符合SMBus规范的波形。

听起来像“手工焊电路”一样原始，但在资源受限的场景下，这是最灵活、成本最低的解决方案。

所需资源清单

📌 特别提醒：SMBus总线是开漏结构，SCL和SDA都需要上拉电阻才能正常拉高。如果没有外部上拉，务必确认MCU是否支持强上拉（部分低端芯片内部上拉弱于100kΩ，会导致上升沿过缓）。

核心时序：每一步都不能错

SMBus标准模式速率是100kbps，对应每位传输时间为10μs左右。但我们不能只看平均速率，关键是要满足每一个最小/最大时间参数。

以下是SMBus标准模式下的核心时序要求（摘自 SMBus Spec 3.1）：

这些数字看着不起眼，但如果CPU主频只有8MHz，每条指令周期约125ns，稍不留神就会超出容限。

举个例子：在发送一位数据时，流程应该是：

set_scl_low(); // 拉低时钟 delay_us(2); // 留出设置时间 set_sda(data_bit ? 1 : 0); // 设置数据 delay_us(2); // 满足T_SU:DAT set_scl_high(); // 上升沿采样 delay_us(5); // 维持T_HIGH

如果中间少了那200ns的延迟，从机可能还没准备好就读取了数据，结果就是通信失败。

关键函数实现：从START到STOP

下面我们一步步写出SMBus软件模拟的核心函数。以下代码可在大多数ARM Cortex-M平台上直接移植，只需修改GPIO宏定义。

引脚与方向控制

// 根据实际硬件修改 #define SCL_PIN GPIO_PIN_6 #define SDA_PIN GPIO_PIN_7 #define PORT GPIOB // 方向切换宏（以STM32为例） #define SET_SDA_INPUT() do { \ MODIFY_REG(PORT->MODER, GPIO_MODER_MODER7_Msk, GPIO_MODER_MODER7_0); \ } while(0) #define SET_SDA_OUTPUT() do { \ SET_BIT(PORT->MODER, GPIO_MODER_MODER7_1); \ } while(0) // 电平操作 static inline void set_scl_high(void) { HAL_GPIO_WritePin(PORT, SCL_PIN, GPIO_PIN_SET); } static inline void set_scl_low(void) { HAL_GPIO_WritePin(PORT, SCL_PIN, GPIO_PIN_RESET); } static inline void set_sda_high(void) { HAL_GPIO_WritePin(PORT, SDA_PIN, GPIO_PIN_SET); } static inline void set_sda_low(void) { HAL_GPIO_WritePin(PORT, SDA_PIN, GPIO_PIN_RESET); } static inline uint8_t read_sda(void) { return HAL_GPIO_ReadPin(PORT, SDA_PIN); } // 用户需提供微秒延时 void delay_us(uint16_t us);

起始条件（START）

这是每次通信的起点，也是最容易出问题的地方。

void smb_start(void) { // 初始状态：SCL=1, SDA=1 set_sda_high(); set_scl_high(); delay_us(5); // START: SDA从高到低，SCL保持高 set_sda_low(); delay_us(5); // 满足T_HD:STA set_scl_low(); // 进入数据传输阶段 }

💡 小技巧：有些从机对T_SU:STA非常敏感，建议在set_sda_low()之前额外加一个小延时（如2μs），确保SCL已经稳定为高。

停止条件（STOP）

与START相反，STOP标志着一次事务结束。

void smb_stop(void) { set_scl_low(); set_sda_low(); delay_us(5); set_scl_high(); // 先升SCL delay_us(5); set_sda_high(); // 再升SDA → 形成STOP条件 delay_us(5); }

注意顺序：必须先升SCL，再升SDA，否则会被误判为重复起始（Re-Start）。

发送一个字节 + 等待ACK

uint8_t smb_write_byte(uint8_t data) { uint8_t i; for (i = 0; i < 8; i++) { set_scl_low(); delay_us(2); if (data & 0x80) set_sda_high(); else set_sda_low(); delay_us(2); set_scl_high(); // 上升沿被采样 delay_us(5); // 维持T_HIGH set_scl_low(); data <<= 1; } // 接收ACK：第9个时钟周期 set_sda_high(); // 主机释放SDA SET_SDA_INPUT(); // 切换为输入 delay_us(1); set_scl_high(); delay_us(5); uint8_t ack = !read_sda(); // 低电平表示ACK set_scl_low(); SET_SDA_OUTPUT(); // 恢复输出 delay_us(2); return ack; // 返回1表示收到ACK }

读取一个字节 + 发送ACK/NACK

uint8_t smb_read_byte(uint8_t send_ack) { uint8_t i; uint8_t data = 0; SET_SDA_INPUT(); // SDA作为输入 for (i = 0; i < 8; i++) { delay_us(2); set_scl_high(); delay_us(5); data = (data << 1) | read_sda(); set_scl_low(); delay_us(2); } // 发送ACK/NACK SET_SDA_OUTPUT(); if (send_ack) set_sda_low(); // ACK: 拉低 else set_sda_high(); // NACK: 释放 delay_us(2); set_scl_high(); // 第9个时钟脉冲 delay_us(5); set_scl_low(); return data; }

实战案例：读取TMP102温度传感器

现在让我们用上面的函数读取一款常见的SMBus温度传感器——TMP102。

它的基本信息如下：
- 从机地址：0x48（7位）
- 温度寄存器地址：0x00
- 数据格式：12位补码，分辨率0.0625°C

完整读取流程如下：

float read_temperature(void) { uint8_t temp_h, temp_l; int16_t raw; float temperature; smb_start(); if (!smb_write_byte(0x48 << 1)) { // 写地址 smb_stop(); return -1000.0f; // 无ACK } smb_write_byte(0x00); // 指定寄存器 smb_start(); // 重复起始 if (!smb_write_byte((0x48 << 1) | 1)) { // 读地址 smb_stop(); return -1000.0f; } temp_h = smb_read_byte(1); // 高字节，发ACK temp_l = smb_read_byte(0); // 低字节，发NACK smb_stop(); // 合并数据（只用高12位） raw = (temp_h << 8) | temp_l; raw >>= 4; // 右移4位 if (raw & 0x800) raw |= 0xF000; // 补码扩展 temperature = raw * 0.0625f; return temperature; }

这个函数涵盖了典型的SMBus“写-读”复合操作，适用于绝大多数寄存器型从设备。

常见坑点与调试秘籍

即使代码逻辑正确，实际调试中仍会遇到各种诡异问题。以下是几个高频“踩坑”场景及应对策略：

❌ 问题1：始终收不到ACK

可能原因：
- 地址没左移！SMBus写地址是(slave_addr << 1)，读是(... | 1)
- 上拉电阻缺失或阻值过大（>10kΩ）
- 从设备未供电或处于复位状态
- SCL/SDA接反

排查方法：
- 用示波器抓取波形，观察SDA是否能在第9个周期被拉低
- 加大延时测试（临时将所有delay_us(5)改为10），排除时序过紧问题

❌ 问题2：偶发性通信失败

典型表现：重启后有时通有时不通。

根源分析：
- 中断抢占破坏了时序（比如SysTick打断了SCL翻转）
- 电源噪声导致电平误判
- 总线残留电荷未释放

解决方案：
- 在smb_start()到smb_stop()之间禁用全局中断（临界区保护）
- 添加重试机制（最多3次）
- 初始化时执行一次“总线恢复”：快速翻转SCL 9次，强迫从机释放总线

void smb_bus_recovery(void) { int i; set_sda_high(); for (i = 0; i < 9; i++) { set_scl_low(); delay_us(5); set_scl_high(); delay_us(5); } }

工程化建议：让你的模拟代码更健壮

别让“临时方案”变成“长期负债”。为了让这套GPIO模拟SMBus能在产品中稳定运行，请遵循以下最佳实践：

1. 封装抽象层
   把set_scl_low()这类底层操作封装成独立模块，未来更换平台时只需改一处。

2. 引入状态机
   对复杂命令（如Block Read with PEC），使用状态机管理流程，避免嵌套过深。

3. 添加超时机制
   所有等待操作（如等ACK）都应设置最大等待次数，防止死循环。

4. 支持动态频率适配
   不同主频下delay_us()行为不同，建议根据SystemCoreClock自动调整延时系数。

5. 启用可选调试日志
   加一个#define SMBUS_DEBUG开关，输出关键事件便于现场排查。

6. 优先使用硬件外设
   如果后期升级到带I²C的MCU，记得替换为硬件驱动，降低CPU负载。

写在最后：软硬兼施才是王道

也许有一天你会觉得，“用手敲时序太原始了”。但正是这种“返璞归真”的实践，让我们真正理解了那些藏在寄存器背后的通信本质。

GPIO模拟SMBus不是终点，而是一把钥匙——它打开了通往更多协议解析的大门（比如PMBus、IPMI、SMLink）。更重要的是，在资源紧张、工具匮乏的开发环境中，这项技能往往能救你一命。

下次当你面对一块没有I²C的老旧MCU，或是要在Bootloader里读个电池电量时，不妨试试这条路：两条线，两段延时，一段代码，就能唤醒整个系统的“生命体征”。

如果你正在做类似的项目，欢迎在评论区分享你的调试经历。毕竟，每一个成功的ACK背后，都有过无数次SDA沉默的夜晚。