Hi,
I had looked at those examples before, but as I said in my question, this code does not compile with a PIC16F87 as the register SSPCON2 is not there.
So my question is what do I need to modify from this example.
Hi,
I had looked at those examples before, but as I said in my question, this code does not compile with a PIC16F87 as the register SSPCON2 is not there.
So my question is what do I need to modify from this example.
Here is an example of hardware I2C, wrong chip, but you should get the idea.
http://www.picbasic.co.uk/forum/cont...-Master-Slaves
Dave
Always wear safety glasses while programming.
My Creality Ender 3 S1 Plus is a giant paperweight that can't even be used as a boat anchor, cause I'd be fined for polluting our waterways with electronic devices.
Not as dumb as yesterday, but stupider than tomorrow!
Dave
Always wear safety glasses while programming.
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.
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.
Charles Linquist
Bookmarks