结论：应采用I2CBus+DeviceDriver两级封装，而非统一I2CDevice类；因I2C是总线协议，不同外设（如AT24C02、MPU6050、SSD1306）地址格式、读写时序、控制逻辑差异极大，强行统一导致维护成本激增。
直接说结论：别封装成“万能类”，先按硬件抽象层（HAL）+ 地址/寄存器语义分层，否则后期一加传感器就崩。
为什么不能写一个 I2CDevice 类统一 handle 所有外设
因为 I2C 是总线，不是设备协议。同一根 SDA/SCL 上挂的 AT24C02（EEPROM）、MPU6050（IMU）、SSD1306（OLED）三者行为差异极大：
-
AT24C02写数据要先发 16 位地址，再发数据；读时可能需要“伪写”地址再发重复起始 -
MPU6050寄存器是 8 位地址，但某些配置需连续读多字节且自动递增地址 -
SSD1306带命令/数据切换引脚（DC），I2C 通信前还得拉低 DC 发命令、拉高 DC 发像素数据——这已超出纯 I2C 协议范畴
强行用一个 I2CDevice::read_reg(uint8_t reg, uint8_t* buf, size_t len) 接口去适配，等于把硬件差异全塞进 if-else 或虚函数表里，维护成本爆炸。
推荐结构：I2CBus + DeviceDriver 两级封装
核心思路是分离“物理传输”和“设备语义”：
立即学习“C++免费学习笔记（深入）”；
-
I2CBus类只管底层收发：i2c_master_send/i2c_master_recv调用、错误重试、超时控制、总线仲裁等待——不碰任何寄存器名或地址长度 - 每个外设单独写
AT24C02Driver、MPU6050Driver，在构造时传入I2CBus&引用，内部自己处理地址格式、页写逻辑、状态轮询等
示例片段（Linux kernel 风格简化）：
class I2CBus {
public:
explicit I2CBus(int bus_fd) : fd_(bus_fd) {}
int write(uint8_t addr, const uint8_t* buf, size_t len);
int read(uint8_t addr, uint8_t* buf, size_t len);
private:
int fd_;
};
<p>class AT24C02Driver {
public:
AT24C02Driver(I2CBus& bus, uint8<em>t addr = 0x50) : bus</em>(bus), addr_(addr) {}
int write_page(uint16_t eeprom_addr, const uint8_t<em> data, size_t len);
int read_bytes(uint16_t eeprom_addr, uint8_t</em> buf, size<em>t len);
private:
I2CBus& bus</em>;
uint8<em>t addr</em>;
};这样改一个传感器驱动，完全不影响其他设备代码，也不用动总线层。
容易踩的坑：地址位宽、ACK/NACK 时机、时序容忍度
这些细节藏在芯片手册里，但 C++ 封装时若忽略，运行时就会静默失败：
- 7 位 vs 10 位地址：
i2c_msg.addr字段填的是左移 1 位后的值（即 7 位地址 I2C_M_TEN 标志 - 有些器件（如
PCA9685）在写完寄存器地址后，要求立刻发 STOP，再发 START+READ，不能连发；而ADXL345支持连续读，靠从机自动递增地址 - STM32 HAL 库的
HAL_I2C_Master_Transmit默认带 STOP，但 Linuxi2c_transfer是原子操作，重复起始得手动拆成两次i2c_msg数组调用
所以 I2CBus::read() 接口必须暴露“是否带 STOP”、“是否重复起始”等控制参数，不能默认固定行为。
最麻烦的其实是调试阶段——示波器上看到 SDA 卡在低电平，八成是某个从机没释放总线，或者主控没发 STOP。这时候封装再漂亮也没用，得回到 i2c-tools 的 i2cdetect 和 i2cget 先确认物理连通性。硬件问题永远比 C++ 类设计优先级高。
