Steve Rapinchuk wrote: > about a third (5 of 13) of [DVD players] don't allow [I2C] clock > stretching. Two of those five completely ignore clock stretching, > and continue to toggle the data line up and down even though the > clock is held low. The other three DVD players seem to support > clock stretching, but only after the 9th clock. (I'm stretching > the clock between the 8th and 9th clocks.) > > The I2C spec includes clock stretching, but it doesn't explicitly > say when it is OK to do it. (The master I2C peripherals in PICs > seem to let you stretch the clock at any time after the clock goes > low.) > .... > Has anyone seen other non-compliant master I2C devices that don't > allow clock stretching? Steve: I've never seen a device with HARDWARE I2C Master functionality that didn't properly support clock-stretching, but I've seen LOTS of software bit-banged I2C masters that fail to support it. Sometimes the lack of support is just due to ignorance: People erroneously assume that if their code can interface with a serial EEPROM -- by far the most common I2C slave device, but also one of the most forgiving -- it can also reliably interface to all other I2C devices. Other times -- and I'm seeing this more and more -- the people writing I2C Master code are aware of the clock-stretching spec, but they choose not to implement it because they don't think they can do it properly: Either they simply aren't talented enough, or interrupts scare them, or timing scares them, or they don't know enough about their system, or their OS gets in the way, or the code was written by one of their vendors to talk to THEIR part and that vendor isn't about to change it just so it can talk to a competitor's part, etc. As firmware I2C becomes more common, you'll see this more and more. Unfortunately, I don't know what you can do about it. When my company's customers have non-compliant I2C Master code that won't talk to our I2C slave devices, we solve the problem by sending an engineer to Korea or Taiwan to rewrite their code... But it doesn't sound as though you're in a position to do that sort of thing, so you may have to resign yourself to the fact that your product just won't work with some DVD players. Hmm... Actually, maybe there IS something you can do. What if you always responded to the DVD player's first byte with an ACK, and thereafter responded to the DVD player's byte x with the ACK/NAK from the TV's byte x-1? If the TV ACKs every byte, everything's cool. If the TV NAKs any byte except the final one, you'll send a NAK to the DVD player soon afterward... And the DVD player probably doesn't care WHICH byte was NAKed; unless there's some complicated protocol involved in the transaction, it'll probably behave identically whether it receives the NAK at the right time or one byte late. This scheme'll only fail if the TV NAKs only the final byte, and how likely is that? Besides, a DVD player that's too dumb to support clock stretching might be so dumb that it ignores NAKs, too... So maybe the scheme won't fail even then. -Andy P.S. Clock stretching is allowed whenever the clock is low, not just after the 9th bit. === Andrew Warren - fastfwd@ix.netcom.com -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist