Pic I2C SSP Code

[nickelflippr]

Have been playing with some Pic I2c Master to Pic Slave code. When the Pic master sends a read to the slave, a peripheral interrupt flag is set and an ISR is started to feed the slave SSPBUF with data. Meanwhile, the slave main code is constantly updating the registers at a regular interval.

The problem arises when eventually the master and slave become out of sync, with new data corrupting a previous array of data to be sent. I am new to interrupts, so not sure how to go about some code that might keep the the master and slave in sync, or avoiding a slave write while the master is reading.

Maybe the answer is very careful delays being set forth, in both the master and slave units, so collision is avoided? Thanks for any ideas.

P.S. The Pic slave is sharing the master Vdd, Vss, and have seperate, but equal 20mhz oscillators. Also, the slave is attached by about a foot of I2C wire.

 

[3v0]

In this case it is a bad idea to read and write from the same data array.

There are a few ways you can fix it.

1. Do not update during a read request.

2. When the slave gets a read request from the master, stop the update process after the current update finishes for just long enough to make a copy of the data to be sent. Let the update run and send the requested data from the copy.

3. Go with a double buffer setup. You have to figure out when it is best/safe to swap the buffers.

Depends on the application. More specifically the nature of the data.

 

[nickelflippr]

I appreciate the good ideas there on ways to stop collision.

Tried the double buffer idea with table data change right after first slave write, while holding off the master read long enough to get this done. Went along pretty good for awhile, but still ended up with some corruption, hopefully this isn't a hardware problem creeping in.

Looks like I,m going to have set and clear a register upon entry into and out of the interrupt, then have the slave check that, so that a write won't occur while reading. Also in the same way, will have to check against the slave writing data, to make sure a read won't occur while writing. Tried this and when a deliberate collision course was set, the code locked up, so more work required on this angle.

Another thought would be to call for the data upon initiation of the interrupt, although I have seen many reminders on this forum to keep intterupt routines short. So how short is short?

Right now, the data from the slave is strictly an excersise in using and viewing the Pic I2C Master to Pic Slave relationship/code.

 

[nickelflippr]

Just a quick update. Taking the sizeable delay out of Main for the slave was a big help. Also buffering the interrupt value just prior to the slave read (in the case of a master write anyways) proved a winning combination.