Timeline for What is the right way to query an I2C device from an interrupt service routine?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 3, 2019 at 16:58 | vote | accept | James Brusey | ||
| Jul 2, 2019 at 10:23 | comment | added | James Brusey |
If I understand you correctly, you are saying: have an ISR that just detaches the interrupt; in the main loop, sleep_until_interrupt(); when woken check if pin is low and if so, respond to I2C and reattach interrupt. Thank you! Do you want to update your answer?
|
|
| Jul 2, 2019 at 9:06 | comment | added | Majenko |
The time taken to poll is negligible compared to the time taken to perform the I2C operations. If you are sleeping and you are woken by the interrupt pin going low, you can just immediately go into a while loop processing any pending events until the interrupt pin goes high. Where's the cumbersome component there? The fact that you have woken up is your "interrupt" to start processing whatever events are available. Note: I use "events" to indicate things the ADXL wants to tell you about, and "interrupt" for the ISR being triggered to differentiate the two.
|
|
| Jul 2, 2019 at 8:51 | comment | added | James Brusey | The cumbersome part is that the polling time needs to be the shortest time that would ordinarily occur between interrupts to make sure that you don't miss any. This might not be easily discernible. In my case, it's possibly around 10ms, which means that I will still have quite a significant duty cycle. Although, I agree with your general principles - they are just that. | |
| Jul 2, 2019 at 8:39 | comment | added | Majenko | ISRs should be short. Nothing else happens while the ISR is running. Things that use interrupts cannot be used inside an ISR. It's best to do as little as possible in an ISR. | |
| Jul 2, 2019 at 8:37 | comment | added | Majenko | What is cumbersome? Wake on the interrupt pin, then sample in your loop. Or set a flag in the interrupt routine and use that to decide whether or not to sample. | |
| Jul 2, 2019 at 8:26 | comment | added | James Brusey | OK - it's a bit cumbersome as it means that you need to make sure that you wake up often enough to service the interrupts. Can you help me understand, though, the reason why there is a problem with detaching the interrupt handler, turning on interrupts and then proceeding from there? | |
| Jul 2, 2019 at 8:11 | comment | added | Majenko | You can still poll and sleep. The two aren't mutually exclusive. Poll an interrupt pin. | |
| Jul 2, 2019 at 8:04 | comment | added | James Brusey | Although this is true - this doesn't help when you have a low power application. Polling would mean that the main processor is constantly on whereas if I drive from an interrupt, the main processor can be in a low power "sleep" state. | |
| Jul 1, 2019 at 15:40 | history | answered | Majenko | CC BY-SA 4.0 |