i2c clock stretching and overrun

[valemike]

If a PIC is the only slave node on the i2c bus and there is just one master PIC...

The PIC's MSSP module only stretches the clock following a READ by the master, and does not stretch the clock following a WRITE by the master, then how do we prevent overruns during successive WRITEs?

I understand that retries are a must in software, but then this means i have to restart my whole stop/start/write_address/write_data/etc. sequence.

Or does the PIC MSSP actually stretch the clock even in WRITEs? If so, which PICs do this? the ones with an MSSP (as opposed to an SSP)? I'm confused.

[rnielsen]

The Slave is the device that will stretch the SCK signal to give it time to 'digest' the command/information that is just received. The CKP bit (look it up in the spec. sheet) can be used in your ISR, in the Slave, to hold the SCK line low until it is finished doing it's thing and then release it so the Master can send another i2c_write() out or even an i2c_read(). If the SCK line is held low NO Master is allowed to send any clock signals out. I found this out when I started messing around with the I2C protocol. I had a device that was holding it low (it was a bad device) and the Master would not communicate with any of the other devices.

You would normally use the sequence:

i2c_start();
i2c_write();
i2c_read();
i2c_read();
...and so on...
i2c_stop();

but you can send out something like:

i2c_start();
i2c_write();// device did not ACK, try again
i2c_write();// device did not ACK again, try again
.... and so on until it does ACK
i2c_write();// device ACK'd
i2c_read();
i2c_stop();

You don't even need to send out an i2c_stop() command. The i2c_stop() simply tells every device, on the i2c bus, that the Master has relinquished control of the bus and that another Master, if another Master is connected, is allowed to take control of it. I just make it a habit of sending it anyway just to make sure things are cleaned up and constant in all of my programs.

Some people like to put Delays in their Master's code to give the devices time to crunch the data. I like to monitor the ACK signal so that I don't waste time in a Delay. If the Slave is busy and not ready to accept another command it will NOACK to tell the Master that it's not ready yet. If you are programming a PIC to be a Slave then you should make your code to do this.

Ronald

[valemike]

Thanks,

I see you keep re-trying the i2c_write til you get an ACK. What if your normal sequence takes up multiple writes and/or reads, and then the e.g. 3rd write happens to be the one that failed. Doesn't this warrant the i2c MSSP 'state machine' to be re-started, and then you would have to reattempt the whole multi-write sequence?

[rnielsen]

The Slave is the one that tells the Master when it can send information. Say, you send a i2c_write(address) to get the Slave's attention. The Slave should recognize it's address and get ready for further incoming commands. If you happen to be Writing several bytes of information to the Slave the Slave might need to do something with that information each time it receives it. The Slave could hold the SCK line low(the CKP bit in the register) until it's done digesting it and then release the SCK line to allow the Master to send the next byte. As long as the SCK line is held low the Master will just sit there until it's released. Now, if the Master is sending a i2c_read() then the Master should send an ACK back to the Slave to acknowledge that it received the data from the Slave properly. Your Slave code should accomodate this as well because if the Master sends a NOACK it means that the Master is finished talking with that particular Slave.

If you are sending successive i2c_write() commands make sure your Slave takes control of the SCK line so that the Master does not try to send any data when the Slave is not ready to receive it.

Ronald

[valemike]

[valemike]

[Mark]

[valemike]

I wonder if that's an i2c handicap, or a PIC MSSP "flaw".

[Mark]

Refer to my code in the library, Multi-Master. You don't really have to digest each byte. Receive it and store it into a buffer to look at later. If you keep your ISR's short, you won't have problems.