Problem is: every i2c transaction is a READ or a WRITE. The spec is mum on the semantics of what that means. Some devices will get into a weird state or irrevocably pop data off a FIFO if you READ them (eg: some IMUs). Others take a WRITE, even with no data, to have a non-idempotent meaning (eg: SMBUS). Some devices will not even ACK their address on a READ request unless it is preceded by a write and a RESTART. Basically there is no safe way to scan an i2c bus and be sure you did not modify some state or put some device into some weird state.
Right. But if you have a finite space of possible i2c devices it's not quite that bad. You can scan for known addresses and there are frequently mitigations for clogging FIFOs - like clocking out the bus or forcing a reset - that you might have to do anyway, depending on what your failure modes for power sequencing are. i2c is just fine when it works, but there are reasons why it can be worth spending the extra pins for SPI.
The post I was replying to was suggesting scanning the bus for any kind of device. That is impossible. I could make a i2c device right now and not tell you how it works. You will have no way to scan for it safely (say I specify that unless the first access to it is a write of 0x55 0xAA, it’ll not talk again, but if it is, the byte sent after 0xAA becomes its i2c address)
I have seen devices that respond to address zero, which is against the spec. Stopped nobody.
I have seen devices that use the bus arbitration meant for multi-master during a READ to allow only one of them to win after responding to a zero-address read.
I’ve used an i2c device that had an additional chip select line for some reason. Unless you lowered that, it would not respond to any traffic on the bus.
You cannot even imagine the fucked up shit that happens over i2c
There is no safe, generic way to scan an i2c bus. If the world of possible devices is limited, it may be possible. But there is no safe generic way.
