New *early access* mp-esp8266-firmware-vXY.bin on ESP8266

All ESP8266 boards running MicroPython.
Official boards are the Adafruit Huzzah and Feather boards.
Target audience: MicroPython users with an ESP8266 board.
pfalcon
Posts: 1155
Joined: Fri Feb 28, 2014 2:05 pm

Re: New mp-esp8266-firmware-vXY.bin on ESP8266

Post by pfalcon » Wed Mar 23, 2016 3:30 pm

thoralt wrote: However, it is _not_ outputting any data on GPIO16. I verified this by using a scope. To ensure the pin was initialized correctly and is still alive I used several pin.high() and pin.low() which showed up on the scope as intended.
To get the best performance, neopixel code is optimized for, and supports only the standard GPIO0-GPIO15. As was mentioned above, GPIO16 is special, and chances are it wouldn't work well neopixels at all, because it may have different update delay/slew rate/whatever. For other uses, GPIO16 should be supported. E.g, I don't expect issues with doing I2C on it (but worth testing), and 1wire is formally supported too, though that really needs testing how well it'll work.
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: New mp-esp8266-firmware-vXY.bin on ESP8266

Post by pfalcon » Wed Mar 23, 2016 3:38 pm

thoralt wrote:As seen in the screenshots, some of the data packets are interrupted by short pauses of 14...16 us. As I read, normally 50 us are required to reset the WS2812B and mark the end of a data stream so I wonder if this short pause could be the cause of the flickering LEDs. Can somebody explain these short pauses? Did anybody else run a greater number of WS2812B using the ESP8266?
Well, ESP8266 isn't exactly the best possible choice for real-time control, you just can't have it all in one small cheap chip. We use code from Adafruit for neopixels, and apply known basic tricks to run it real-time'ish, like putting it in iRAM. Well, those pauses show that the code gets interrupted, which isn't surprise, because WiFi, which the chip serves, is *the* real-time task, and anything else is less priority and can be preempted. We'll need to look at the way to give people better controls of interrupts, but likely that will come at the expense of WiFi connectivity.
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: New mp-esp8266-firmware-vXY.bin on ESP8266

Post by pfalcon » Wed Mar 23, 2016 4:14 pm

pfalcon wrote: For other uses, GPIO16 should be supported. E.g, I don't expect issues with doing I2C on it.
Correction - I looked at the I2C code and see that it's "optimized" too :-(. That's one of the area where we with Damien disagree - whether there should be basic generic implementation which just works, or whether there should be vendor-specific hacks everywhere ;-).
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/

arthoo
Posts: 2
Joined: Wed Mar 09, 2016 10:39 pm

Re: New mp-esp8266-firmware-vXY.bin on ESP8266

Post by arthoo » Wed Mar 23, 2016 8:17 pm

Quote "MicroPython itself doesn't store them [ESSD and Password], but that's exactly what the underlying vendor SDK does. The most bullet-proof way to deal with this is to completely erase flash (and reprogram uPy if needed) before handing out your device (esptool.py erase_flash)."

If I take my esp8266 out of range of the stored wifi accesspoint it keeps trying to connect.

no [SSID] found, reconnect after 1s
reconnect
f 0, scandone
no elfjes found, reconnect after 1s

erasing and reprogramming seems a bit harsh. tried ^C ^D and the rest. doesn't stop.
Is there a way to escape this loop?

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

Re: New mp-esp8266-firmware-vXY.bin on ESP8266

Post by pfalcon » Wed Mar 23, 2016 9:23 pm

The purpose of the station WiFi interface is to be connected to access point. So, it always tries to. If you don't want it to be connected (connecting) to AP, disable it:

Code: Select all

network.WLAN(network.STA_IF).active(False)
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
deshipu
Posts: 1385
Joined: Thu May 28, 2015 5:54 pm

Re: New mp-esp8266-firmware-vXY.bin on ESP8266

Post by deshipu » Wed Mar 23, 2016 11:57 pm

There is a very cool library for ESP8266 that uses its I2S hardware, with DMA, for driving neopixels. It doesn't let you choose the pins freely, but it's blazing fast: https://github.com/cnlohr/esp8266ws2812i2s

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

Re: New mp-esp8266-firmware-vXY.bin on ESP8266

Post by pfalcon » Thu Mar 24, 2016 10:08 am

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/

phuse
Posts: 1
Joined: Fri Apr 01, 2016 1:59 pm

Re: New mp-esp8266-firmware-vXY.bin on ESP8266

Post by phuse » Fri Apr 01, 2016 2:12 pm

[quote="pfalcon"][b]deshipu[/b], thanks, recorded as https://github.com/micropython/micropython/issues/1927[/quote]

would like to still have the current solution available as an option if possible - tested the alpha and seems to work well on the wifipixel-board :D
http://wiki.protoneer.co.nz/WifiPixels , https://www.instagram.com/p/BDRiAKfjYNg

User avatar
jgriessen
Posts: 191
Joined: Mon Sep 29, 2014 4:20 pm
Contact:

Re: New mp-esp8266-firmware-vXY.bin on ESP8266

Post by jgriessen » Fri Apr 01, 2016 9:52 pm

pfalcon wrote:The purpose of the station WiFi interface is to be connected to access point.
Is there any way to have the wifi radio listen only for an authorized station while it is in eccess point mode? In other words, to not do any broadcasts, not transmit until it hears a particular wifi radio?

That idea does not seem to go with your above statement, but I was wondering how to minimize power used in a battery/solar system. The ESP8266 will be part of a system with battery and solar power and sensors. Any power saving ideas besides just sleep and wake up at regular intervals?

In my application, a cell phone user would like to know sensor data occasionally, and start the flow of data by asking. At other times the data is not wanted, power savings and solar charging of batteries is wanted.

If this is too off topic, I'd appreciate any good links to read up on wifi used for sensor networks.

John
John Griessen blog.kitmatic.com

User avatar
platforma
Posts: 258
Joined: Thu May 28, 2015 5:08 pm
Location: Japan

Re: New *early access* mp-esp8266-firmware-vXY.bin on ESP8266

Post by platforma » Mon Apr 04, 2016 10:59 am

jgriessen,

I don't think what you're describing would work, the AP has to broadcast its SSID in order for other station to pick it up and connect. So by definition it has to "transmit before it hears a particular wifi radio". It might be possible, however to turn off SSID broadcasting to make the AP undiscoverable by others, and I suppose reduce power consumption that way. So you "authorised station" will be the only one that knows the SSID in advance and doesn't have to do a scan.

Now I'm not entirely sure if we have these functions in the esp port, but I'm guessing we don't.

Locked