Skip to content

Conversation

pfalcon
Copy link
Contributor

@pfalcon pfalcon commented Jan 22, 2015

....

So far implements .scan(lambda x: print(x)) function to scan for WiFi access
points.

@pfalcon
Copy link
Contributor Author

pfalcon commented Jan 22, 2015

As esp826 networking is pretty differnt from BSD socket paradigm, I didn't try to implement "network" module (well, I tried and scratched that for now). Generic "esp" name is given because there's for example esp6203: https://espressif.com/en/products/esp6000/

…ing.

So far implements .scan(lambda x: print(x)) function to scan for WiFi access
points.
@dvv
Copy link

dvv commented Jan 23, 2015

s/esp/wifi/ ?

@pfalcon
Copy link
Contributor Author

pfalcon commented Jan 23, 2015

s/esp/wifi/ ?

What would be the reasons to call it with such a generic name? Current situation is that it's clear it's not possible to implement standard Python "socket" module, or MicroPython's "network" module which would contain "scan" function for other hardware - because all esp8266's function provide results via callback, instead of return value. So, currently this module just esp8266-specific, but reasons to not call it "esp8266" given above.

t->items[3] = MP_OBJ_NEW_SMALL_INT(bs->rssi);
t->items[4] = MP_OBJ_NEW_SMALL_INT(bs->authmode);
t->items[5] = MP_OBJ_NEW_SMALL_INT(bs->is_hidden);
mp_call_function_1(scan_cb_obj, t);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this protected against NLR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, need to be done. But as I mentioned in #1068 (comment) , it looks that we need to repeat code for callback protection again and again...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, with the idea to have reusable functions for protected callback execution. I assume otherwise looks ok for starters, so merging.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I though about factoring the callback wrapper code, but a lot of it relies on clearing interrupt flags, and doing certain things if the call fails, and these things are all different depending on which callback it is. So it needs some thought. Anyway, yes, merging is good.

@pfalcon
Copy link
Contributor Author

pfalcon commented Jan 25, 2015

This was merged.

tannewt added a commit to tannewt/circuitpython that referenced this pull request Aug 8, 2018
tannewt added a commit to tannewt/circuitpython that referenced this pull request Aug 21, 2018
SK6812 on 5v is pickier than WS2812 on 5v.

Hopefully fixes micropython#1083.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants