The "other devices" are soldered to the same PCB that the I2C bus comes off of. It would not be trivial to "remove" them. My code includes this:
struct bme280_dev dev;
int8_t rslt = BME280_OK;
uint8_t dev_addr = BME280_I2C_ADDR_PRIM;
dev.intf_ptr = &dev_addr;
dev.intf = BME280_I2C_INTF;
dev.read = user_i2c_read;
dev.write = user_i2c_write;
dev.delay_ms = user_delay_ms;
rslt = bme280_init(&dev);
Albeit I think I actually changed the name from dev to bme280_dev. I believe this should be accessing 0x76. Based on looking at the website I referenced earlier, it is likely that the BME280 is configured for 0x76, although it's always possible it's 0x77. Honestly, looking through the bme280_init code, a lot of it really doesn't make sense. It's nothing like the other I2C device accesses I've used. I'm used to opening a file descriptor first, and I don't see that anywhere. Within the bme280_get_regs we have:
dev->intf_rslt = dev->read(reg_addr, reg_data, len, dev->intf_ptr);
That's pretty weird, since it looks like read is a function, but the reference seems to be using it as a variable within a structure pointed to by dev. But this is C, not C++, so... why would a function be inside a structure? Where is this defined? Why no file decriptor, etc? Why assign a pointer (dev.intf_ptr) to a variable that stores the address, why not just store the address since presumably you are just using it to open the file descriptor? Or maybe not. Like I said, I'm really confused about this code.
Regardles... was my expectation that I2C writes should work, and that I2C reads should be the logical AND of the two device outputs if multiple devices share an I2C bus address? Again, I want to emphasize that my ability to debug this is limited. I am located in the US, and my friend is in Germany.
