Losing the REPL when an IRQ is triggered
Re: Losing the REPL when an IRQ is triggered
Hi!
I have the same problem with MicroPython v1.8.3-126-gdab0f31 on Wipy.
I am trying to modify the DHT22 driver (https://github.com/kurik/uPython-DHT22) to work on Wipy and it's quite annoying to loose REPL every time I use timerchannel.irq.
Michal
I have the same problem with MicroPython v1.8.3-126-gdab0f31 on Wipy.
I am trying to modify the DHT22 driver (https://github.com/kurik/uPython-DHT22) to work on Wipy and it's quite annoying to loose REPL every time I use timerchannel.irq.
Michal
Re: Losing the REPL when an IRQ is triggered
Hi, check this thread on GitHub:
https://github.com/micropython/micropython/issues/2406
It seems that it should be fixed in 1.8.4 but I did not test it yet. Please post test results if you will be testing new release.
https://github.com/micropython/micropython/issues/2406
It seems that it should be fixed in 1.8.4 but I did not test it yet. Please post test results if you will be testing new release.
Re: Losing the REPL when an IRQ is triggered
That was my recent test. But maybe the problem is the ISR itself, like dhylands posted above. If the ISR is not really minimal, then you run into trouble. Opposed to others, in my test I could not print in the ISR, so I used a flag (counter).
Re: Losing the REPL when an IRQ is triggered
I have upgraded my Wipy to MicroPython v1.8.4-10-g081c064 and now the following example from docs:
seems to work without loosing REPL! Hurray!
Michal
Code: Select all
from machine import Timer
from machine import Pin
tim = Timer(1, mode=Timer.PERIODIC, width=32)
tim_a = tim.channel(Timer.A | Timer.B, freq=1)
led = Pin('GP16', mode=Pin.OUT)
def tick(timer):
global led
led.toggle()
tim_a.irq(handler=tick, trigger=Timer.TIMEOUT)
seems to work without loosing REPL! Hurray!
Michal
Re: Losing the REPL when an IRQ is triggered
Using that code with 1.8.4 here, I get the LED flashing OK, but I lose the REPL
To be precise, I get one more REPL prompt after the 'import', and then no response to the <Enter> key or <Control+D>. I'm connecting to the REPL via WiFi.
Jim
To be precise, I get one more REPL prompt after the 'import', and then no response to the <Enter> key or <Control+D>. I'm connecting to the REPL via WiFi.
Jim
Re: Losing the REPL when an IRQ is triggered
I gave it another try after reading your post and it seems you are right. The problem persists:-( I don't understand how it could work for the first time.
Michal
Michal
Re: Losing the REPL when an IRQ is triggered
Still with 1.8.4, the following code sometimes works here, i.e. the REPL remains available and I can monitor the 'count' variable and see it increasing. Other times, it hangs the REPL either immediately or after a few seconds.
Code: Select all
from machine import Timer
count = 0
def tick(timer):
global count
count += 1
return
tim = Timer(1, mode=Timer.PERIODIC, width=32)
tim_a = tim.channel(Timer.A | Timer.B, freq=1)
tim_a.irq(handler=tick, trigger=Timer.TIMEOUT)
Re: Losing the REPL when an IRQ is triggered
How do you monitor the count value? From the REPL prompt or by within the module, which sets up the interrupt? You should put that all into a module and then monitor the count value in a loop, printing when it changes.
And please do not forget, that if you register an ISR, it still stays registered (= its adrress is still known and called) even is the module which established it terminates and Python thinks it's not needed any more. That may lead to unexpected effects.
And please do not forget, that if you register an ISR, it still stays registered (= its adrress is still known and called) even is the module which established it terminates and Python thinks it's not needed any more. That may lead to unexpected effects.
Re: Losing the REPL when an IRQ is triggered
Danke Robert!
I've tried that approach before, but not under 1.8.4. The code below sometimes works for a while in 1.8.4 - it got up to a count of 220 just now, but sometimes it doesn't start, or only gets up to one or two. I wonder if I should be using a different Timer?
"... the module which established it terminates and Python thinks it's not needed any more. That may lead to unexpected effects." To be honest, I was hoping that it -would- continue after exiting the module, and that I could monitor its continued execution from the REPL.
I've tried that approach before, but not under 1.8.4. The code below sometimes works for a while in 1.8.4 - it got up to a count of 220 just now, but sometimes it doesn't start, or only gets up to one or two. I wonder if I should be using a different Timer?
"... the module which established it terminates and Python thinks it's not needed any more. That may lead to unexpected effects." To be honest, I was hoping that it -would- continue after exiting the module, and that I could monitor its continued execution from the REPL.
Code: Select all
# timer4.py
import time
from machine import Timer
count = 0
def tick(timer):
global count
count += 1
return
tim = Timer(1, mode=Timer.PERIODIC, width=32)
tim_a = tim.channel(Timer.A | Timer.B, freq=1)
tim_a.irq(handler=tick, trigger=Timer.TIMEOUT)
last_count = 0
while True:
if count > last_count:
print(count)
last_count = count
time.sleep_ms(100)
Re: Losing the REPL when an IRQ is triggered
Hi jmdavies. I'm just running your timer4.py code, and it looks rock-solid. I canceled the first run at counter 1676, then made three other runs, which I always stopped manually at about 300. Now I let it run as far as it gets.
Configuration:
- MicroPython v1.8.4-30-g99b05f4-dirty on 2016-09-10; WiPy with CC3200
- No additional code loaded in boot.py or main.py
- Telnet terminal access with wipy as AP
- WiPy w/o carrier board connected to a lab 5V power supply with short wires..
- Modified version of the build, which enables execution of precompiled python.
P.S.: My note above about ISR not available any more may be wrong - driven by coding in other environments. If you see the module in dir(), it's still there and should be usable.
Configuration:
- MicroPython v1.8.4-30-g99b05f4-dirty on 2016-09-10; WiPy with CC3200
- No additional code loaded in boot.py or main.py
- Telnet terminal access with wipy as AP
- WiPy w/o carrier board connected to a lab 5V power supply with short wires..
- Modified version of the build, which enables execution of precompiled python.
P.S.: My note above about ISR not available any more may be wrong - driven by coding in other environments. If you see the module in dir(), it's still there and should be usable.