Searching \ for '[PIC][EE] Non-compliant I2C Master (DVD Players)' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/i2cs.htm?key=i2c
Search entire site for: '[EE] Non-compliant I2C Master (DVD Players)'.

Exact match. Not showing close matches.
PICList Thread
'[PIC][EE] Non-compliant I2C Master (DVD Players)'
2007\03\14@183054 by Steve Rapinchuk

flavicon
face
I am working on a project for a client that involves the I2C portion of an
HDMI interface. It is essentially an I2C extender, which goes between an
HDMI source (DVD player) and sink (TV). This I2C interface is a superset of
that which is in every computer graphics card (source) and monitor (sink).
I am using a PIC18F with two separate I2C busses: one as a I2C slave (DVD
player is master), and the other as an I2C master (TV is I2C slave):

DVD Player <=I2C1=> PIC18F <=I2C2=> TV

Every time the DVD player does an I2C "write" operation, my code does the
following:

1. Stretch the I2C1 clock (hold the clock low) after the 8th clock.
2. Write the byte to the TV via I2C2.
3. Read the TV's acknowledge bit on I2C2.
4. Set the value of the TV's acknowledge bit on the data line of I2C1.
5. Release the clock so the DVD player can clock in the acknowledge bit.

I've tried this with 13 different DVD players from 12 different
manufacturers. This works great with most of the DVD players, but the
problem is that about a third (5 of 13) of them don't allow 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.) The HDMI spec
mentions clock stretching, but doesn't give any specifics, and simply
refers you to the I2C spec. The interesting thing is that I tried out my
code against a HDMI Compliance Tester, and it passed. The DVD players that
don't allow clock stretching all pass the compliance tester as well. To me
that's a problem with the compliance tester, so I'm in the process of
contacting the vendor to correct that, but I'm not holding my breath.

Has anyone seen other non-compliant master I2C devices that don't allow
clock stretching?


- Steve Rapinchuk

2007\03\14@185857 by peter green

flavicon
face


{Quote hidden}

"On the byte level, a device may be able to receive bytes of
data at a fast rate, but needs more time to store a received
byte or prepare another byte to be transmitted. Slaves can
then hold the SCL line LOW after reception and
acknowledgment of a byte to force the master into a wait
state until the slave is ready for the next byte transfer in a
type of handshake procedure (see Fig.6)."

"On the bit level, a device such as a microcontroller with or
without limited hardware for the I2C-bus, can slow down
the bus clock by extending each clock LOW period. The
speed of any master is thereby adapted to the internal
operating rate of this device."

apart from the restriction for hs mode the document doesn't seem to restrict in any way when a slave can do this.

> (The master I2C peripherals in PICs seem to let you
> stretch the clock at any time after the clock goes low.) The HDMI spec
> mentions clock stretching, but doesn't give any specifics, and simply
> refers you to the I2C spec. The interesting thing is that I tried out my
> code against a HDMI Compliance Tester, and it passed. The DVD
> players that
> don't allow clock stretching all pass the compliance tester as
> well. To me
> that's a problem with the compliance tester, so I'm in the process of
> contacting the vendor to correct that, but I'm not holding my breath.
Whatever behaviour is correct the fact is that there seem to be a lot of DVD players without support for clock stretching so it seems like you will have to make your go between more intelligent.

> Has anyone seen other non-compliant master I2C devices that don't allow
> clock stretching?
well i implemented one on a fpga recently ;)

i'd imagine pretty well any software bit banged master is unlikly to properly support clock stretching, so probablly are most masters that are not designed to do multi-master.

full support of clock stretching is pretty much essential for multi-master support.



2007\03\15@031308 by Andrew Warren

face
flavicon
face
Steve Rapinchuk <.....piclistKILLspamspam.....mit.edu> 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 - EraseMEfastfwdspam_OUTspamTakeThisOuTix.netcom.com

2007\03\15@032146 by Andrew Warren

face
flavicon
face
peter green <piclistspamspam_OUTmit.edu> wrote:

> i'd imagine pretty well any software bit banged master is unlikly
> to properly support clock stretching, so probablly are most masters
> that are not designed to do multi-master.

Peter:

Although many software I2C masters DON'T support clock stretching,
I'm sure you know that there's usually no good reason that they
CAN'T... All you have to do is replace this every time it appears:  

   Make SCL a high-impedance input

with this:

   Make SCL a high-impedance input
   Wait for the SCL pin to go high

If you want, you can add a timeout (or wrap a watchdog timer around
the whole thing), although of course it won't be strictly compliant
if you do.  

-Andy

=== Andrew Warren - @spam@fastfwdKILLspamspamix.netcom.com

2007\03\15@072356 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: KILLspampiclist-bouncesKILLspamspammit.edu [RemoveMEpiclist-bouncesTakeThisOuTspammit.edu]
>On Behalf Of Steve Rapinchuk
>Sent: 14 March 2007 23:32
>To: spamBeGonepiclistspamBeGonespammit.edu
>Subject: [PIC][EE] Non-compliant I2C Master (DVD Players)
>
>
>I am working on a project for a client that involves the I2C
>portion of an
>HDMI interface. It is essentially an I2C extender, which goes
>between an
>HDMI source (DVD player) and sink (TV).

Does you extender have to "launder" the I2C packets in any way e.g. replace certain bytes etc?  If not, then can you not use a hardware extender such as the Philips P82B715?

As Andy says, there are many firmware based master I2C implementations that do not support clock stretching which is fine when the peripherals (e.g. EEPROM) are soldered onto the same board as your micro and you know it works, but clearly very poor practice if you have to interface with other manufacturers products, and pretty much negligent if you have to comply with a published specifiation.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2007\03\20@115807 by Steve Rapinchuk

flavicon
face
peter green wrote:
>"On the byte level, a device may be able to receive bytes of
>data at a fast rate, but needs more time to store a received
>byte or prepare another byte to be transmitted. Slaves can
>then hold the SCL line LOW after reception and
>acknowledgment of a byte to force the master into a wait
>state until the slave is ready for the next byte transfer in a
>type of handshake procedure (see Fig.6)."
>
>"On the bit level, a device such as a microcontroller with or
>without limited hardware for the I2C-bus, can slow down
>the bus clock by extending each clock LOW period. The
>speed of any master is thereby adapted to the internal
>operating rate of this device."
>
>apart from the restriction for hs mode the document doesn't seem to
>restrict in any way when a slave can do this.

Thanks for pointing that out. I don't know how I missed that in the
I2C spec. That made me go over the HDMI spec again, and I found the
following in section 8.4.1 Timing:

"Note that an HDMI Sink may hold off the DDC transaction by
stretching the SCL line during the
SCL-low period following the Acknowledge bit as permitted by the I2C
specification. All HDMI
Sources shall delay the DDC transaction while the SCL line is being held low."

Although the I2C spec says clock stretching can be done on any bit,
the HDMI spec states it can be done after the acknowledge. In my
experience, if I2C masters don't allow clock stretching on the bit
level, they don't allow it after the acknowledge bit either. (Five of
the 13 DVD players I've tested don't allow clock stretching, neither
on the bit or byte level.) The funny thing is that one of the
non-compliant DVD players is made by Philips, the company that
invented I2C and wrote the spec!

-Steve Rapinchuk

2007\03\20@124803 by Steve Rapinchuk

flavicon
face
Michael Rigby-Jones wrote:
>Does you extender have to "launder" the I2C packets in any way e.g.
>replace certain bytes etc?  If not, then can you not use a hardware
>extender such as the Philips P82B715?

No, but that's not an option since the final product is a very
loooooong HDMI cable with two PICs in it, and there's no metal [ie.
no wires] in the loooooong section between the PICs.


-Steve Rapinchuk

2007\03\20@125125 by Steve Rapinchuk

flavicon
face
Andrew Warren wrote:
>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

Actually, I've had to resort to something like that. On startup, I have to
poll all the I2C devices on the TV (typically 0x74 and 0xA0), read
and buffer all the data at those slave address (typically <512 bytes),
and then ACK any transfers that read/write to those slave devices.
I ACK every byte that's written (Although I've only used three different
TVs so far, none of them NAK the last byte.) I have to continually re-read
and buffer those data areas that can change. Fortunately this is limited to
a few bytes of HDCP info (DRM crap).

If anyone is interested, you can learn more about HDMI here:

http://en.wikipedia.org/wiki/Hdmi


-Steve Rapinchuk

2007\03\20@131655 by Alan B. Pearce

face picon face
>If anyone is interested, you can learn more about HDMI here:
>
> http://en.wikipedia.org/wiki/Hdmi

I guess in the furore of what Vista is doing with HDMI non-compliant
monitors, it will get read many times, and become a prime source of hacking
info ...

2007\03\20@132248 by alan smith

picon face
optical then?

Steve Rapinchuk <TakeThisOuTsteveEraseMEspamspam_OUToakvalley.com> wrote:  Michael Rigby-Jones wrote:
>Does you extender have to "launder" the I2C packets in any way e.g.
>replace certain bytes etc? If not, then can you not use a hardware
>extender such as the Philips P82B715?

No, but that's not an option since the final product is a very
loooooong HDMI cable with two PICs in it, and there's no metal [ie.
no wires] in the loooooong section between the PICs.


-Steve Rapinchuk

2007\03\20@144346 by Steve Rapinchuk

flavicon
face

Alan B. Pearce  wrote:
> >If anyone is interested, you can learn more about HDMI here:
> >
> > <http://en.wikipedia.org/wiki/Hdmi>http://en.wikipedia.org/wiki/Hdmi
>
>I guess in the furore of what Vista is doing with HDMI non-compliant
>monitors, it will get read many times, and become a prime source of hacking
>info ...


Yup, HDCP encryption has already been broken:

http://en.wikipedia.org/wiki/High-bandwidth_Digital_Content_Protection


-Steve Rapinchuk  

2007\03\20@144720 by Steve Rapinchuk

flavicon
face
Alan B. Pearce  wrote:
>optical then?
>
>Steve Rapinchuk
><<RemoveMEsteveTakeThisOuTspamTakeThisOuToakvalley.com>steveoakvalley.com>
>wrote:  Michael Rigby-Jones wrote:
> >Does you extender have to "launder" the I2C packets in any way e.g.
> >replace certain bytes etc? If not, then can you not use a hardware
> >extender such as the Philips P82B715?
>
>No, but that's not an option since the final product is a very
>loooooong HDMI cable with two PICs in it, and there's no metal [ie.
>no wires] in the loooooong section between the PICs.
>
>
>-Steve Rapinchuk


Um, yes. (I had to check with my client to make sure I wasn't
breaking the NDA. Turns out they've already announced they are
working on such a product.)


-Steve Rapinchuk  

2007\03\20@152341 by alan smith

picon face
welll...if not copper.....has to be optical since I wouldnt think RF would be too pratical. 10G optical is getting cheaper by the month it seems

Steve Rapinchuk <steveEraseMEspam.....oakvalley.com> wrote:  Alan B. Pearce wrote:
>optical then?
>
>Steve Rapinchuk
><steveoakvalley.com>
>wrote: Michael Rigby-Jones wrote:
> >Does you extender have to "launder" the I2C packets in any way e.g.
> >replace certain bytes etc? If not, then can you not use a hardware
> >extender such as the Philips P82B715?
>
>No, but that's not an option since the final product is a very
>loooooong HDMI cable with two PICs in it, and there's no metal [ie.
>no wires] in the loooooong section between the PICs.
>
>
>-Steve Rapinchuk


Um, yes. (I had to check with my client to make sure I wasn't
breaking the NDA. Turns out they've already announced they are
working on such a product.)


-Steve Rapinchuk

2007\03\21@102704 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: EraseMEpiclist-bouncesspammit.edu [RemoveMEpiclist-bouncesEraseMEspamEraseMEmit.edu]
>On Behalf Of alan smith
>Sent: 20 March 2007 19:23
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC][EE] Non-compliant I2C Master (DVD Players)
>
>
>welll...if not copper.....has to be optical

He might have had a pneumatic or hydraulic system :D

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...