q. on ESP8266 I2C clock stretch (Arduino IDE)

For Adafruit customers who seek help with microcontrollers

Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.
Locked
User avatar
StanJ
 
Posts: 12
Joined: Sat Aug 24, 2019 7:33 am

q. on ESP8266 I2C clock stretch (Arduino IDE)

Post by StanJ »

If you don't know what I2C 'clock stretching' is, please pass this by. :-)

I'm working with the maintainers for the ESP8266 Arduino code to fix the I2C clock stretch. They've already corrected some of the issues previously, and it now supports clock stretch on any of the bits. However, it has a bug with slow parts & long stretches: it doesn't do yield(), so you may get WiFi problems, WDT resets or other 'background' issues. That's part of why it has a current default limit of 230us. I have a fix, but I'd like your input.

What's the longest clock stretch you've seen?

I'm more interested in answers from the folks here that wrote Adafruit's libraries, or someone that has a datasheet, 'scope or logic analyzer that knows that "X part needs Y clock stretch to avoid problems". If you've just randomly increased Wire.setClockStretchLimit( ) to get your part to work then you may have been 'fixing' other issues.

The change to the Arduino ESP8266 Wire library won't affect existing libraries or code; your stuff will work the same. I'm merely looking for a realistic maximum for the default Wire.setClockStretchLimit( ) to eliminate most of the "But it works with my Arduino!" complaints. I see a handful of posts here, as well as existing tweaks in Adafruit libraries to deal with the older ESP8266 Wire library, and probably 80-90 similar issues on Arduino.cc.

The longest clock stretch I've seen recently was in the 20-40ms range, so I'm planning on that for the default stretch limit unless there's a valid reason for a longer delay. You can always set it longer in your sketch if needed for an unusual part. The ESP8266 Wire library is all bit-banged code, so IT GOES AWAY AND DOESN'T RETURN until it completes an I2C transaction or it detects an error. Your sketch is suspended while servicing I2C (unlike the interrupt-driven AVR library), so I don't want to make the default delay overly long.

Batter up!

User avatar
adafruit2
 
Posts: 22149
Joined: Fri Mar 11, 2005 7:36 pm

Re: q. on ESP8266 I2C clock stretch (Arduino IDE)

Post by adafruit2 »

hi, the chips with the biggest issues are the BNO055, PN532 and CCS811. so that i do not quote an incorrect number, check the datasheet & forums
https://www.google.com/search?client=fi ... ck+stretch

User avatar
StanJ
 
Posts: 12
Joined: Sat Aug 24, 2019 7:33 am

Re: q. on ESP8266 I2C clock stretch (Arduino IDE)

Post by StanJ »

You'll be pleasantly surprised to know: "the fix is in". It didn't make it for 2.6.2, but should be included by the next rev after that. It's available on a git pull right now.

I just noticed I made a mistake, and the maximum default clock stretch in this first release is either 3x or 6x the new maximum of 150ms. That'll get corrected Real Soon Now. As before, you're free to boost that higher and there won't be any ill results any longer, but you shouldn't need to touch it in 99.9% of the cases. I looked at data sheets for a large number of chips & modules, and 150ms was the worst I saw. Way back in the Dark Ages (mid-'80s) we designed-in a SAR A/D converter that needed 300ms, but I'm sure that the chip (and possibly also the manufacturer!) are gone by now.

In order to keep the SYS and WiFi in the ESP8266 happy, it does a yield() every 5ms while it's twiddling it's thumbs waiting for the slave. The yield() may stretch the actual wait if it hits just before the slave finally releases SCL, but that won't hurt anything since the bus is state-driven by the master SCL. The longest yield() I saw was on the order of 250-300us from WiFi, but again that won't be triggered until you pass the 5ms stretch time, and generally a WiFi yield() only hits around the 20-50ms mark. The other SYS yields are much shorter, around 12-25us after every 10-20ms of clock stretch.

Unfortunately, some folks insist on using older versions of the cores or libraries, so you won't want to jump in and remove all of the Wire.setClockStretchLimit( ) statements from your existing libraries. The limits you've used previously are probably shorter than the new default maximum, but they don't hurt anything as long as they're sufficient for the parts.

Locked
Please be positive and constructive with your questions and comments.

Return to “Microcontrollers”