Early access releases #3 & #4

All ESP8266 boards running MicroPython.
Official boards are the Adafruit Huzzah and Feather boards.
Target audience: MicroPython users with an ESP8266 board.
User avatar
Frida
Posts: 45
Joined: Sat Jan 30, 2016 2:20 pm
Location: Middelfart, Denmark

Re: Early access release #3

Post by Frida » Sat Apr 16, 2016 6:38 pm

The network resets periodically, why?
It is my new router, my 10 years old router has no problems.
Yes Frida is my watchdog!

pfalcon
Posts: 1155
Joined: Fri Feb 28, 2014 2:05 pm

Re: Early access release #3

Post by pfalcon » Sun Apr 17, 2016 2:15 pm

jwissing wrote:I have flashed my ESP12E with the latest build and there is no module webrepl2 and module onewire is missing.
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.

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.
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).
Awesome MicroPython list
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/

pfalcon
Posts: 1155
Joined: Fri Feb 28, 2014 2:05 pm

Re: Early access release #3

Post by pfalcon » Sun Apr 17, 2016 2:24 pm

Frida wrote:
The network resets periodically, why?
It is my new router, my 10 years old router has no problems.
It's also:

1. Your particular module (ask its vendor why it works that way).
2. Cheap esp8266 chip (you wouldn't expect it to work as good and as reliable as much more expensive solutions from reputable vendors, would you?)
Awesome MicroPython list
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/

User avatar
Frida
Posts: 45
Joined: Sat Jan 30, 2016 2:20 pm
Location: Middelfart, Denmark

Re: Early access release #3

Post by Frida » Sun Apr 17, 2016 5:28 pm

@pfalcon
Oh, I'm using one of yours recommendation the Adafruit HUZZAH.
And keep up the good work.
Yes Frida is my watchdog!

pfalcon
Posts: 1155
Joined: Fri Feb 28, 2014 2:05 pm

Re: Early access release #3

Post by pfalcon » Fri Apr 22, 2016 3:59 pm

Frida wrote: Oh, I'm using one of yours recommendation the Adafruit HUZZAH.
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.

Regarding 2nd point (quality of esp8266 chip, or to be more exactly, its drivers, the binary-blob, proprietary part of the SDK) - we saw a lot of issues with networking part prior and during development, and many of them we were able to overcome (WebREPL terminal is an example - it was pretty flaky as initial prototype, early release #3 shows that's pretty stable now ("working" part, not disconnect part)). But we fight 3rd week with file transfer operations of WebREPL protocol - and just can't get them to work reliably. When it works "more or less" for me, for Damien, it's still "barely works".

I'm afraid, we won't be able to much about before planned GA release date which is now less than 2 weeks away - it already proved to be a big time sink, so we need to put it aside and work on bunch of other small things we need to get right before release.

So, we release what we have now as the Early Release #4 - please try the webrepl_cli.py file transfer utility, and tell us how much it sucks for you. We still think it's better to include it into the release, because, well, being able to transfer files not so comfortably is still better than not being able to transfer them at all ;-). We're also happy that community explored alternative ways to do file transfers, e.g. mpfshel - that's exactly how it should be: we, core developers, try to do as much as we can, but we still can't do everything, the big active community can.

With these somewhat sad news about WebREPL file xfer issue, the rest of news on Early Release #4 are all good - all issues with WebREPL terminal mode reported on this thread should be fixed, debug output from the parts proved stable were removed, etc.

Generally, we're entering feature freeze mode, preparing for general availability release!
Awesome MicroPython list
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/

wendlers
Posts: 47
Joined: Wed Mar 16, 2016 10:07 pm

First try "Early access releases #4", getting "LmacRxBlk:1"

Post by wendlers » Fri Apr 22, 2016 7:09 pm

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.

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.

I run the following about 5 to 6 times from within the "webrepl" directory:

Code: Select all

./webrepl_cli.py LICENSE  192.168.4.1:/test.txt
And get the following on the REPL:

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

pfalcon
Posts: 1155
Joined: Fri Feb 28, 2014 2:05 pm

Re: First try "Early access releases #4", getting "LmacRxBlk:1"

Post by pfalcon » Fri Apr 22, 2016 7:57 pm

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.
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 .
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.
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.
Awesome MicroPython list
Pycopy - A better MicroPython https://github.com/pfalcon/micropython
MicroPython standard library for all ports and forks - https://github.com/pfalcon/micropython-lib
More up to date docs - http://pycopy.readthedocs.io/

wendlers
Posts: 47
Joined: Wed Mar 16, 2016 10:07 pm

Re: Early access releases #3 & #4

Post by wendlers » Fri Apr 22, 2016 8:51 pm

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.
This really sounds like a nasty bug and I totally know how much time it takes to track such bugs down :-(

But I think the big problem here is, that with such bugs, all the best stretch goals might only be "half the fun", if they not work reliable (e.g. if we get that "Lmac.." while doing an OTA update), so I personally would happily accept that stretch goals are delayed in favor of getting rid of such bugs.

However, great work so far, I think the ESP port really makes progress :-)

Photon Peddler
Posts: 7
Joined: Tue Jul 08, 2014 5:30 pm
Location: Connecticut, USA

Re: Early access releases #3 & #4

Post by Photon Peddler » Fri Apr 22, 2016 11:12 pm

Hi!

Some observations about v04 and also webrepl.


- Reading the RTC memory caused the firmware to crash at first:

import machine
machine.RTC().memory()

Then, after writing something (RTC().memory("ABC")), it does not crash anymore.


- Deep-sleep using the esp module function does not seem to work with integer values > 0. This simply resets right away:

import esp
esp.deepsleep(1000)

However, the longer deep-sleep example in Quick reference for the ESP8266 (http://docs.micropython.org/en/latest/e ... ckref.html) works fine. Maybe I have misunderstood the functionality of esp.deepsleep().


- 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)


- I don't seem to be able to enter the \ character on webrepl. Mac OS X 10.10.5, Safari 9.0.3 with Finnish/Swedish keyboard layout. US keyboard layout works. The character is produced by pressing right ALT + shift + 7 on Fin/Swe keyboard.


(Also, how do I turn on BBCode?)

wendlers
Posts: 47
Joined: Wed Mar 16, 2016 10:07 pm

Re: Early access releases #3 & #4

Post by wendlers » Sat Apr 23, 2016 7:37 am

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)
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:

Code: Select all

dest_fname = bytes((SANDBOX + remote_file).encode("utf-8"))
As a work-around, you could do the following:
python3 webrepl/webrepl_cli.py test.py 192.168.0.123:/test.py
I filed an issue on the "WebREPL" git: https://github.com/micropython/webrepl/issues/3

Locked