Multiple PIC talking to same I2C device

[GrandPa]

I want to implement a circuit where 2 microcontrollers (PIC18F4620 and PIC18F4431) will exchange values with an I2C EEPROM device (24LC32).

18F4620 will both read an write stored values, while 18F4431 will only read values. I have no problem using a single PIC to talk to I2C EEPROM, but was wondering about possible data collision with such a design.

The exact question is what will happen if 18F4431 try to read data while 18F4620 is writing the same or any other memory location at the same time? I would also know what is the best way to avoid/detect/fix data collision in such case.

J-P

[sinoteq]

Yes! There is a risk of collision, the more times you read and write the bigger the risk.
I think think one way to fix this is with one extra line between the PICs. Call it 'Enable EE2' and make the PIC that wants to access the EE2 pull it high or low before it accesses the EE2 and keep it high/low untill you are done. When it is not used it is regarded as an input in the TRIS setting. Of course before you do this you check that it is not in an "enabled" state. There are many more ways of doing this, I bet it can be solved with a software function also by checking the SDA and SCL for traffic but if you have extra pins this is the easiest way.

[GrandPa]

I've read the manual a little more and found that "If the optional Label is included, this label will be jumped to if an acknowledge is not received from the IC2 device."

Maybe this can be the easiest solution? Something like using I2CREAD or I2CWRITE in a subroutine with a label, a little delay too maybe, and if read or write failed then jump back and try again the subroutine?

Any comment about this will be appreciated.

J-P

[Melanie]

No, Label won't work.

I2C relies on the Master (PIC) generating a clock. You can't have two Masters because firstly the bus would have to be multiplexed between the Masters, but secondly, one would interfere with the other should they use the bus at the same time.

Options...

1. One was was already mentioned. Use a third line between the PICs to indicate the bus is in use.

2. Dedicate one PIC as the I2C bus server, and on request it will fetch whatever data the other PIC requires.

3. Synchronise a clock between PICs... (say 10Hz...), PIC-A is only allowed to use the bus commencing on a clock leading edge, PIC-B is only allowed to use the bus commencing on the falling edge. Here with this example, all bus transactions must be completed within say a 45mS slot.

Checking the bus for traffic is not a good way to go, because there are many instances where a pause in mid-transfer (eg a 10mS wait following an EEPROM Write) could be construed as the bus being free.

[SteveB]

The 18F MSSP has a "Multi-Master" mode for the I2C bus. I've never used it, only know about it from the 18F4620 datasheet and spending a lot of time reading the Phillips I2C Bus Spec Sheet (http://www.nxp.com/acrobat_download/literature/9398/39340011.pdf) a while back.

It might be worth doing some study. I could be easier to implement than we first realize, especially with 2 PIC in the same basic family (18F).

HTH,
Steve

EDIT: Here is a new link for I2C Specifications (http://www.nxp.com/news/backgrounders/bg_esc9727/index.html). There is a link to a new .pdf file (http://www.nxp.com/acrobat/usermanuals/UM10204_3.pdf) for the bus specs.