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 _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "[email protected]"
