Post by thread:Which is the truth on I2C-SLAVE for PIC 16C74A?

Hi to all, this is my first message to the "PICLIST", first of all thanks for all. I have red many massage about the I2C-SLAVE problem for a PIC (in my case the 16C74A), I have studied the Microchip App. Note, but I now haven't a clear vision of this problem. In particoular: I'm programming a control system for a mobile exapode (a legged robot), in a thesis project. I need to make a comunication over an I2C BUS, between two PIC and a Linux PC. 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. where can I find the right informations about this particoular role (I2C-SLAVE)? Are there code examples? 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? (And so if the SSP registers are configured, the interrupt enabled, and the proper Trisc bits set..., why no ack?) By an oscilloscope I have seen right signals. Where is the problem? Is this kind of comunication really implementable? May be that I can't implement this comunication in interrupt driven mode? Thanks for your kind attention. Paolo Marras AIRLAB (Artificial Intelligence and Robotics Lab) Politecnico di Milano

> 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. > where can I find the right informations about this particoular role > (I2C-SLAVE)? The full data sheet for your processor is available on the Microchip web site. There is more information in the Mid-Range MCU family Reference Manual. Mine's paper, Microchip doc. DS33023A, you need Section 15, on the SSP. > Are there code examples? Only Scanty ones in the datasheets and ref manual. > 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? > By an oscilloscope I have seen right signals. The I2C master is workstation PC, I guess? And you are using 7 bit addresses? So you can see a valid Address byte to the Slave? > Where is the problem? > Is this kind of comunication really implementable? Yes. The SSP does work fine as a Slave. Its master mode that requires extensive software. > May be that I can't implement this comunication in interrupt driven mode? Yes you can, but I would start out with a non-interrupt program to 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. ------------ Barry King, KA1NLH Engineering Manager NRG Systems "Measuring the Wind's Energy" Hinesburg, Vermont, USA http://www.nrgsystems.com

> 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? Yes, that's right if you want to be interrupted on any Bus START or STOP condition. Your ISR must handle the START and STOP events. These will occur even if your slave is not addressed! So if your ISR is expecting an address byte on the first interrupt, it will not be there yet. I use SSPCON = B'00110110' so that I get interrupt on each byte, but not for every START and STOP. More details in the datasheet. > 13 SSPBUF B'00000000' > 39 SLAVE B'10100100' "SLAVE" must be one of your variables in RAM? It isn't a special function register. > 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? I think that its hard to simulate an I2C message in MPSIM, and I wonder if the interrupt routine is doing what you expect when the address byte arrives. > 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? You said you checked that on the 'Scope. Is the START valid and meeting all the setup times? When you do your test program, if you want to handle the START interrrupt, you could signal that, too, to confirm it was detected. ------------ Barry King, KA1NLH Engineering Manager NRG Systems "Measuring the Wind's Energy" Hinesburg, Vermont, USA http://www.nrgsystems.com