Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increase I2C clock stretching value? #3977

Closed
icucode opened this issue Dec 15, 2017 · 2 comments
Closed

Increase I2C clock stretching value? #3977

icucode opened this issue Dec 15, 2017 · 2 comments

Comments

@icucode
Copy link

@icucode icucode commented Dec 15, 2017

Basic Infos

Hardware

Hardware: ?ESP-12?
Core Version: ?2.1.0-rc2?

Description

Slow sensors doesn't work with default clock stretching value. Users or library authors have to adjust by calling e.g. Wire.setClockStretchLimit( 500L ); on ESP8266 for it to work. Can the default clock stretching (230 uS) be increased to make the code more user friendly?

Settings in IDE

Module: ?Generic ESP8266 Module?
Flash Size: ?4MB/1MB?
CPU Frequency: ?80Mhz?
Flash Mode: ?qio?
Flash Frequency: ?40Mhz?
Upload Using: ?OTA / SERIAL?
Reset Method: ?ck / nodemcu?

@devyte

This comment has been minimized.

Copy link
Collaborator

@devyte devyte commented Dec 16, 2017

@icucode Only some devices require clockstretching, and of those only the really slow ones would make use of this. The whole purpose of Wire.setClockStretchLimit() is for the user to call it with the value required by the specs of the device being used.
In other words, if you have a slow sensor, you are supposed to call this. Doing so makes the handling of the device slowness explicit.
Closing as won't fix. If a reason better than skipping a simple 1-line function call is presented, I'll reopen.

@devyte devyte closed this Dec 16, 2017
@icucode

This comment has been minimized.

Copy link
Author

@icucode icucode commented Dec 16, 2017

I understand that the explicit part can be good to have to protect the I2C bus from slow devices. But the I2C specification doesn't explicitly have a timeout for clock stretching:

"4.2.2 ... I2C can be a ‘DC’ bus, meaning that a slave device stretches the master clock when
performing some routine while the master is accessing it. This notifies the master that the
slave is busy but does not want to lose the communication. The slave device will allow
continuation after its task is complete. There is no limit in the I2C-bus protocol as to how
long this delay can be."

See:https://www.nxp.com/docs/en/user-guide/UM10204.pdf

I may also have been unlucky with my I2C device since it does not explicitly tell in the datasheet how slow it is. Instead I have had to rely on time consuming trial and error to locate the problem since I don't own an oscilloscope.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.