4 ms·
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 f
by buescher 2y ago
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.
- dmitrygr 2y agoThe 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.
- buescher 2y agoOh yes. I do not have to imagine. That's why I said "Right".