svn commit: r323465 - head/usr.sbin/i2c

[Andriy Gapon]

On 10/10/2017 20:03, Ian Lepore wrote:
> This conversation is making me think harder about what's happening on
> the bus during the two different kinds of scans, and I'm realizing the
> answer is "almost exactly the same thing in both cases".
> 
> A "normal" scan is a START, followed by 9 clocks during which the slave
> address is put on the bus and either an ACK or NAK happens, followed by
> a STOP.
> 
> A new-style "read" scan is a START, followed by 9 clocks during which
> the slave address is put on the bus and either an ACK or NAK happens,
> followed by 9 more clocks for transferring a byte+NAK, followed by a
> STOP.
> 
> So the entire difference is 9 extra clocks, in terms of bus behavior.
>  Operationally, the slave device already indicated a willingness to
> service a read operation when it ACK'd its address following the start.
> 
> Actually doing the read shouldn't put the device into a bad state, but
> I guess we could theorize it might... maybe it likes to work in 16-bit
> chunks and a STOP after 8 bits confuses it.  But before the stop comes
> a NAK from the master which says "I don't want to read anymore" and if
> that confuses the device, it's violating the protocol.
> 
> All in all, I'm now wondering if what should change is removing the
> wording about the read-based scan being somehow "less reliable", I
> don't think it really is.

Well, the misbehaving devices most certainly violate the protocol, but that does
not change the fact that they exist.  For example, the PLL chip I mentioned
earlier simply listened for its slave address and then expected a fixed length
sequence of bytes to program a new frequency.  The slave even ignored the R/W
bit and intermediate start-stop bits.  It simply treated the next 8 x N bits as
the data.
I think that it was this chip or something like it:
http://pdf1.alldatasheet.com/datasheet-pdf/view/58355/CYPRESS/W48S111-14.html


-- 
Andriy Gapon