TWI timeout

[DanNixon]

Adds an iteration limit to the while loops in various twi_ functions and resets TWI bus if limit is reached.
Stops entire microcontroller form hanging if for whatever reason the TWI bus fails.

[Lauszus]

I would really like to see something like this in the core. I got a sensor that works perfectly 99.9% of times, but sometimes it will suddenly lock up the I2C bus and this will make the entire system fail.

Note that it runs two DC motors, so they will keep spinning, as the microcontroller is just stuck in the while loop.

For now I have just "solved" it by using a watchdog timer.

[Lauszus]

Also see: #1476

[thirtythreeforty]

This needs to get merged, or something similar to it. This bug just bought me an AVR Dragon to find the issue.

[DanNixon]

@thirtythreeforty I'll fix the merge conflicts when I'm back on internet that's fast enough to clone the ridiculously oversized repository.

I had completely forgotten about this considering I opened this over a year ago.

[PaoloP74]

News?

[wmarkow]

@DanNixon, you closed this pull request but it seems that your proposal have never been merged. Was there any particular reason behind this?

[DanNixon]

@wmarkow It sat for over two years with no activity.

[wmarkow]

Ok, I just thought that there was something wrong with your proposed fix. I'm facing the same problem with Wire library and adding some timeout feature would help for me. So I started to look for a solution and I have found you pull request. Actually I took some of your ideas to implement my own solution. Thanks.

[thirtythreeforty]

@wmarkow I can vouch that this solution works perfectly... we pulled this commit in, as-is, for a project a couple years ago.

[wmarkow]

Thank you guys for your input. It is good enough for me to know that this commit works nice.

[RalfvandenBurg]

I also used this fix, it should be included especially if you i2c bus isn't that good shielded.

[nothingface0]

I've also tested in sure-to-hang conditions (first by connecting CLK to ground and also in a system with very long I2C cables), and I can confirm that I've got several days uptime.

[ermtl]

It's been 9 [expletive deleted] YEARS since that bug was first discussed (2011), countless people pulled their hair trying to understand why their Arduino was freezing, why would it work normally, then suddenly stop, a dozen of times, it's been raised in here, dozens of times people had been told to get lost, use something else, etc ...
#7328
#2418
#1842
#5249
arduino/ArduinoCore-avr#42
Google shows pages after pages of people getting started and who get discouraged by this elusive bug they don't understand. This runs totally contrary of what arduino is supposed to stand for.

If the fix was difficult, if it compromised compatibility or added other problem, it would be understandable, but it's not the case, all that [expletive deleted] is caused by those 2 damn lines of code that obviously can create an infinite loop if for some reason the read operation does not complete :

// wait for read operation to complete
while(TWI_MRX == twi_state){
continue;
}

Yes, I know, this state is not supposed to happen according to the I2C protocol, but guess what ? electrical glitches didn't get the memo.

Countless people, after losing hours or days kind of solved the issue either by making a modified version for themselves, or switching to another library, so there are several implementations of a timeout that are simple and would easily solve the issue.

But arduino developpers stubbornly refuse to fix it !

You think I'm rude ? After 9 years of giving the finger on this issue to the whole community for absolutely no reason, I couldn't care less.

How long before you close it again ?
Just be honest, and put a "[expletive deleted] you all, WONTFIX" label on it ...