- Wed Mar 21, 2018 11:18 pm
#74798
Yes, it seems like there is no interruption of the interrupt routine. I do not explicitly disable or enable other interrupts in my tests.
I can imagine that it would be possible to accept short interrupts of my long interrupt routine. I will try to test what happens when I enable interrupts inside the interrupt handler. E.G. a 600 µs interrupt routine (which is clearly unstable now) divided into 12 parts of 50 µs (which seems to be stable) where further interrupts are shortly enabled in between.
Something like this should be possible with the sensors because the timing critical parts (trigger data acqusition, transmit one byte using software emulated 1-Wire-protocol) can often be separated by parts with variable delays.
EDIT: I have testet what happens if I enable interrupts inside the ISR via a call to "interrupts();" and "noInterrupts();" afterwards. It makes no difference. The ISR is not interrupted and the WiFi still hangs after transmitting some data.
I can imagine that it would be possible to accept short interrupts of my long interrupt routine. I will try to test what happens when I enable interrupts inside the interrupt handler. E.G. a 600 µs interrupt routine (which is clearly unstable now) divided into 12 parts of 50 µs (which seems to be stable) where further interrupts are shortly enabled in between.
Something like this should be possible with the sensors because the timing critical parts (trigger data acqusition, transmit one byte using software emulated 1-Wire-protocol) can often be separated by parts with variable delays.
EDIT: I have testet what happens if I enable interrupts inside the ISR via a call to "interrupts();" and "noInterrupts();" afterwards. It makes no difference. The ISR is not interrupted and the WiFi still hangs after transmitting some data.
