Skip to content

Please revert commit 48ff3a10ad465afc08a76874cf0e9ef25a6da86a #140

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

Open
TobbeJ opened this issue Aug 21, 2016 · 2 comments
Open

Please revert commit 48ff3a10ad465afc08a76874cf0e9ef25a6da86a #140

TobbeJ opened this issue Aug 21, 2016 · 2 comments

Comments

@TobbeJ
Copy link

TobbeJ commented Aug 21, 2016

Hello.

I have run into a problem with the Wire library and tracked it down to commit 48ff3a10ad465afc08a76874cf0e9ef25a6da86a and i believe the changes done in that commit is actually wrong.

If you have an arduino program that uses the Wire library as a i2c slave and it takes advantage of clock stretching in the onReceive event handler then it will lose data if the master sends data too fast.
The next command that was sent will most of the time only have 1 byte received instead of several.

Reverting commit 48ff3a10ad465afc08a76874cf0e9ef25a6da86a fixes the problem.
I have attached a sample program that i used to test the problem.
This program simulates the slave taking a long time by using a 1 second delay in the onReceive event handler.

To reproduce the problem, use attached file (i'm using a 328p) and then from the attached linux computer send several i2c write commands in quick succession.
for example: i2cset -y 3 0x04 0x01 0x02 0x03 0x04 i;i2cset -y 3 0x04 0x01 0x02 0x03 0x04 i;i2cset -y 3 0x04 0x01 0x02 0x03 0x04 i;i2cset -y 3 0x04 0x01 0x02 0x03 0x04 i;

first command will work and serial port on arduino will print the sent data.
second command and all following will only print first byte.
after reverting above commit output is as expected and no data loss.

WireStretchTest.txt

@TobbeJ
Copy link
Author

TobbeJ commented Aug 21, 2016

Note that i'm not testing this with a raspberry pi since i read it have a bug in its i2c implementation affecting clock stretching.
Also this is related to issue arduino/Arduino#1477

@sandeepmistry sandeepmistry transferred this issue from arduino/Arduino Sep 16, 2019
@matthijskooijman
Copy link
Collaborator

From a quick look at the code and the problematic commit (which is 48bcef5 in this repository), that commit indeed looks wrong to me (I expect it will break clock stretching by an Arduino I2c slave. It is intended to fix arduino/Arduino#1477, but from that report I cannot quite figure out what the actual problem is, so I suspect this commit does not actually fix that problem, just works around it somehow. Maybe the Arduino I2c master fails to support clock stretching properly?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants