Timeline for Reuse I2C SCL or SDA Pins to signal interrupt
Current License: CC BY-SA 3.0
8 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jun 6, 2017 at 7:49 | comment | added | Mihai Galos | Excellent comments. My initial starting point was that interrupts were cleared by HW after x ms, which is not the case. Moreover, one needs to look out for unintentionally producing a start condition. Please post an answer so I can approve it. Thank you for your precious support! | |
Jun 5, 2017 at 23:35 | comment | added | MarkU | SDA falling edge while SCL high is always a Start Condition - you can't use SDA to assert interrupt status because you will lock the I2C bus. | |
Jun 5, 2017 at 23:32 | comment | added | MarkU | Intel Architecture Labs used a separate open-drain interrupt in their SMBus Smart Battery extention to I2C. They do indeed use interrupt polling through the device responding to the reserved SMBAlert address, and the open-drain SDA bus ensures the interrupting devices are priority encoded. This only works if the device is SMBus compliant however. | |
Jun 5, 2017 at 23:07 | comment | added | StainlessSteelRat | So if all your interrupt lines are tied to SCL and an interrupt occurs, how do you clear the interrupt if you cannot access the device? Interrupt SCL low. You have to be able to write to it to clear it. Tie all your INT to a separate INT line. | |
Jun 5, 2017 at 22:56 | comment | added | Janka | How do you ensure interrupts do not occur during a data transfer? It all boils down to this. If you can ensure that by some protocol, the chances you don't need interrupts at all hit the ceiling. | |
Jun 5, 2017 at 22:46 | history | edited | Mihai Galos | CC BY-SA 3.0 |
edited title
|
Jun 5, 2017 at 22:41 | review | First posts | |||
Jun 5, 2017 at 22:44 | |||||
Jun 5, 2017 at 22:38 | history | asked | Mihai Galos | CC BY-SA 3.0 |