I2C设备访问失败主因是权限不足或路径错误，需配置udev规则并加入i2c组；读寄存器优先用i2c_smbus_read_byte_data()（SMBus兼容场景），否则用I2C_RDWR；注意地址左移、上拉电阻、时钟频率及硬件冲突。
Linux下用C++打开I2C设备文件失败：/dev/i2c-X 权限或路径不对
直接 open(/dev/i2c-1) 返回 -1 并报 Permission denied，不是代码写错了，是权限没配。Linux把I2C总线设备当作普通字符设备管理，普通用户默认无权访问。
- 先确认设备存在：
ls /dev/i2c*，常见是/dev/i2c-0或/dev/i2c-1，数字取决于板子DTS配置 - 临时测试可加sudo，但生产环境必须改udev规则：新建
/etc/udev/rules.d/99-i2c.rules，内容为KERNEL=="i2c-[0-9]*", GROUP="i2c", MODE="0660" - 然后执行
sudo groupadd i2c && sudo usermod -a -G i2c $USER，登出重进生效 - 别硬编码
/dev/i2c-1—— 有些ARM平台（如树莓派CM4）可能映射到/dev/i2c-10，建议从/sys/class/i2c-dev/下枚举真实路径
i2c_smbus_read_byte_data() 和 ioctl(I2C_RDWR) 的选择困境
读寄存器时该用哪个？i2c_smbus_read_byte_data() 看起来简单，但底层依赖内核i2c-dev驱动的SMBus封装，不支持所有设备；ioctl(fd, I2C_RDWR, ...) 更底层、更灵活，也更易出错。
- 如果设备手册明确说“兼容SMBus”，且只读单字节/字/块（≤32字节），优先用
i2c_smbus_read_byte_data()—— 它自动处理地址位移、ACK/NACK、重复起始等细节 - 遇到非标准协议（比如需要发送两个字节地址再读）、大于32字节数据、或返回值异常（如返回负数但errno没变），立刻切到
I2C_RDWR模式 -
I2C_RDWR要自己构造i2c_msg数组：写消息（ADDR|WRITE）和读消息（ADDR|READ）必须分两条，中间不能穿插sleep —— 内核会合并成标准的“write-then-read”时序 - 注意：某些老内核（I2C_RDWR 的msg.len=0支持不稳，读操作前务必确保写消息至少发1字节地址
用C++封装I2C通信时，RAII没管好fd导致设备句柄泄露
写个 I2cDevice 类，构造函数里 open()，析构函数里 close()，看似稳妥，但实际常在异常路径或提前return时漏关fd。
- 别手写析构逻辑 —— 直接用
std::unique_ptr+ 自定义deleter：auto fd = std::unique_ptr<int void>(new int(open(path, O_RDWR)), [](int* p) { if (*p >= 0) close(*p); delete p; });</int> - 更推荐用
std::optional<int>存fd，配合作用域结束自动析构，比裸指针更直观 - 千万别把fd传给其他线程后还在原线程close —— I2C总线是共享资源，多线程并发访问必须加互斥锁，且锁粒度要覆盖整个读写事务（不是只锁fd操作）
- 实测发现：某些I2C适配器（如i2c-bcm2835）在close()后立刻reopen，可能触发内核状态残留，建议两次open之间间隔至少1ms
读到全0或固定值？检查从机地址、上拉电阻和时钟频率
代码编译运行无报错，但 i2c_smbus_read_byte_data(fd, reg) 总返回0或-1，大概率不是软件问题。
立即学习“C++免费学习笔记（深入）”；
- 用
i2cdetect -y 1确认设备是否在线 —— 如果地址格子是--，说明硬件没响应；显示具体地址（如40）但读不到数据，再查软件 - 地址要左移1位！
i2c_smbus_read_byte_data()的第一个参数是7位地址（如0x40），内核会自动左移补R/W位；别传0x80这种已含方向位的值 - 示波器量SCL/SDA：空闲时是否为高电平？若常低，上拉电阻缺失或阻值过大（建议4.7kΩ）；若波形畸变、上升沿缓慢，可能是走线太长或负载过重
- Linux默认I2C时钟是100kHz，某些传感器（如BME280）要求400kHz，需改设备树里的
i2c@... { clock-frequency = <400000>; }并重启，用户态无法动态调速
最麻烦的是地址冲突和时序容差——同一总线上两个0x40设备，或者从机对SMBus Block Read的ACK时序敏感，这些没法靠改代码绕过，得动硬件或换器件。
