c++ 不能直接操作 i2c 总线，需通过 linux 的 ioctl + /dev/i2c-* 设备文件实现；须 root 权限或加入 i2c 用户组；地址需左移一位（如 0x48 → 0x90）；核心调用为 ioctl(fd, i2c_rdwr, &msg)。
C++ 本身不直接操作 I2C 总线——得靠系统接口或硬件抽象库，硬写驱动会掉进内核/权限/时序坑里。
Linux 下用 ioctl + /dev/i2c- 设备文件是最常用路径
Linux 内核把 I2C 总线抽象成字符设备（如 /dev/i2c-1），C++ 程序通过 open()、ioctl() 和 i2c_msg 结构体发读写请求。这不是 C++ 标准功能，而是 Linux 系统调用的封装。
- 必须用
root权限或把用户加进i2c用户组，否则open()返回-1，errno是EACCES -
ioctl(fd, I2C_RDWR, &msg)是核心调用，不能用read()/write()直接读写设备文件——那样会报EINVAL - 地址要左移一位（7 位地址转 8 位），比如传感器地址 0x48，实际传
0x48 或 <code>0x90（写）/0x91（读） - 别忘了先用
ioctl(fd, I2C_SLAVE, addr)设置从机地址，否则I2C_RDWR会失败
用 libi2c 库比裸 ioctl 少踩三类坑
libi2c（来自 i2c-tools）把底层细节包了一层，接口更稳，尤其适合快速验证传感器通信。
- 初始化用
i2c_open_bus("/dev/i2c-1")，比手动open()+ioctl(I2C_SLAVE)少两步出错机会 - 读写函数如
i2c_smbus_read_byte_data()自动处理寄存器地址+数据格式，不用自己拼i2c_msg数组 - 返回值直接是数据或负数错误码（如
-EIO表示无应答），比判断ioctl返回值 +errno更直观 - 注意：它默认用 SMBus 协议子集，某些非标准 I2C 设备（比如需要重复起始条件的）可能不兼容
别在 C++ 里用 wiringPi 或 BCM2835 库操作树莓派 I2C
这两个库设计目标是 GPIO 模拟时序，I2C 只是附带支持；它们绕过内核 I2C 子系统，直接操作寄存器，后果很实在：
立即学习“C++免费学习笔记（深入）”；
- 和内核驱动（如
i2c-bcm2835）抢总线，大概率触发clock stretching timeout或NACK - 无法使用
i2cdetect、i2cdump等调试工具，问题定位变黑盒 - 树莓派 OS 更新后寄存器映射可能变化，程序某天突然失联，查日志只看到
Bus error - 真要控制底层时序（比如某些老式传感器要求特定 SCL 高低电平时间），应该改内核驱动或用 FPGA，不是靠用户态轮询
跨平台？别硬搞，优先选 Rust 或 Python 胶水层
C++ 的跨平台 I2C 抽象几乎不存在。Windows 没原生 I2C 设备节点，macOS 不开放硬件总线，嵌入式裸机又没 libc。强行封装只会让代码变成条件编译地狱。
- 如果项目真要多平台，建议 C++ 只做算法/业务逻辑，I2C 通信交给 Python（用
smbus2）或 Rust（用linux-embedded-hal）跑在宿主机或 MCU 上 - 传感器协议解析（如 BME280 的温度补偿公式）完全可以抽成头文件，C++ 和 Rust 共用同一套
constexpr计算逻辑 - 最常被忽略的一点：I2C 电气特性（上拉电阻值、线长、容性负载）比软件逻辑更容易导致通信失败，示波器看波形比加一百个
printf有用得多
