i2C with PIC16F87, need help

[mackrackit]

Here is an example of hardware I2C, wrong chip, but you should get the idea.
http://www.picbasic.co.uk/forum/cont...-Master-Slaves

[Demon]

Here is an example of hardware I2C, wrong chip, but you should get the idea.
http://www.picbasic.co.uk/forum/cont...-Master-Slaves

It might not be a good example for a 16F87.

...
Like my other stuff, it ONLY works on 18F chips.
...

[mackrackit]

It might not be a good example for a 16F87.

No, it is not a plug and play, but the OP is wanting to know how to use the hardware and I figured it would get him started.

He could use the software command as you pointed out butt there may be a reason why he can not.

[Demon]

It definitely can't hurt to look that's fur sure.

I don't know how many times I used bits and pieces from other designs and schematics when I was researching LCDs. They usually have particularities, but sometimes they share common techniques.

[Charles Linquis]

The confusing thing about I2C is there are MASTER reads and writes, and SLAVE reads and writes.

One of the definitions of an I2C MASTER is that the MASTER drives the clock.

I2CWRITE and I2CREAD are both master-side commands. That is, an I2CWRITE will write data to a slave, and an I2CREAD reads data from a slave.


So, you can't have communication between two PICs with I2CWRITE on one side and I2CREAD on the other. One side has to be the master and one side has to be the slave. Being a master is easy - you can start talking whenever you are ready. Being a slave is harder - you have to grab the data asynchronously, whenever it comes along. That is why it is best to have the slave be interrupt-driven as in my example.

I don't know for certain that the code won't run on a 16F part. I never use them. But I do know that it works great on an 18F2221, 18F2321 and an 18F8723.

[Demon]

...
Being a master is easy - you can start talking whenever you are ready. Being a slave is harder - you have to grab the data asynchronously, whenever it comes along.
...

And that would explain why I used USART to talk between Master-Slave PICs, and used I2C to talk to eeproms and I/O Expanders. lol

That project dates back to 2005-2006, it's been a while.