After the 8th bit, the EEPROM should pull the data line low for an ACK or leave it high for NACK. The IIC bus must be pulled high with resistors (1k or 10k depending on how fast you want to go) and the PIC must only drive low (not drive high) .. open-drain outputs are ideal for this but you can achieve the same effect by seting the PORT bits low and using the TRIS bits to drive the line low or let the resistors pull it high. I have code for a 17C756 talking to a 24C64 here: http://kdsl32.dnvr.uswest.net/cgi-bin/tl.exe/AERC/poscalc/eeprom.asm It is commented .. I think pretty well but I haven't gotten anyone else's opinions yet. The port initializations (after reset) are here: http://kdsl32.dnvr.uswest.net/cgi-bin/tl.exe/AERC/poscalc/init1.asm Note that RA2 and RA3 are open-drain outputs on the 17C756, specifically designed for IIC or similar applications. On a normal output you would simply program the PORT bit low and toggle the TRIS bit in the same manner as the PORT bits are toggled in my 17C756 code. Hope this helps, Ken >Yes, I've checked the archives, still uncertain, and reluctant to ask. >Trying initially to get an F84 to talk to a 24LC65 but have other I2C >ICs in the wings. No problem with start bits or bytes but have run >into difficulty over the 9th clock pulse. > >I have the Philips guide to I2C as well as AN515 (are the sub >headings mixed up BTW ?) and Nicole Ambrose's program from >the archives. Unfortunately everything else relating to I2C at the >archives seems to be unavailable. > >I'm uncertain because every sample of code I look at seems to be >using a different method at the 9th pulse to determine Ack. I won't >go into details but suffice to say I'm confused. Part of the reason is >sparse commenting on code, but we've been there before haven't >we. Notes like "move FF into the accumulator" after movlw 0ffh >aren't particularly helpful. Plenty of what-it-does but hardly any why- >it-does-it. > >OK, what I'd like to know specifically is - after the 8th data bit has >been clocked into the EEPROM, do you change the PIC SDA to >an i/p to test Ack or can you just send a "dummy" 9th pulse out, >and assume on a single-memory bus that Ack has been generated ? >Nowhere have I seen an explicit direction to change SDA direction >at Ack testing time and can't tell whether there's an implied one. > >Can someone take a minute to give a blow-by-blow, doesn't even >have to be code, about I2C procedure please. > >Jinx