i2c master/slave

http://www.melabs.com/resources/samples/pbp/i2cmast.bas
http://www.melabs.com/resources/samp...p/i2cslave.bas

I found example for this on Melabs site, tried to establish communications between 2 PICS. Connected SDA-SDA and SCL-SCL, added pull-ups of 10k (10K is marginal - you should use lower values like 4K7 - Melanie), and used examples as Melabs posted in samples,but it doesn't work. I believe that problem is in slave which uses hardware MSSP module (master uses software I2Cread/write commands), but can't precisly determine what it is.
So my question is this:
1. Did anyone tried this Melabs example?
2. Did anyone has succesfuly managed to implement pic as I2Cslave using MSSP?
3. Does anyone know an easier method of exchanging data between 2 PIC's(problem is that slave PIC has interrupt routine on <200us). I think that SPI would be way to go, so if I can not make I2C to work, maybe this is a way to go.

Hi!

Maybe these links will help you.
(Search with Google for more).

Microchip Application Note AN734:
Using the PICmicro SSP for Slave I2C Communication
http://www.microchip.com/stellent/i...ppnote=en011798

Picbasic Pro project for Slave I2C Communication:
http://www.astrosurf.com/soubie/pic_as_an_i2c_slave.htm
(See Microchip application note AN734 has errors).


Luciano

Can someone explain to me why people choose I2C for a PIC to PIC comm when a simple serial comm is so much simple???

Synchronous Communications (like I2C) is faster and more robust than Asynchronous Communications which in addition to wasteful Start and Stop Bits also requires stable clocks at each processor for fast data transfer. If you're already laying down an IC2 Bus for other devices, it seems logical to extend it to encompass your processors as well, and then your processors can happilly rely on internal oscillators freeing PIC pins. Remember that PICs internal oscillators are only guaranteed to be factory calibrated to 4MHz +/- 1% and regardlesswhat people say, that just doesn't cut it for Async speeds above 1200 Baud with any degree of reliability and repeatability... whereas I2C is happily interchanging data at between ten and forty times that speed without any regard to clock stability.

That make sense. Thanks Melanie!