ADB was pretty solid. A shared-single-wire bus that allows multiple slaves by including an address in the message... but includes a protocol-level reset that's used regularly, so a missed single bit doesn't jam things up unrecoverably. When I think of how many fewer hours of my life I would have wasted had I2C learned this lesson...
The I2C protocol is a distributed state machine. Each slave node needs to know what bit in the message sequence is being sent, to match it against its own address. As a result, a single missed bit results in a slave not recognizing its own address and going dark -- or, worse but rarer, potentially recognizing its address in the midst of data sent to another slave, and responding inappropriately. Observing this in a real system indicates either a signal integrity issue or a bug, but signal integrity issues do happen, and this non-recoverable behavior is somewhat unique to I2C, and somewhat cursed, turning what would be a transient error into a permanent one. In practice, most I2C devices have some mechanism for recovering (sufficiently long pulse on clock line, so many clock edges all low, a dedicated reset pin); and for the few that don't, forcing a reset of the device through a high-side drive or similar works fine; but the fact that these mechanisms are outside of the protocol, rather than inside it, is also cursed, and means that for an I2C bus of mixed devices there's not guaranteed to be a single method acceptable to all of them.
ADB was pretty solid. A shared-single-wire bus that allows multiple slaves by including an address in the message... but includes a protocol-level reset that's used regularly, so a missed single bit doesn't jam things up unrecoverably. When I think of how many fewer hours of my life I would have wasted had I2C learned this lesson...
Oh is that why I2C seems to just hang/break whenever I use it for a DIY project? Does everyone just reset the bus all the time?
The I2C protocol is a distributed state machine. Each slave node needs to know what bit in the message sequence is being sent, to match it against its own address. As a result, a single missed bit results in a slave not recognizing its own address and going dark -- or, worse but rarer, potentially recognizing its address in the midst of data sent to another slave, and responding inappropriately. Observing this in a real system indicates either a signal integrity issue or a bug, but signal integrity issues do happen, and this non-recoverable behavior is somewhat unique to I2C, and somewhat cursed, turning what would be a transient error into a permanent one. In practice, most I2C devices have some mechanism for recovering (sufficiently long pulse on clock line, so many clock edges all low, a dedicated reset pin); and for the few that don't, forcing a reset of the device through a high-side drive or similar works fine; but the fact that these mechanisms are outside of the protocol, rather than inside it, is also cursed, and means that for an I2C bus of mixed devices there's not guaranteed to be a single method acceptable to all of them.
Yes, but every device is slightly different and sometimes you need obnoxious hacks to even detect that there is a problem at all...
As the author mentions doing it, a note regarding retrobright: it seems to cause faster yellowing than not using it. https://youtu.be/_n_WpjseCXA
Maybe just let your items show their age.