Post by thread:Master-Slave Via I2C

Has anyone out there have any experience with using the I2C bus to communicate between two PICS? I have already developed the I2C Routines for use with a EEPROM that will be common to both micros. I am using PIC16C74A controllers and the CCS compiler. I thought about connecting the SDA and SCL lines of the bus the RB0 & RB1. Unfortunately, I can't seem to find a way to interrupt on the I2C START condition only. If I could, i could check the address byte and then ignore it if I was addressing the EEPROM. If anyone out there knows where I can find some code/help on this issue I would greatly appreciate their help. Shawn Springer PS - My current work on I2c and other portions of my project can be found here. Maybe looking at my code will help... www.pitt.edu/~swsst16/project/schedule.htm (Don't mind the dates, the software is current)

> Has anyone out there have any experience with using the I2C bus to > communicate between two PICS? I have already developed the I2C Routines for > use with a EEPROM that will be common to both micros. I am using PIC16C74A > controllers and the CCS compiler. Are you using the BSSP peripheral and the dedicated SDA/SCL hardware on the slave PIC? If not, you are doing it the hard way. > I thought about connecting the SDA and SCL > lines of the bus the RB0 & RB1. Unfortunately, I can't seem to find a way to > interrupt on the I2C START condition only. If I could... If you are using the BSSP in slave mode, you can get an interrupt only when you are addressed by the Master. Is there one PIC that needs to Master the EEPROM and Slave to another PIC? That's hard, becuase you have two masters. Its much easier to have one Master (bit banged, using SSP hardware assist is helpful), and two slaves, one hardwired EEPROM and one a PIC using SSP in slave mode. Then the Master code doesn't have to worry about arbitration. Another possibility is to have one PIC be a Master and the other PIC Slave using SSP. Then the Slave could have two OTHER pins ( another I2C bus) to the EEPROM. Then you can use the CCS code for the master on both PICS. I think the CCS I2C master routine works for these simple cases. You'll have to do the Slave support in the Slave PIC using SSP hardware yourself I think. Wastes two pins, though...

The Master controller is using the designated I2C SDA & SCL pins on PORTC. This is used to access the EEPROM. The Slave controller however, cannot use the designated pins because my current design calls for it to drive a MAX7221 chip with its SPI. The slave must be able to write to the EEPROM and the Master must be able to read from it. Also, the master must issue commands to the slave but the slave doesn't necessarily need to communicate info back to the master aside from acknowledgements. Is it easier to connect the EEPROM to the slave and master via I2C and use that bus and use two more pins for Master-Slave communications? If so, how would I configure the slave? Any ideas? Shawn Springer {Original Message removed}

Shawn, > The Master controller is using the designated I2C SDA & SCL pins on PORTC. > This is used to access the EEPROM. The Slave controller however, cannot use > the designated pins because my current design calls for it to drive a > MAX7221 chip with its SPI. So the Slave PIC has two things that need to run on the SSP. That's the basic problem. You either have to bit-bang one of them, or change the design. Whats a 7221? Is there an I2C equivalent to use instead, so you could go to all I2C? Could you just change everything to SPI? I know there are SPI EEPROMs around. I don't know much about SPI, but I think you just bus the data and clock lines to all the chips, and the master has to drive the chip selects to each slave. So that's 3 chip selects, plus the clock and data. ------------ Barry King, KA1NLH NRG Systems "Measuring the Wind's Energy" http://www.nrgsystems.com Check out the accumulated (PIC) wisdom of the ages at: PIC/PICList FAQ: http://www.piclist.org ------- End of forwarded message -------