micropython/micropython-esp32

unable to connet to esp32 from webREPL

sanu-krishnan opened this issue · 9 comments

sanu-krishnan commented

This happens when there is no delay statement in the infinite while loop or the delay is too small

while True:
      led.value(1)
      time.sleep_ms(10)
      led.value(0)
      time.sleep_ms(10)

Above code has the issue. But when I change the delay values to 100, it works fine.

Full Code : ebotmain.py

import time
import machine
def ebotx():	
	led=machine.Pin(5,machine.Pin.OUT)
	while True:
		led.value(1)
		time.sleep_ms(10)
		led.value(0)
		time.sleep_ms(10)

boot.py

import network
import sys
import webrepl
import time

sta_if = network.WLAN(network.STA_IF)
sta_if.active(True)
sta_if.ifconfig(('192.168.1.200','255.255.255.0','192.168.1.1', '8.8.8.8'))
sta_if.connect('xxxxx', 'xxxxxx')
sta_if.isconnected()

webrepl.start()
import ebotmain
del sys.modules['ebotmain']
import ebotmain
ebotmain.ebotx()
Avi-TelnT commented
sanu-krishnan commented

yea. both are the same code. 2nd and 3rd are the complete code.

The code inside the while loop won't be same as this blink code, and I need to repeat it till 'ebotmain.py' is updated.

According to my knowledge, webREPL can run as a daemon (in the background) on esp32 and it uses a dedicated hook to run periodically in the main uPy task in order to check for incoming connections.

Should I set any parameters to use webREPL in daemon mode?

I tried webrepl.start_foreground() as well. This has a better result, but unable to enter the password. Seems like the webREPL got hanged

Avi-TelnT commented
MrSurly commented

Why not to use timer event to blink the led?

This doesn't fix the core issue of web REPL being unresponsive when there's a tight loop.

  • 👍2
MrSurly commented

@sanu-krishnan This repo is considered deprecated as the ESP32 port is now part of the main repo. You should open an issue there, with the title specifying that this is an ESP32 e.g. ESP32: unable to connect from webREPL

Avi-TelnT commented
sanu-krishnan commented

@MrSurely : sure.

I got a reply from Mr.dpjeorge saying that 20ms delay is compolasry for the present implementation

nickzoic commented

G'day all!

Apologies, I've been away on vacation and away from keyboards, which has been wonderful but I'm just now catching up on emails.

As MrSurly points out, this repo is now only here for historical purposes, please direct all bugs & PRs to the main micropython repo. I'll look into how to turn it read only, we should have done that ages ago to prevent confusion.

On the actual topic: I'd agree with Avi-TelnT that it'd be better to use a timer or PWM channel to pulse that LED ... check out machine.PWM.

But I also agree with MrSurly that we're introducing a surprising thing here if a time.sleep_ms(10) is a different beast from a time.sleep_ms(11). In case anyone's trying to work it out, this is because of #define CONFIG_FREERTOS_HZ 100 setting the freertos internal tick clock to 100Hz = one tick per 10ms). In mphalport.c, if you sleep for <= this time then we skip the vTaskDelay but we also skip the MICROPY_EVENT_POLL_HOOK ... this might not be such a good idea.

So we should look into if there's some way out of it.

sanu-krishnan commented

Thanks nickzoic,
LED pulsing is just an example. My idea is to use WebREPL while execution of the present code, to pause that code and update the same code.
I managed it somehow by adding an interrupt on pin0, (ISR includes some delay) and pressing the button connected to pin0 to access the webREPL.

Will report further issues in the main repo.

Thank you all.