>>hang on a minute. Are you really telling us that the code in >>Microchip Application Note AN734 doesn't work? > >I am saying that it does not work reliably (i.e. on every >occurence) in my context, that is as an assembler routine >inserted in my Basic application, with use of preamble and >postamble routines to the effect of saving and restoring the >PIC's registers and the compiler internal variables. OK, this is more info than you have given up till now. If you had said this at the start, you may have even avoided most of Olin's diatribe. >>I used this code to make my interrupt driven I2C slave module quite satisfactorily. > >This information is valuable indeed, because it seems to >show that the logics are OK (they seem to be when analysed >with the PIC's reference book as a bible) and work for some >people in some contexts. > >Would you care indicate whether yours was a large >application (how busy the PIC was when not managing i2c), >and whether the i2c was managed in the program's main loop >or as a real interrupt service routine? It is done as a real interrupt service routine that puts the received bytes into a FIFO buffer. The code is exactly as in the application note with two modifications, one to correct the error that Bob reports below, and the other to handle a status byte that I wanted the master to be able to poll, and is handled totally within the interrupt routine without dropping out to background code. ... >I have found this message a long time ago and taken note >that some people had had problems running that AN734 code >until it apparently was corrected. The message (by Bob >Blick) says this: ... >The sample works except when you read from the slave. In the >example they forgot to set CKP after the slave is done >transmitting. > >?Cheers, Bob >*** > >Apparently , a "CKP = 1" instruction, or rather, in >assembler, > > bsf SSPCON,CKP ; Release the clock. > >was missing. > >Problem is this instruction is present in the "Doi2cWrite" >sub, which is called every time the slave is read by the >master (states 3 and 4). So my question is "where is (or >was) that instruction missing?". > >Also, if it is not missing in the version I have, why does >it basically work, but unreliably? > >More mysteries... I suspect that the unreliability is for the reason that Bob states. I took Bobs statement literally, and put the instruction you note in the code that handles the end of transmission situation, where the one you are looking at is in the middle of the message handling. Just looking through the code I have, it looks like it goes at the beginning of I2CErr, where the NOP instruction is. If this does not fix the code I will send you my code, but it is a module designed around Olin's development environment, so is a linkable module. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads