Consolidate use of modnetwork, modusocket and cc31k #4096
Comments
Yes it could. In principle it is a good idea to consolidate duplicated functionality, and make code more port-agnostic. But in practice, in this case, it might be made harder because the different ports have very different modnetwork.c code. And the modusocket.c code is very different depending on the approach used: lwIP (esp8266, stm32 in certain configurations), POSIX-ish (unix, esp32 to some extent), or generic wrapper (cc3200, stm32). So if things get moved to extmod/ then it would be called something like extmod/modusocket_generic.c.
Yes it would also be good to move generic stuff out of ports/cc3200/ and make it reusable. We can always add compile time config options to retain existing behaviour on cc3200 where appropriate. IMO keeping the network class named "WLAN" is important. |
extmod/ neither was intended to contain, nor contains, nor should contain hardware-specific stuff, like "modnwcc31k.c". There's drivers/ for that. |
…n-main Translations update from Weblate
|
modsocket and modnetwork are now in extmod and not port-specific. Drivers must, as mentioned, stay separate. So I believe this can be closed. |
In an attempt on getting a WiFi uplink in the nrf port i have experimented with cc3k and cc31k modules. Without to much success using cc3k. After ordering a cc3100 click module i finally made some progress and got wifi up running quite well after implementing the SPI driver needed for nrf5x.
However, I'm not too keen on introducing yet another modnetwork and modusocket and a raw copy of the cc3200 modwlan with removal of cc3200 specific header includes and so on. So, i'm proposing to consolidate the modnetwork, modusocket and cc31k module (modnwcc31k.c) into extmod/.
Proposal can be seen here:
master...glennrub:network_consolidate
I have nrf, stm32 and cc3200 targets in a state where it is possible to compile, but untested (only tested non-secure socket on nrf52). Right now its a rough implementation to show the proof-of-concept.
@dpgeorge, could this be a viable solution?
@danicampora, could this work for the cc3200 port? I know this would be an intrusive patch to the cc3200 as the WLAN is renamed to CC31K (could it be weak-linked?). At least it would make the code existing for cc31k reusable for other ports quite easy, by just defining a SPI transport for it and use the alternate cc31k_make_new with the extra SPI parameters.
The text was updated successfully, but these errors were encountered: