feat: Add configurable i2c timeout

[EiNSTeiN-]

I am playing around with a custom sensor which I query using I2C. The sensor runs off a rp2040 which acts as the I2C target in this case. I wrote the code in CircuitPython for convenience, unfortunately my logic analyser shows the response time from the rp2040 to a read request is routinely in the 4ms to 6ms range which trips Klipper's hardcoded I2C timeout.

In this PR I made the timeout configurable in klippy and added the i2c_timeout config option which defaults to 5000 (the formerly hardcoded timeout value).

[github-actions[bot]]

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards, ~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[KevinOConnor]

Thanks. As high-level feedback, I don't think this will work properly in common usage. The issue is that i2c commands currently block all other task execution in the Klipper mcu code. If a device of any kind were to block the task execution for more than a few milliseconds it can cause hard to debug problems in the entire system (eg, skewed clock estimation, spurious host retransmits, lost sensor readings, spurious watchdog reboots, etc.). In that sense, the current 5ms hardcoded timeout is basically intended to catch the point where we need to resume task execution regardless of whether the device is working normally or not.

Cheers, -Kevin

[EiNSTeiN-]

That makes sense, this change was useful mainly during prototyping my own code and I've since rewritten it in C so the response times fall within the 5ms delay without changes to klipper. I'll close this PR