-
-
Notifications
You must be signed in to change notification settings - Fork 8.4k
esp8266: Add "esp" module with esp8266-specific "cooperative" networking... #1083
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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.
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); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
This was merged. |
SK6812 on 5v is pickier than WS2812 on 5v. Hopefully fixes micropython#1083.
....
So far implements .scan(lambda x: print(x)) function to scan for WiFi access
points.