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

[pfalcon]

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.

[pfalcon]

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.

[pfalcon]

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 .

[arthoo]

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]

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)

[deshipu]

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]

deshipu, thanks, recorded as https://github.com/micropython/micropython/issues/1927

[phuse]

[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
http://wiki.protoneer.co.nz/WifiPixels , https://www.instagram.com/p/BDRiAKfjYNg

[jgriessen]

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

[platforma]

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.