| View previous topic :: View next topic |
| Author |
Message |
Fusillade
Joined: 02 Aug 2007
Posts: 31
|
| I2C Clock Stretching |
 Posted: Fri Jun 10, 2011 9:19 am |
 |
|
When setting up a PIC as an i2c slave, it appears that #use i2c(...) defaults to clock stretching as the only option available related to clock stretching is NO_STRETCH.
Is the i2c bus clock held low until completion of i2c_read()?
_________________
New:
Compiler Version: 5.078
IDE Version: MPLAB X V4.15
Devices: PIC18LF****
Old:
Compiler Version: 4.121
IDE Version: MPLAB IDE V8.63
Devices: PIC18LF**** |
|
 |
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
|
| Posted: Fri Jun 10, 2011 10:07 am |
|
|
If you use #use i2c without providing the pins for the hardware I2C or using I2Cx directive to force using an internal MSSP, then it defaults to software I2C which could very well be subject to all sorts of "clock stretching" if you have other interrupts enabled that could disrupt the software I2C's operation.
But that shouldn't matter as I2C (like SPI) are clocked protocols and so the data isn't dependent on timing like asynch items (like RS232) are.
Cheers,
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
Fusillade
Joined: 02 Aug 2007
Posts: 31
|
|
| Posted: Fri Jun 10, 2011 1:14 pm |
|
|
| bkamen wrote: | If you use #use i2c without providing the pins for the hardware I2C or using I2Cx directive to force using an internal MSSP, then it defaults to software I2C which could very well be subject to all sorts of "clock stretching" if you have other interrupts enabled that could disrupt the software I2C's operation.
But that shouldn't matter as I2C (like SPI) are clocked protocols and so the data isn't dependent on timing like asynch items (like RS232) are.
Cheers,
-Ben |
Thanks for your response. I provide the required options:
I define the device as a slave.
I define the pins.
I define the address.
I force it to use hardware as is recommended for a slave device.
I interrupt upon proper verification of the address and jump to an interrupt handler routine.
I just did not provide this information as my question is specifically related to the NO_STRETCH option available in the #use i2c pre-processor directive and the clearing of the required bit in the PIC register so that communication can continue.
My assumption is that the default configuration for the i2c using the CCS pre-processor directive is to use clock stretching since the only option that I find available is to specify no clock stretching. I would just like verification that this is true.
Based on the information in the PIC data sheet for i2c slave with clock stretching:
| Quote: | The user’s Interrupt Service Routine (ISR) must set
the CKP bit before transmission is allowed to continue.
By holding the SCLx line low, the user has time to
service the ISR and load the contents of the SSPxBUF
before the master device can initiate another transmit
sequence. |
I have not found an example of anyone using the CCS compiler for slave i2c operation in which they did a separate command for setting the CKP bit. As a result, I must assume that this bit is being set during the i2c_read() function. I would just like verification that this is true.
_________________
New:
Compiler Version: 5.078
IDE Version: MPLAB X V4.15
Devices: PIC18LF****
Old:
Compiler Version: 4.121
IDE Version: MPLAB IDE V8.63
Devices: PIC18LF**** |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
|
| Posted: Fri Jun 10, 2011 1:19 pm |
|
|
If your PIC is an I2C slave, then you have no control over clock stretching as only the master provides the clock on an I2C bus.
Also, there is no clock polarity like there can be for SPI. Since the MSSP does both, the option is there for SPI modes of operation.
This is why you haven't seen an I2C implementation that fiddles with CKP. It's only useful in SPI mode.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
Fusillade
Joined: 02 Aug 2007
Posts: 31
|
|
| Posted: Fri Jun 10, 2011 2:36 pm |
|
|
| bkamen wrote: | If your PIC is an I2C slave, then you have no control over clock stretching as only the master provides the clock on an I2C bus.
Also, there is no clock polarity like there can be for SPI. Since the MSSP does both, the option is there for SPI modes of operation.
This is why you haven't seen an I2C implementation that fiddles with CKP. It's only useful in SPI mode.
-Ben |
I think you have the information backwards.
Clock stretching is allowed with I2C. The slave can hold the SCL line low while it prepares data. Once the slave is ready, the line can be released allowing the master to continue.
For instance, I'm working with the PIC18F26J11 and the SSPxCON2 register for I2C master mode (DS39932C-page 288) defines the SEN bit as "Initiates Start condition on SDAx and SCLx pins; automatically cleared by hardware" while the SSPxCON2 register for I2C slave mode (DS39932C-page 289) defines the SEN bit as "Clock stretching is enabled for both slave transmit and slave receive (stretch enabled)".
Stretching is not allowed for this device in SPI mode and the SSPxCON2 register is ignored.
The SSPxCON1 register for SPI mode (DS39932C-page 268) defines bit CKP as the "Clock Polarity Select bit" while the SSPxCON1 register for I2C mode (DS39932C-page 287) defines bit CKP as "SCKx Release Control bit" used for releasing the clock in slave mode.
_________________
New:
Compiler Version: 5.078
IDE Version: MPLAB X V4.15
Devices: PIC18LF****
Old:
Compiler Version: 4.121
IDE Version: MPLAB IDE V8.63
Devices: PIC18LF**** |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19404
|
|
| Posted: Fri Jun 10, 2011 2:46 pm |
|
|
Fusillade is right.
You do not see clock stretching being used with SPI. On SPI, the clock is driven actively both high and low by the master, and the slave cannot affect this.
On I2C, the signals are only ever driven _low_ by the master, with the high level provided by a pull-up resistor. The slave then holds the clock _low_ till the data is read. The default setup on most chips automatically does this, only releasing the clock, when you perform an I2C_READ, which is why 'fiddling with CKP' is rarely seen. Not using stretch is the 'option', while clock stretching is the default. Historically, some compiler versions in the past, on some chips _did not_ configure the bit properly, which is why you will find code doing this.
Best Wishes |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
|
| Posted: Fri Jun 10, 2011 4:17 pm |
|
|
| Ttelmah wrote: | Fusillade is right.
You do not see clock stretching being used with SPI. On SPI, the clock is driven actively both high and low by the master, and the slave cannot affect this.
On I2C, the signals are only ever driven _low_ by the master, with the high level provided by a pull-up resistor. The slave then holds the clock _low_ till the data is read. The default setup on most chips automatically does this, only releasing the clock, when you perform an I2C_READ, which is why 'fiddling with CKP' is rarely seen. Not using stretch is the 'option', while clock stretching is the default. Historically, some compiler versions in the past, on some chips _did not_ configure the bit properly, which is why you will find code doing this.
|
Mmm, then I misunderstood what he meant.
I know clock stretching is allowed on I2C... but what what's being referred to as clock stretching I don't think of as such. That's a delayed ACK/NAK.
I've always referred to clock stretching as the concept that the master does not send out evenly paced clock pulses. Some are longer than others... while I2C has "speeds" -- I've seen people write software implementations that take their sweet time and produce some really funny looking clock trains.
but I'll go read the I2C spec again... maybe I'm using the wrong term in the wrong place. (or maybe I decided their application of a nicely timed clock ending in a delay by the slave was horrible terminology.)
Ultimately from what you described originally, it sounded like the slave could, interbyte assert timing nuances on the clock coming from the master... and that's DEFINITELY something I'd have to go search the specs for.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19404
|
|
| Posted: Sat Jun 11, 2011 2:13 am |
|
|
Clock stretching is part of I2C. It is normally only applied on the ACK/NACK pulse, but is in the spec, to do it even on other bits, for bus synchronisation (but the PIC doesn't use this).
Quote from the 2007 spec:
"Clock stretching
Clock stretching pauses a transaction by holding the SCL line LOW. The transaction cannot continue until the line is released HIGH again. Clock stretching is optional and in fact, most slave devices do not include an SCL driver so they are unable to stretch the clock.
On the byte level, a device may be able to receive bytes of data at a fast rate, but needs more time to store a received byte or prepare another byte to be transmitted. Slaves can then hold the SCL line LOW after reception and acknowledgment of a byte to force the master into a wait state until the slave is ready for the next byte transfer in a type of handshake procedure."
The PIC data sheets also use the same nomenclature:
For CXP:
"In I2 C mode:
SCK release control
1 = Enable clock
0 = Holds clock low (clock stretch). (Used to ensure data setup time.)"
Note 'clock stretch'.
It's use to change the speed of the bus 'mid byte', is very rare, and the PIC hardware does not support this, only slowing the clock for the ACK/NACK, in the 'handshake proceedure' mentioned.
Best Wishes |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA
|
|
| Posted: Sat Jun 11, 2011 10:50 am |
|
|
Thanks for the update... I didn't get to looking at it yet.
but the email shows up in my inbox. hahah.. (nag)
And that about matches what I've never seen - a slave stretching the clock.
But anyway - thanks for posting the info.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
