I2C Object that supports clock stretching?

Timothy D. Swieter

I am working on a project that needs I2C with clock stretching.· I reviewed the objects in the object exchange, but I don't think any of them support clock stretching.· I tried James' object and it didn't work.· So I investigated and I don't think I see the code facility in it to support the slave holding the clock.· Is there an object that does this or do I need to code it up?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.

www.brilldea.com·- Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto fo SunSPOT, BitScope
www.sxmicro.com - a blog·exploring the SX micro
www.tdswieter.com

Timmoore

I have been using Mike Greens I2C spin code with devices that need clock stretching without problem even though it doesn't support it. It seems at least for the devices I used that spin is slow enough that it wasn't needed.

Timmoore

I just looked more carefully at my I2C driver and I had modified it from Mikes original code. I had some devices that wouldn't run faster than 100K so I had to add time delays to slow it done to that. The clock stretching devices were on the same I2C bus and worked file with that version of the driver.

Phil Pilgrim (PhiPi)

It should be simple enough to add true clock stretching. Set SCK's OUTA bit to zero, and toggle it using DIRA. Then, whenever you raise SCK by setting its DIRA bit to zero, wait until the pin actually goes up before proceeding further.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!

Timmoore

@Tim, Did you implement the clock stretching? If you haven't I ended adding it to Mikes Basic_I2C driver because I needed it for a HMC6343 compass.

Timothy D. Swieter

No, I haven't gotten around to it. I sat down to do it and then got distracted. I have all the good intentions on so many things, but I seem to operate on distractions lately.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.

www.brilldea.com·- Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto fo SunSPOT, BitScope
www.sxmicro.com - a blog·exploring the SX micro
www.tdswieter.com

Timmoore

Try this, I have only changed read/write to support clock stretching,·according to the spec all low to high SCL should have it·but it works for hmc6343. Theres also a timeout on the clock stretching that isn't in the spec but I have had problems with other I2C implementations previously if you dont have a timeout.

Timothy D. Swieter

Thanks Timmoore. I will try this once I return to HK and have a moment. It will be a couple weeks though.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.

www.brilldea.com·- Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto fo SunSPOT, BitScope
www.sxmicro.com - a blog·exploring the SX micro
www.tdswieter.com

cdeadlock

Hello, can anyone confirm that this clock stretching addition posted by Timmoore works correctly?

I am having some trouble waking up an NXP pn532. It uses clock stretching to tell the propeller when it has awoken from its sleep mode. It is supposedly up to / over 1ms of wakeup time.

Does the clock stretching happen on the very first I2C start condition? Or after the device has recognized its own address? I am wondering if the device can even detect its own address if its oscillator has not started yet?

The pn532 documentation is a bit confusing, possibly a bad translation, but its exact words are :

Moreover, to wake up the PN532C106, the host controller must
• In I2C
Send PN532 I2C address (48h). The PN532 will stretch low the SCL line during
1 ms (can be less depending on the quartz). The host controller shall wait for the
end of the stretching.

• In HSU
Send a preamble 55 55 00 00 00 00 00 FF then Len LCS …. (I was successful in waking the chip with this serial USART interface and preamble command... but I would prefer to use i2c)


It is confusing when that 1ms clock stretching begins from this sentence.

I have tried increasing the timeout period from Timmore's code (by decreasing the I2CDelayS value) but the chip appears to be holding the clock low forever.

If the pn532 wants the address before it begins clock stretching should I be writing its address using the WriteNS() function which ignores clock stretching?

I am also not sure if the clock stretching would then start on the acknowledge bit, or the next reply byte after that.

Thank you for your time.

cdeadlock

I think I have figured it out. The address does indeed need to be sent with WriteNS() as the clock stretching does not begin until after the 9th bit ACK of the address write wakeup procedure. Then following bytes either READ() or WRITE() need clock stretching enabled. If anyone is interested the wakeup time was only 300us so perhaps the timeout increase was not necessary.

I am not sure if this is the I2C standard, or just how this particular chip wakes up.