Tanks a lot for your clear and precious answer. -----Messaggio Originale----- Da: Barry King A: Data invio: lunedl 25 ottobre 1999 16.47 Oggetto: Re: Which is the truth on I2C-SLAVE for PIC 16C74A? > > I don't have an ack from a SLAVE micro neither when the PC is the Master > > transmitter, nor when the comunication is between micro. > > Why doesn't the PIC ack the first address byte of a I2C message?(the address > > is right) > > Doesn't the PIC make the ack by hardware? > Yes, if it is set up correctly. So if it doesn't ACK, then it ISN'T set > up right. Interrupt has nothing to do with it until the SECOND byte, if > you miss the first interrupt (from reset) the hardware will still ACK. > > > (And so if the SSP registers are configured, the interrupt enabled, and the > > proper Trisc bits set..., why no ack?) > Are you sure you are setting up the registers right? Did you > remember to switch RAM banks to write the SSPADD register? > Can you tell us what the values are in each register? TRISC, > SSPSTAT, SSPADD, SSPSTAT? Do your tools allow you to > confirm the values in the registers? These are the register values that I can see in a simulation session by Mplab: Address Symbol Value 93 SSPADD B'10100100' 14 SSPCON B'00111110' <<<<< Is This value rigth? 13 SSPBUF B'00000000' 39 SLAVE B'10100100' 03 STATUS B'00111100' 87 TRISC B'00011000' 94 SSPSTAT B'00000000 Thisi is the register image that I see when the PIC is waiting for a I2C message, and another PIC (Programmed as Master) or a PC (that trys with every possible address to catch an ack, scanning for active devices on the bus) are sending their message What do you think about it? > And you are using 7 bit addresses? yes I'm. > test just the I2C Slave receive first. Maybe just present the byte sent > to you on Port B? When you get that working, then do the same > function with interrupts. The ISR for the SSP must be careful to > detect and clear error conditions, or the bus may be locked up by > the Slave, but you are seeing no ACK, so this is not the problem. Now, I'm working to do this. And I'm waiting to obtain the use of an emulator, by which I think to see the complete real register situation of the micro during program esecution, to see where is the problem. May be that the PIC doesn't sense the START condition? Or what else?! Bye and thanks. Paolo Marras AIRLAB (Artificial Intelligence and robotics LAB) Politecnico di Milano