On Sat, Jul 10, 2010 at 4:55 AM, Olin Lathrop wrote: > Barry Gershenfeld wrote: > > The problem then was, I would get one interrupt (when the slave saw > > its address) and then nothing afterward. > > What did you expect? You only addressed the slave once, so got one > interrupt. > I wasn't clear on this, but the scanning cycle was set up to repeat itself after 100 ms. So the slave got addressed periodically. I expected "something"; either another interrupt, or an error indication. > > Turns out, I have to read the "received byte". > > Of course, especially with slaves that do clock stretching. How else would > the hardware know you got it and it was OK to proceed? Clock stretching is intended for data reads only. But this was a poll. The only exchange of practical information that happens is, the master sees an ACK, revealing the presence of a device at that address. I'm pretty sure > other IIC implementations work similarly, although I often do IIC in > firmware. It's one of the first things to give up in hardware if you need > the dedicated pins for something else. If I remember right, your PIC has > remappable pins, so that's less of a issue. > We have been bit-banging IIC all along (via the CCS compiler or by my own hand). But when you want a PIC as a slave, then the hardware engine makes the most sense. (Studiously avoiding saying "required" but probably close enough in an application that has the slave plus other things to do.) Barry -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist