Re: Early access release #3
Posted: Sat Apr 16, 2016 6:38 pm
It is my new router, my 10 years old router has no problems.The network resets periodically, why?
Please see the new forum at
https://forum.micropython.org/
It is my new router, my 10 years old router has no problems.The network resets periodically, why?
Re: onewire module: see this ticket: https://github.com/micropython/micropython/issues/1987 . WebREPL is not finished, early release #3 is first release where it's made available for early testers to gather feedback.jwissing wrote:I have flashed my ESP12E with the latest build and there is no module webrepl2 and module onewire is missing.
Early releases are to gather feedback together with suitable reports in case of issues. When filesystem support will be considered stable enough, debugging output will be turned off. As was suggested, you can turn off output yourself (at your own risk).
I conclude these are different source bases and not comparable.
I take it that it is not possible to suppress the debug messages in this build.
It's also:Frida wrote:It is my new router, my 10 years old router has no problems.The network resets periodically, why?
Ah, good, because couple of cheap boards I have here are definitely less sensitive than "bigger" WiFi device (like laptop/smartphone), get much fewer APs in scan results, and I'm got used to see regular reconnects.Frida wrote: Oh, I'm using one of yours recommendation the Adafruit HUZZAH.
Code: Select all
./webrepl_cli.py LICENSE 192.168.4.1:/test.txt
Code: Select all
>>> import webrepl
>>> webrepl.start()
WebREPL daemon started on 192.168.4.1:8266
>>> chg_A3:-180
chg_A3:0
WebREPL connection from: ('192.168.4.2', 32968)
WebREPL connected
>>> dupterm: EOF received, deactivating
chg_A3:-180
chg_A3:0
chg_A3:-180
chg_A3:0
chg_A3:-180
chg_A3:0
WebREPL connection from: ('192.168.4.2', 32970)
WebREPL connected
>>> dupterm: EOF received, deactivating
WebREPL connection from: ('192.168.4.2', 32972)
WebREPL connected
>>> dupterm: EOF received, deactivating
WebREPL connection from: ('192.168.4.2', 32974)
WebREPL connected
>>> dupterm: EOF received, deactivating
WebREPL connection from: ('192.168.4.2', 32976)
LmacRxBlk:1
LmacRxBlk:1
LmacRxBlk:1
The idea is that webrepl_cli.py should run with CPython3.3+, CPython2.7+, and even with MicroPython itself. So, if you see any issues like that, please report details to https://github.com/micropython/webrepl/issues .wendlers wrote:Hi,
I just flashed the new v04, and tried the WebREPL based client utility. First of all, it might be a good idea to mention in the README, that "webrepl_cli.py" needs to be run with Python3 (and thus, calling "./webrepl_cli.py" might not work on some "popular" Linux distros in their default setup). Or maybe just use "#!/usr/bin/env python3" instead of "#!/usr/bin/env python" at the top of the file.
You're very lucky guy. I myself usually get esp8266 unstable after 3rd file transfer (but I transfer files 40K-250K). Yes, number 6 is just right - there's internal buffer leak occurring somewhere, with LmacRxBlk:1 meaning internal receive buffers are exhausted. We saw a lot of this and similar issues when we just started (and it's well-known esp8266 issues, just google for it), and were able to contain them by tweaking lwIP parameters, etc., but here it popped again, and usual methods don't seem to help. So, it feels like searching for black cat in a dark room, and we need to improve diagnostic capability of entire network stack from modlwip thru lwip to WiFi driver in SDK (which is binary blob as you remember). That may require weeks or more, so first we need to get release out, and maybe even start on some stretch goals.Beside that, I was able to successfully copy a file with "./webrepel_cli.py". But after about copying 6 times the same file, I get repeatedly LmacRxBlk:1 on the REPL, and the device is not reachable any more until I reset it.
This really sounds like a nasty bug and I totally know how much time it takes to track such bugs downSo, it feels like searching for black cat in a dark room, and we need to improve diagnostic capability of entire network stack from modlwip thru lwip to WiFi driver in SDK (which is binary blob as you remember). That may require weeks or more, so first we need to get release out, and maybe even start on some stretch goals.
Yes, this is the error I get too when using python 2.7. The problem is, that "byte" on Python 2.7 does not allow the second parameter for the encoding. Something that works on both might be:Photon Peddler wrote: - Does webrepl require Python v3? On Mac OS X:
$ python -V
Python 2.7.10
$ webrepl/webrepl_cli.py test.py 192.168.0.123:/test.py
('put', '192.168.0.123', 8266)
('test.py', '->', '/test.py')
Traceback (most recent call last):
File "webrepl/webrepl_cli.py", line 204, in <module>
main()
File "webrepl/webrepl_cli.py", line 198, in main
put_file(ws, src_file, dst_file)
File "webrepl/webrepl_cli.py", line 93, in put_file
dest_fname = bytes(SANDBOX + remote_file, "utf-8")
TypeError: str() takes at most 1 argument (2 given)
Code: Select all
dest_fname = bytes((SANDBOX + remote_file).encode("utf-8"))
I filed an issue on the "WebREPL" git: https://github.com/micropython/webrepl/issues/3python3 webrepl/webrepl_cli.py test.py 192.168.0.123:/test.py