Date: Tue, 10 Oct 2017 20:27:10 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Ian Lepore <ian@FreeBSD.org>, src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r323465 - head/usr.sbin/i2c Message-ID: <4f91a38d-4de8-b6a7-1076-4f6c200708fe@FreeBSD.org> In-Reply-To: <1507655033.84167.54.camel@freebsd.org> References: <201709112149.v8BLncAs049328@repo.freebsd.org> <4c4a916f-9960-6d7f-3389-37b998ba980b@FreeBSD.org> <1507651963.84167.37.camel@freebsd.org> <230cbbbf-9d98-2249-e0db-488b4a3abfb3@FreeBSD.org> <1507655033.84167.54.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4f91a38d-4de8-b6a7-1076-4f6c200708fe>