General availability release v1.8

[syrekron]

I flashed the bin that was sent out yesterday into my feather huzzah.
I did do a full erase beforehand using esptool.py.
When I try importing the ssd1306 module I get a Memory Error exception.
I've tried deleting webrepl beforehand to try to free memory but it still produces this exception.

I assume I'm missing something.
Has anyone gotten ssd1306 to work on the GA release?

[platforma]

I'll take the liberty of starting a new, release v.1.8 of 2016-05-03, thread to gather user issues and bugs.
This is the continuation of the early release threads: http://forum.micropython.org/viewtopic.php?f=16&t=1757

[platforma]

I am also getting a memory error after the ssd1306 import. However if I get the webrepl module and stop it, I can import with no problem.

Code: Select all

>>> import ssd1306
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError: 
>>> import webrepl
>>> webrepl.stop()
>>> import ssd1306
>>>

Trying to reproduce the same again I get a different output sometimes. Doing a gc.collect() however, solves the problem.

Code: Select all

MicroPython v1.8-3-gcf139c6 on 2016-05-03; ESP module with ESP8266
Type "help()" for more information.
>>> import webrepl
>>> webrepl.stop()
>>> import ssd1306
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError: memory allocation failed, allocating 166 bytes
>>> import gc
>>> gc.collect()
>>> import ssd1306
>>> 

I can see webrepl is now starting automatically on every boot, from the answer pfalcon gave me http://forum.micropython.org/viewtopic. ... =40#p10355, since my ESP remembered the AP settings (persistent after flash_erase), it starts on both STA and AP addresses. Since the auto re-connect happens after the webrepl was started, I get one useless websocket:

Code: Select all

WebREPL daemon started on ws://192.168.4.1:8266
WebREPL daemon started on ws://0.0.0.0:8266
Started webrepl in setup mode

Am I correct to assume that this is wasteful in terms of memory? Is the only way to prevent webrepl from autostarting is to exclude it from frozen modules at compile time?

I am also getting strange webrepl errors after issuing Ctrl-D over serial several times, which is solved by doing a hard reset:

Code: Select all

PYB: soft reboot
Traceback (most recent call last):
  File "boot.py", line 3, in <module>
  File "webrepl", line 61, in start
  File "webrepl", line 21, in setup_conn
OSError: 12

[deshipu]

I just tested it on the HUZZAH Feather, and couldn't reproduce the problem. I flashed the firmware, imported the sd1306 module, and tried the example code I used before at http://forum.micropython.org/viewtopic. ... 035#p10035 -- the display properly shows a sine wave.

[deshipu]

However, I noticed that pressing the "up" arrow after a soft restart makes random strings appear on the command line. I guess there is a regression on not clearing the command line history on restart.

[deshipu]

The i2c.writeto() function no longer seems to take the "stop" argument:

Code: Select all

TypeError: function does not take keyword arguments

[pfalcon]

Am I correct to assume that this is wasteful in terms of memory?

I wouldn't say "wasteful", but anything loaded/running on esp8266 takes memory, with not so much of it available. That was the idea behind WebREPL - to develop single efficient protocol to do many things with little resources, to let it run like an SSH daemon on a Linux system. Well, it still takes memory, and we actually could proceed to optimize it given the problem faced with it.

Is the only way to prevent webrepl from autostarting is to exclude it from frozen modules at compile time?

No, the way to disable it is to edit boot.py in filesystem and comment out lines related to (including import).

[platforma]

Don't get me wrong, I think the idea is perfectly valid, but the user should be given the choice to have it autostart or not, especially if one is trying to squeeze out every byte out of the available RAM and chooses to continue development over serial REPL. As in my situation, starting it on two interfaces at the same time, before the AP even connects, and listening on 0.0.0.0 is of little use, which is of course a result of me previously configuring the AP and connecting to my router.

Thank you for the pointer to boot.py!

[pfalcon]

the user should be given the choice to have it autostart or not

And user is given this choice, except the default is "on". The idea was to let use module wirelessly with as little set up as possible. Of course, as we don't ship pre-programmed hardware, it's not completely "unpack and play", as you need to program it with wires to you computer, but I hope it's still exciting enough to try it after that without any serial terminal. And as it's a new feature, it's better to have it on and let people try it with least effort, because otherwise many simple won't get to it. A bit more advanced users can easily disable it.

All in all, WebREPL by default causes enough issues for development too. For example, testsuite doesn't pass with it running. So, we'll have it not running on startup in master.

[mindrobots]

First impression: Brilliant!!

I've loaded the v1.8 binary sent ot me per your instructions on a NodeMCU (ESP8266 12e module on it?). Everything worked as expected. I had also followed the build instructions in the readme.md of the esp8266 github folder before I had gotten the release email. Those steps all worked on my Raspberry Pi build system and gave me a loadable, runnable binary.

I currently have it plugged into a Raspberry Pi 3 for loading and power. The ESP8266 presents its AP and I can connect to it and access it through webREPL. This is really awesome! I need to do more testing in depth but so far it is working.

Questions relating to ESP8266 version:
1) With Pyboard, I see the storage show up as a blk device (/dev/sdx) - with ESP8266 connected to USB, I do not see a block device presented. Is this as expected?

2) From the MicroPython ESP8266 documentation (Tutorial 1.4 and 2.1), I get the impression that I should be able to access the REPL via the USB/UART connections. It ignores any input from minicom when I connect but I do see the ESP8266 logging events to minicom as I do things through webREPL. Is this as expected? I assume webREPL has control over the UART so it can log things which is keeping me from accessing it. I've found no way to stop it and break into the UART REPL.

3) You should make a note that a copy of the webrepl.html sources and supporting files needs to be locally available on the system you attach to the AP and access the ESP8266 with. Once you attach to the ESP8266 AP, you no longer have access to other networks and can't get to the webrepl.html and supporting files if you didn't copy them some place local. (I may be missing something here.)

I'm going to set up another ESP8266 so it uses the station interface to connect to my home network. so that testing platform should be coming soon.

This is really great stuff! I wish I had been devoting more of my play time to my Pyboards (kickstarter backer) and MicroPython instead of other things. I've missed out on a lot.

I hope my feedback helps. Let me know if I can do anything to help out (sweep the floors, tidy up after the cats, test things, break things, etc.)

Thanks for all the work you've put in on this!

Rick