i2c: howto make the slave inhibit master's read?

valemike · Guest

Using a pair of PIC18F chips (with MSSP module), I use CCS's libraries for the Master i2c node, and used Microchip's application note AN735(?) to make interrupt driven i2c functions for the slave.

However, i find that i have to inject a couple ms delays on the Master side to let the slave do its internal computations; otherwise, the master ends up reading 0xFF.

e.g.

1. Master: i2c_start()
2. Master: i2c_write(SLAVE_ADDRESS)
3. Master: i2c_write(COMMAND_ID) // tells the slave i want XX info.
4. Master: i2c_start(); // restart
5. DELAY_MS(xxx)
6. Master: i2c_read();

You see, i need to issue the delay in step #5 in order to let the slave catch up before issuing the i2c_read. How do i configure the slave to force the master to wait? (Is the answer "clock stretching"? If so, then at what point do i set that CKP bit in the slave code?)

Mark · Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA

Step 5 should be i2c_write(SLAVE_ADDRESS + 1)

This is read mode. This will put the slave into read mode where the slave will hold the clock line low. In the interrupt routine, you will load the value into the buffer and then release the clock. Take a look at the SSPSTAT register and the CKP bit.

valemike · Guest

Thanks Mark. I meant to put step "4 1/2" where i send the odd-numbered slave address.

So it is after receiving this odd-numbered slave address write where the slave would set the CKP bit in its ISR? Then based on the preceding write, which is interpreted as a command, then the slave knows what to calculate and return? So it is the i2c_read() that will be locked up until the slave decides to release the CKP bit?

That's my interpretation on your previous answer.
-Mike

valemike · Guest

1. Master: i2c_start()
2. Master: i2c_write(SLAVE_ADDRESS)
3. Master: i2c_write(COMMAND_ID) // tells the slave i want XX info.
4. Master: i2c_start(); // restart
5. DELAY_MS(xxx)
6. Master: i2c_read();

I'm finding that if i were to halt the PIC slave (using an ICD breakpoint) in the ISR as a response to (2), then there is no clock stretching and the Master zooms right thru this thru 3,4,5,6 and ends up reading 0xFF.

After some experimentation, i found that if i were to stretch the clock in the isr corresponding to (2), (3), (there is an automatic stretch already in (6)), then all goes well without the need for delays in the master code.

Would this liberal sprinkling of stretches and releases in several parts of the isr cause anything to malfunction? So far i haven't found that to be a problem.

Mark · Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA

There would be no clock stretching for your step 2. Again, step 5 should be writing to the device with its address +1 or what it really means it with the LSB set. Slave addresses must be even for this reason. Look at the ex_slave example. This is very similar to what you want. Think about how you access a serial eeprom.

1. start
2. write device addr
3. write eeprom addr - this is just like your command
4. start
5. device addr read mode
6. read
7. stop

valemike · Guest

Mark · Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA

Writing an even number as the address will not cause the slave to stretch the clock. The odd address is where this should occur. Also, the i2c_write() calls are not infinite waits. There must be a timeout or error condition that occurs. You zooming by is do to the ignoring of these errors. I handle the receive in hardware but do the transmitting in software. I wrote my own routines so that I could have more control over these error conditions. I promised some code so I'll try to get something tomorrow. I been pretty busy at work and today spent most of the day installing wireless billing gateways. Man what an idea. Easy made money Very Happy