硬件I2C与软件I2C实测对比：坑点、恢复与选型指南

最近在驱动交流群里又看到一个经典问题：硬件 I2C 和软件 I2C 到底谁更坑？我本来想回一句“都坑，看你踩哪一个”，但想了想，这话说了等于没说，而且凭我的经验，这个问题的答案确实不是一句玩笑能带过的。上周正好在调一批板子，一边是 AS5600 磁编码器读取，走的是 STM32 的硬件 I2C；另一边是一块 SSD1306 的 OLED 屏，为了省引脚临时用 GPIO 模拟的软件 I2C。两边项目同时推进，我等于被逼着把两种实现方式的坑都完整踩了一遍，从时序异常到状态机假死，从中断打断到地址错位，最后还总结出了一套通用的切换思路。

这篇文章就想把这回实测对比写清楚：硬件 I2C 的坑长在哪里，软件 I2C 的坑又长在哪里，以及当你必须在两者之间做选择时，应该拿什么标准来拍板。我相信只要你实际调过 I2C 外设，读到后面肯定会有共鸣。

1. 为什么“硬件 I2C 和软件 I2C 谁更坑”能成为驱动圈的连续剧

1.1 先交代背景：这篇文章想讲哪件事

在嵌入式驱动开发里，I2C 是一个绕不开的总线协议。芯片外围有大量的传感器、存储器、显示屏、电源管理芯片都在用 I2C 通信，典型代表有 AS5600 角度传感器、SSD1306 OLED、LSM6DSR 六轴传感器、W25Q32 这类 SPI 器件也有 I2C 版本，甚至 DHT11 这类“看起来只有一根数据线”的温湿度传感器，本质上也是类似 I2C 的单总线时序。所以每个做驱动的工程师，基本都会经历一场“硬件 I2C 还是软件 I2C”的抉择。

我参与的这个“驱动之路”系列已经写到第 44 篇，往期内容大多围绕某一种驱动程序的分析，而这篇文章比较特殊：我不打算只讲某颗芯片，而是想借两个真实翻车现场，把 I2C 的两种实现方式放在同一杆秤上称一称。

先把话说在前面：硬件 I2C 指的是使用 MCU 内部集成的 I2C 外设模块，你只需要往寄存器里配置地址、数据、控制位，外设会自动产生 SCL 时钟、逐位搬运数据、发送起始和停止条件。软件 I2C 则是用普通 GPIO 引脚，在代码里通过不停地拉高拉低电平、控制电平翻转时刻，手动模拟出 I2C 的时序。两者最终在物理总线上的波形可以几乎一样，但设计哲学完全不同，坑自然也不同。

1.2 两套实现能“完成同一件事”，但完成方式完全不同

先做个不严谨但很形象的类比：硬件 I2C 像是开自动挡汽车，你觉得只要挂挡踩油门，剩下的交给变速箱；软件 I2C 像是开手动挡，所有换挡时机都得自己用脚和手配合，配合得好很顺滑，配合不好就顿挫甚至熄火。

开自动挡也会出问题，比如变速箱换挡逻辑死机、报错让你不知所措。硬件 I2C 外设内部的有限状态机一旦进入某个异常状态，你可能连手动干预的入口都找不到。而手动挡的问题则是另外一类，你的操作必须精确，差几个微秒的时序错误，数据就悄悄错了，甚至没有任何报错迹象。

我这次在两块板上的调速经历，恰好就把这两类问题都演示了一遍。所以在往下看之前，你先记住一个判断主线：硬件 I2C 的坑偏向“状态机的复杂性”，软件 I2C 的坑偏向“时序和并发的不确定性”。后续所有细节都会围绕这条主线展开。

2. 硬件 I2C 的坑：状态机的脾气比你想的更大

2.1 “全自动”只是个幻觉，I2C 外设本质上是状态机

很多初学者以为硬件 I2C 会自动处理一切，其实外设只是把协议状态机帮你在硅片上做了。你配置寄存器后，它会按顺序执行：产生起始条件、发送从机地址、等待 ACK、传输数据、接收 ACK 或 NACK、产生停止条件。每一步之间，硬件都会内部切换状态，并往状态寄存器或中断标志里写值。

问题就出在“切换状态”这个动作上。真实总线是不完美的，从机可能回应了奇怪的时序，总线可能被瞬时毛刺干扰，外部干扰可能让某一位电平翻转。这些事情不会恰好发生在你预期的位置。一旦状态机没有转到你预想的下一步，外设就会进入一个“不是忙、不是完成、也不是错误”的尴尬地带。

我在调试 AS5600 时遇到的情况就很典型。AS5600 是 AMS 推出的一款磁旋转编码器，I2C 从机地址是 0x36（7 位地址），数据手册标称支持最高 400kHz 的时钟。这个芯片在工作时持续输出角度数据，驱动的主要任务就是周期性地读取 0x0C~0x0D 两个寄存器里的角度值。听起来特别简单对吧，但简单地读两个字节，在硬件 I2C 上就可以出现奇怪现象。

2.2 总线忙：硬件里最经典的假死状态

最让我头疼的，不是 AS5600 本身不响应，而是 STM32 的 I2C 外设突然进入了“BUSY”状态。这个 BUSY 不是你想象的总线上有数据在跑，而是外设认为总线正在被别人占用，于是拒绝发起任何新的通信。

这种假死状态的触发原因有很多，常见的有几种：通信过程中从机突然复位，导致 SCL/SDA 的电平配合被打乱；热插拔器件时总线电平出现半高状态；或者你在一个事务还没结束时抢先复位了 MCU，外设和从机的相位对不上。一旦外设判断总线忙，之后你再去调用 HAL_I2C_Mem_Read 之类的接口，结果往往不是报错，而是直接超时。

超时之后 HAL 返回 HAL_TIMEOUT，这个返回码如果你的代码没有每次都检查，接下来程序就会继续执行，拿到的还是上一次缓冲区里的旧数据。AS5600 的角度数据表现出的症状就是“部分刷新、数值偶尔跳变、再读恢复”，很难通过简单打印直接定位。

当时解决的办法分三步：第一步，查看 I2C 外设的状态寄存器，确认到底是 BUSY、AF（应答失败）还是别的标志；第二步，直接用软件复位外设，常见的做法是调用 DeInit 再 Init，或者直接操作外设寄存器里的 SWRST 位；第三步，如果 SCL 或 SDA 线上的电平已经被拉死，需要先把相关引脚重新配置成 GPIO 输出，手动翻转 SCL 产生 9 个以上的脉冲，帮总线“解套”。

下面是我在 HAL 环境里常用的恢复代码片段，核心思路是彻底干掉 I2C 外设的状态，再做一次干净的重初始化：

void i2c_bus_recover(I2C_HandleTypeDef *hi2c) { GPIO_InitTypeDef gpio = {0}; // 1. 先关掉 I2C 外设 __HAL_I2C_DISABLE(hi2c); // 2. 把 SCL 和 SDA 引脚临时切换成普通推挽输出 gpio.Pin = SCL_PIN | SDA_PIN; gpio.Mode = GPIO_MODE_OUTPUT_PP; gpio.Pull = GPIO_PULLUP; gpio.Speed = GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(I2C_GPIO_PORT, &gpio); // 3. 手动翻转 SCL，产生至少 9 个时钟脉冲 HAL_GPIO_WritePin(I2C_GPIO_PORT, SCL_PIN, GPIO_PIN_SET); for (int i = 0; i < 9; i++) { HAL_GPIO_WritePin(I2C_GPIO_PORT, SCL_PIN, GPIO_PIN_RESET); for (volatile uint32_t t = 0; t < 100; t++); HAL_GPIO_WritePin(I2C_GPIO_PORT, SCL_PIN, GPIO_PIN_SET); for (volatile uint32_t t = 0; t < 100; t++); } HAL_Delay(1); // 4. 恢复成 I2C 复用功能 gpio.Pin = SCL_PIN | SDA_PIN; gpio.Mode = GPIO_MODE_AF_OD; gpio.Pull = GPIO_PULLUP; HAL_GPIO_Init(I2C_GPIO_PORT, &gpio); // 5. 重新初始化外设 HAL_I2C_DeInit(hi2c); HAL_I2C_Init(hi2c); }

这段代码既是急救手段，也是一步一步排查的必经过程。老实说，功能上不算复杂，但真正在项目里经历过“读着读着角度就不动了，重新插拔电源又好了”的读者，应该能理解我写出这段代码时的心情。

总线忙这个坑的最大特点，就是它的出现往往没有任何固定复现条件，可能连续跑一万次都正常，下一次就卡住。我在后面实测部分会详细讲它实际翻车的整个过程。

2.3 时钟拉伸、NACK 和“慢从机”的不适配

硬件 I2C 的另一个坑，是它对从机行为的要求比软件 I2C 更“死板”。在 I2C 协议里，从机可以通过拉低 SCL 来要求主机等待，这叫时钟拉伸。很多传感器和 EEPROM 在内部忙时会用这招，这是协议允许的。

问题在于，不少 MCU 的硬件 I2C 外设虽然支持时钟拉伸，但对拉伸时间的上限和检测方式有自己的偏好。有些外设在 SCL 被拉低后会一直在硬件层面等待，直到从机释放 SCL，如果从机忙了太久，主机外设的等待超时配置不合理，整个事务就会卡死在中间。

我在项目中碰到过一种情况：从机在写寄存器后需要几十毫秒的处理时间，每次写完紧接着读，硬件 I2C 就可能出现 NACK。因为从机还在忙，根本来不及响应你紧跟而来的下一次通信。这类时序问题让“全自动”的硬件外设显得很笨，它不会体贴地帮你判断“此时应该等一等再发下一帧”。

和 NACK 相关的还有一个新手坑，很多人做硬件 I2C 时都会踩：I2C 的 7 位地址和 8 位地址混淆。比如 AS5600 的器件地址是 0x36，这个 0x36 是 7 位地址，写到 I2C 总线上时要左移一位，变成 0x6C 作为写地址、0x6D 作为读地址。不少人在 HAL 的接口里直接传入 0x36，导致地址错误、设备无应答。我之前还在群里见过有人为此调了一整天，最后发现就是没左移这一位。硬件 I2C 的报错在这种情况下一般就是 AF 标志置位，数据手册又不会特意把“你漏了左移”写在醒目位置。

3. 软件 I2C 的坑：时序、中断打断与 9 拍 ACK 的代价

3.1 你以为写位翻转很简单，其实真正要看的是时序

软件 I2C 的优势非常明显：随便找两个 GPIO 就能当 SCL 和 SDA，不受 MCU 引脚复用表限制，换板子也方便。我这次用软件 I2C 驱动 OLED，就是为了省出一组硬件外设引脚给其他功能用。

但软件 I2C 的基础就是反复做引脚电平翻转。每次发送一位，主机要把 SDA 的数据准备好，然后拉高 SCL，保持一段时间，再拉低 SCL，准备下一位。这段“保持时间”如果太短，从机采样不到正确电平；如果太长，总线的通信速率会严重拖慢；如果在关键电平保持期间被别的代码打断，波形就更不可控了。

我之前见过一个很形象的说法，说软件 I2C 就像两个人约定好每秒钟说一个字，结果对方经常说完一个字后停顿两三秒再继续说，沟通效率低且容易让人抓狂。从机虽然不会“抓狂”，但它对电平持续的窗口是有要求的，高电平或低电平持续时间低于其最小阈值，它就可能把 0 误判成 1，或者干脆忽略这一拍。

一个最朴素的软件 I2C 位操作代码大概长这样：

#define SCL_H() HAL_GPIO_WritePin(SCL_GPIO_Port, SCL_Pin, GPIO_PIN_SET) #define SCL_L() HAL_GPIO_WritePin(SCL_GPIO_Port, SCL_Pin, GPIO_PIN_RESET) #define SDA_H() HAL_GPIO_WritePin(SDA_GPIO_Port, SDA_Pin, GPIO_PIN_SET) #define SDA_L() HAL_GPIO_WritePin(SDA_GPIO_Port, SDA_Pin, GPIO_PIN_RESET) #define SDA_READ() HAL_GPIO_ReadPin(SDA_GPIO_Port, SDA_Pin) static void i2c_delay(void) { for (volatile uint32_t i = 0; i < 200; i++); } void i2c_start(void) { SDA_H(); SCL_H(); i2c_delay(); SDA_L(); i2c_delay(); SCL_L(); } void i2c_stop(void) { SDA_L(); SCL_H(); i2c_delay(); SDA_H(); i2c_delay(); } uint8_t i2c_write_byte(uint8_t data) { for (uint8_t bit = 0; bit < 8; bit++) { if (data & 0x80) SDA_H(); else SDA_L(); data <<= 1; i2c_delay(); SCL_H(); i2c_delay(); SCL_L(); i2c_delay(); } // 第 9 个时钟，读取从机的 ACK SDA_H(); i2c_delay(); SCL_H(); i2c_delay(); uint8_t ack = (SDA_READ() == GPIO_PIN_RESET) ? 0 : 1; SCL_L(); return ack; }

代码看起来人畜无害，可实际跑起来，问题全出在工作环境。i2c_delay 是忙等循环，循环期间 CPU 只能干等着，这本身就是一笔不小的性能开销。更麻烦的是，如果这个代码运行在主循环里，突然来了一个定时器中断，CPU 跳去执行中断服务函数，折腾几百个周期再回来，SCL 高电平的时间就被无端拉长了。

对于大多数慢速器件来说，一个 SCL 高电平多个几百指令周期问题不大，因为协议本身对高电平最大时间没有硬性限制。可如果你把刷新 OLED 的工作放在周期性的任务里，时序抖动会导致帧数据处理跟不上，表现就是屏幕局部撕裂、乱码、偶发白屏。更严重的情况是，ISR 耗时太久，一个字节还差两拍没传完就被中断，回来继续传时波形已经完全不符合 I2C 协议，从机直接丢掉同步。

3.2 中断和任务切换：软件 I2C 的头号杀手

软件 I2C 最大的不稳定因素不是函数写得不好，而是并发。

在裸机编程里，中断随时可能插一脚；在带 RTOS 的系统里，高优先级任务也可能抢占当前正在做位翻转的任务。只要你在位翻转中途被切走，时序就变形了。有些工程师会在 i2c_delay 前后临时关闭中断，这种做法能解决一部分问题，但代价是系统实时性受损。更合理的方式是把软件 I2C 的整个通信过程放在临界区里，关中断的时间会被拉长到一次完整读写，这对中断响应要求高的系统是不可接受的。

我的做法是分层看问题：如果软件 I2C 只是用来初始化外设，比如每次开机写一次显示屏配置，中断打断的影响微乎其微，因为就算波形变形，通信失败后重试一次也就好了。如果软件 I2C 承担高频周期性读写任务，比如每秒刷新几十次角度数据，那中断引起的波形畸变就会积累成大问题。

针对 OLED 这个例子，我最后把软件 I2C 的调用点改成一个不带任务抢占的专用低优先级线程，并在每次完整帧传输前加 5 毫秒的互斥锁保护。这样中断还是能打断单片机，但数据读取过程被限制在不会被高优先级任务长期抢走 CPU 的区间内。这个方法不算完美，但在成本和引脚约束下已经是比较实用的折中方案。

3.3 此“ACK”非彼“ACK”：从机等待、时钟拉伸和 9 拍细节

软件 I2C 还有一个容易被忽略的细节，就是 ACK 的判断时机。很多人在写软件 I2C 时，发送完 8 位数据就直接拉高 SCL，然后默认从机一定会回 ACK，但真实从机不一定会配合。

I2C 协议规定，主机在发送完每个字节后的第 9 个时钟周期释放 SDA，由从机拉低 SDA 来表示 ACK。要注意，这个 ACK 的判断必须发生在 SCL 高电平的中间段，而且很多从机在发送 ACK 之前需要一点时间准备。如果主机拉高 SCL 后立刻去读 SDA，从机还没来得及把 SDA 拉低，你就会误判为 NACK。

软件 I2C 在这一点上比硬件 I2C 更容易踩坑，因为软件实现完全靠代码节奏控制。你在 SCL 拉高后如果没有加微小延迟就去读 SDA，那基本每次都会读到高电平，得到“从机不响应”的错误结论。当时我在调 OLED 时也遇到过类似的误判，调试了很久才发现不是时序太慢，而是时序太快，从机“来不及回话”。

另一个相关问题是时钟拉伸检测。功能正常的 I2C 从机慢的时候会拉低 SCL 让主机等待，但软件 I2C 如果不主动检测 SCL 电平，而只是机械式地拉高拉低自己的引脚，就完全无法感知从机的等待需求。具体表现是：从机内部忙时，主控继续按自己的节奏翻转 SCL，结果数据在从机端被错误采样。这个问题的解决方案也不复杂，在每次 SCL 拉高后加入一个轮询循环，检查 SCL 引脚的实际电平是否被从机拉低：

static void i2c_wait_clock_stretch(void) { for (uint32_t timeout = 0; timeout < 10000; timeout++) { if (SCL_READ() != GPIO_PIN_RESET) { break; // SCL 恢复高电平，继续 } } }

把这个函数插入到位翻转的 SCL 拉高之后，软件 I2C 的兼容性会提升不少。但这个轮询本质上也是忙等，如果从机拉低时间过长，主控 CPU 就会卡在循环里出不来，所以超时值必须合理配置。

4. 同板实测：AS5600 连续读取和 OLED 刷屏，两种 I2C 的翻车方式完全不一样

4.1 测试场景：为什么要拿 AS5600 和 OLED 说事

理论讲了半天，接下来聊聊我这周实际看到的“交通事故”。

选这两个器件也很讲究。AS5600 是实时输出型传感器，需要连续读两个字节，数据随时在变化，很适合暴露通信中断、总线忙这类偶发问题。SSD1306 OLED 则是典型的多字节写设备，每帧都要写入大量显示数据，速率不足或者时序抖动，屏幕立刻给你反馈，肉眼就能看出问题。

这两个器件的应用场景也很有代表性：一个代表低速高要求的传感器读取，频率低但可靠性要求高；另一个代表高速大批量的数据传输，容量大但对实时性相对不是特别敏感。

4.2 硬件 I2C 的翻车：连续读取 AS5600 偶发数据漂移，问题出在“总线忙”

AS5600 的读取逻辑是：发送寄存器地址 0x0C，然后重新产生起始条件，再发送读地址开始读两个字节。硬件 I2C 用 HAL_I2C_Mem_Read 一条指令就能完成，非常方便。代码大概长这样：

uint8_t angle_buf[2]; HAL_StatusTypeDef status = HAL_I2C_Mem_Read(&hi2c1, 0x36 << 1, 0x0C, I2C_MEMADD_SIZE_8BIT, angle_buf, 2, 100); if (status == HAL_OK) { uint16_t angle = (angle_buf[0] << 8) | angle_buf[1]; }

第一版里我对返回值检查不严格，结果就出事了。程序跑起来大多数时间是正常的，但每隔一段时间角度值会突然跳一大截，然后又恢复正常。一开始我怀疑是 AS5600 本身受磁场干扰，后来在总线上用示波器抓波形，发现某一帧读操作没有任何输出波形，也就是 MCU 压根没有发起 I2C 通信。

继续深挖状态寄存器，发现 I2C 外设的 BUSY 位一直被置 1。也就是说外设认为总线处于忙状态，所有后续通信都被它自己挡掉了。HAL_I2C_Mem_Read 在超时后返回 HAL_TIMEOUT，但由于我没有检查返回值，angle_buf 里存的是上次读取的旧值，于是角度数据表现为“跳回旧值再恢复正常”。把现象翻译成业务语言，就是传感器“偶尔丢帧”。

根因是外部干扰还是上电时序导致的电平异常，我没有完全定位到单点原因，但对策比较明确：每次读取前检查外设状态，发现 BUSY 就执行前面那套 I2C 总线恢复函数。加上这个检查之后，连续跑了几个小时没有再出现偶发丢帧。

这算是一个很典型的“硬件 I2C 更坑”案例，因为它随机、隐蔽、不好复现。如果只看现象，你会以为是算法问题，或者是传感器问题，很少想到问题出在 MCU 外设的内部状态上。

4.3 软件 I2C 的翻车：OLED 刷新闪烁，中断一来就花屏

另一个项目是软件 I2C 驱动 SSD1306 OLED。这个屏最常见的是 128x64 分辨率，I2C 模式下写一帧全屏数据要传输上千字节，对速度要求远比单次读两个字节高。

我用软件 I2C 刷屏时，静态显示没有问题，但一旦画面带动态数据，比如不断变化的数字，屏幕就开始出现横向撕裂感，偶尔整块区域闪白。示波器抓 SCL 波形后，能看到 SCL 的周期忽长忽短，不是稳定的连续波形。深入一看，是定时器中断每隔一段时间就进来读取一个编码器计数值，中断服务函数里有一些浮点运算，耗时较长，导致软件 I2C 的位翻转被大幅延迟。

问题的本质不是软件 I2C 代码写错，而是它所在的执行环境没有给它提供“稳定的时间切片”。我在中断里用了一个全局标志位，让主循环集中处理编码器数据后，再统一刷屏，屏幕画面明显稳定了很多。后来我又给每一次完整显示帧的传输加了一个简单的忙标志，避免两个任务同时操作软件 I2C 总线，最终动态刷新基本能保持流畅。

软件 I2C 的坑就是这样，它不会像硬件 I2C 那样沉默拒绝通信，而是用“数据错误、画面撕裂”这样直观的方式告诉你时序被破坏了。好在它比较好理解，调试方向清晰，基本往中断和优先级上排查就能解决问题。

4.4 把两次翻车放在一张表里对比

我把这两次翻车的特点整理成了表格，方便大家对照：

提到表格，有读者可能注意到一个细节：当软件 I2C 被中断打断时，从机不见得会立刻出错，因为从机端有输入缓冲和时序容差，唯有当波形畸变超出了它内部最小采样窗口，才会丢数据。这也是为什么很多人复现软件 I2C 问题时觉得“时好时坏”，因为只有时序扭曲到一定程度才会触发故障。

5. 从踩坑经验里提炼选型原则：抽象层、超时与两条底线

5.1 我倾向的选择逻辑：看代码结构，不看外设“高级感”

经历了这么多实际问题，我对“硬件 I2C 和软件 I2C 到底选谁”有了更落地的看法。

如果你问“谁更坑”，我的答案是：硬件 I2C 的坑更隐蔽，软件 I2C 的坑更琐碎。硬件 I2C 一旦出问题，定位链路长，涉及寄存器状态、外设时序、从机协议，新手很容易被绕晕；软件 I2C 虽然容易把现象暴露得明明白白，但要保证它在复杂的实时系统里稳定运行，需要你花不少心思处理中断和并发。

所以在实际选型时，我更看重的是项目节奏和代码结构：

• 如果项目里已经有完善的中断管理和任务优先级划分，而且你有信心不让总线操作被长服务函数打断，软件 I2C 完全够用，还省引脚。
• 如果项目对可靠性要求极高、通信频率也高，或者你在做批量量产产品，我会毫不犹豫选择硬件 I2C，同时把错误标志检查和总线恢复逻辑写进驱动。
• 如果只是原型验证、临时飞线测试，那根本不用纠结，直接软件 I2C 最快。

这里还要多说一句，很多人选硬件 I2C 是冲着速度去的。硬件 I2C 确实能跑 400kHz 甚至 1MHz，而软件 I2C 受 CPU 翻转速度和延时函数影响，通常只能稳定跑几十到一两百 kHz。但如果你只是在初始化时写几行配置寄存器，速度差异根本无关紧要。反过来，如果你要高频持续读写大块数据，软件 I2C 会把 CPU 占用压满，这时候就该果断换硬件 I2C。

5.2 一个不需要反复重爬的 I2C 抽象层（含代码）

经历了硬件和软件两种 I2C 来回切换的折腾，我现在的主力做法是给驱动代码加一层很薄的抽象接口，把“底层用的是硬件外设还是 GPIO 模拟”彻底隔开。上层模块比如 OLED 驱动、传感器驱动，只认一个自定义的 I2C 读写函数，具体底层在初始化时注册进去。

下面是简化后的接口定义：

typedef struct { void (*init)(void); int (*write_reg)(uint8_t dev_addr, uint8_t reg_addr, const uint8_t *data, uint16_t len); int (*read_reg)(uint8_t dev_addr, uint8_t reg_addr, uint8_t *data, uint16_t len); } i2c_bus_t; extern const i2c_bus_t i2c_hal_bus; // 硬件 I2C 后端 extern const i2c_bus_t i2c_gpio_bus; // 软件 I2C 后端 // 在应用启动时选择后端 const i2c_bus_t *g_i2c = &i2c_hal_bus; // 或改成 &i2c_gpio_bus void oled_write_command(uint8_t cmd) { uint8_t buf[1] = {cmd}; g_i2c->write_reg(OLED_ADDR, 0x00, buf, 1); }

硬件后端里，write_reg 直接调用 HAL_I2C_Mem_Write；软件后端里，write_reg 内部先发送起始条件，写入设备地址和寄存器地址，再逐字节发送数据。上层 OLED 代码完全不知道底层是谁，换总线就只是改一行 g_i2c 指针的事情。

这套抽象层最大的价值，是让我在原型阶段先用软件 I2C 快速跑通逻辑，等硬件 I2C 外设调试稳定后再切换过去，而不需要改动任何上层业务代码。反过来，如果量产时引脚资源紧张，从硬件 I2C 切到软件 I2C 也只是换一个后端实现，排查范围被限制在 GPIO 初始化函数和延时配置上。

当然，抽象层也要注意安全。每个后端的 read_reg 和 write_reg 都必须有超时机制，并且要向上返回成功或失败。上层拿到失败后可以做重试，而不是傻等或者读取脏数据。我具体实现时统一了错误码，比如 0 表示成功，-1 表示超时，-2 表示从机 NACK。这个约定让两种后端的差异在上层看来完全透明。

5.3 最后两条底线

到底谁更坑，我不打算给你一个绝对的结论，因为不同项目环境里结论会变。但有一个底线我是确定的：无论是硬件 I2C 还是软件 I2C，一旦你在驱动里写了不带超时上限的忙等循环，就一定会被某个奇怪的从机行为卡死。

第二条底线是：不要试图在中断服务函数里完整执行 I2C 通信，尤其是软件 I2C。中断里的 I2C 一旦和主循环共用同一条总线，你会发现两个上下文互相踩，现象千奇百怪。把 I2C 通信放到主循环或专用线程里，用标志位和互斥量去协调，比手动维护一整套中断级可重入驱动要省心得多。

这几天同时调试 AS5600 和 OLED 的经历，让我对 I2C 这件事又加深了一层理解：每条总线协议都不复杂，复杂的是把协议放到一个随时有中断、有时序要求、有功耗限制的真实系统里。硬件 I2C 和软件 I2C 的争论还会继续，但只要你手里握着超时机制、总线恢复代码和一层干净的抽象接口，无论哪条路都能走得通。