esp8266: Added wifi_opmode() to read and set WiFi operating mode #1318
Conversation
|
Nope, sorry, that's unlikely right. We should have common API for such functionality across ports, and other ports unlikely have it named like that. Please review how cc3200 port does it, spin a discussion if needed. Thanks. |
|
The CC3200 adopted the same approach that other network cards (wiznet, cc3k) were using, so the operation mode (STA, AP, right?) is configured with the constructor. |
|
#1319 for discussion |
|
Based on HackerNews discussion, I would like to merge this. The idea with postponing this patch was the hope that we'd come to new API conventions and to motivate contributors to participate in their discussion and moving forward. Neither did happen, and in the meantime, esp8266 port stalled. Between not having progress at all, and having some gradual progress, even if not in the exactly ultimate direction, I guess the latter is better. |
We had #1319, and we were getting to something there, but of course pleasing everyone was impossible. Besides that ticket, we also have #1430 and the API proposal in the wiki, so I would say that we are doing a lot to come with an unified API, but it happens to be a quite challenging task ;-). Anyway, I think it is a good idea to merge this and keep progressing on the ESP8266 port :-). |
|
Well, networking API doesn't depend on hardware access API and vice-versa, and #1319 and #876 were there long before #1430. It's certainly challenging task, and exactly where we have problems. Implementing existing Python APIs, agreeing which of them to implement and which not - no problems. But when it comes to implementing new, uPy-specific APIs, here it's a lot of slipping (and why I skip participating in #1430 discussion). |
|
+1 on merging. I think we should look at these patches as adding functionality (functionality that people have tested and is working) and then once the API is done hopefully most of the work in fixing said patches is simple renaming. As per #1439, do we want to raise an error if the mode could not be set? |
+1. |
I think it does. The network card is a piece of hardware, and like SPI, I2C, etc. we have to accommodate the API to suite different platforms. Furthermore, in the API proposal in the wiki we are defining the design goals and principles, which should hopefully serve as a set of rules to follow from now on. |
I think we should raise an |
|
Ok, merged with few naming changes: function is called wifi_mode() for consistency with existing phy_mode(). Station constants are named STA, which is standard abbreviation (STAT is something completely different). |
fix Trellis M4 DotStar pin assignments.
I wanted this function to use while testing the esp.connect() crash, but it's also come in handy for verifying the problem and the fix with esp.scan(). I tried to follow conventions for the names of the three constants, hopefully I've parsed that correctly.