Skip to main content
Topic: Clock Stretching - I2C (Read 2631 times) previous topic - next topic

Clock Stretching - I2C

I thought it would be good to start a separate thread just on the topic of clock stretching.  I think it should be a requirement in future firmware revisions.

I tried out BP for the first time this week and was disappointed when I couldn't get it to communicate properly out of the box with my target PIC acting as an I2C slave.  My code relies on clock stretching for flow control and can take several tens of milliseconds to respond to certain commands.  Some commands I can get away with the 5 kHz speed, but not all.

That's my input.  Thanks for all those who work hard on this project.

Re: Clock Stretching - I2C

Reply #1
I'm sorry about that. Due to a defect in one version of the PIC 24FJ64GA002 on the Bus Pirate we use a software I2C library, and it does not support clock stretching at this time. It is on the todo list though.
Got a question? Please ask in the forum for the fastest answers.

Re: Clock Stretching - I2C

Reply #2
Could we get positive confirmation that v4 bus pirates do support clock stretching? I'm sad to say that I wasted a few hours debugging an I2C slave implementation because it was not painfully obvious that my v3b did not support clock stretching.

Re: Clock Stretching - I2C

Reply #3
I have clock stretching working on V3 with my own custom build. It is a trivial thing to implement... just wait until the clock goes high again after releasing it. I can hardly believe that it isn't implemented in the release firmware yet.