Including WiFi support for the Challenger wifi boards.

[PontusO]

I am currently looking into adding support for the Challenger series WiFi boards into the new WiFi library.
It seems to me that adding the WiFi functions is rather simple (although I can not see any real driver API) but I am unsure how the MAC later would integrate towards our AT based higher level TCP/UDP stuff.

[JAndrassy]

the WiFi library for Pico W uses the LwIP TCP/IP stack from the Pico SDK and an implementation for the Pico W WiFi chip as network interface for LwIP.
AFAIK there is a plan to add other network interfaces (W5500 Ethernet, ENC28J60 etc) for LwIP in this core.

But your Challenger boards have esp32 for WiFi. To integrate it with LwIP in RP2040 (or any other host MCU with LwIP stack), the esp32 would have to run a firmware which would allow implementation of LwIP network interface on host MCU.
Maybe such an firmware already exists, but with a quick search I didn't find it.

[earlephilhower]

(although I can not see any real driver API)

You need to be able to send and receive packets at the ETH link layer and pass to the LWIP stack running on the Pico cores.

Then you'd subclass the lwip_XXX (see the ESP8266 libraries for W5100/W5500/ENC28J) and provide the ~4 or 5 methods and "things would just work."

Hooking in at the IP layer seems like it would be a challenge. Not sure LWIP provides for that.

[earlephilhower]

Another option might be to implement a subclass of WiFiClient And WiFiUDP.

Things like the webserver and httpclient should be able to work with that (potentially with some template adjustments)

[earlephilhower]

I'm sorry but I am not familiar w/Khoi's code. IMHO I don't really see it as better or worse, but as choice.

On the ESP8266 (and ESP32) we use our own WebServer and it just kind of made sense since I'd bet they were among the first Arduino cores w/WiFi. It has transparent support for TLS(https), filesystems, etc. which aren't universal for example. There's not quite a "standard" embedded system, yet. :)

With a WiFi chip I think it's fair to say beginners want to do stuff out of the box and not have to find their own external library. Copying the ESP32 one means they get access to all that massive ecosystem, in this case. I would have liked to pull in the ESP8266 one but we evolved that core (mostly for memory reasons...only 40K usable!) to make many libs hard to port.

Advanced users can and should look around and try Khoi's or me-no-dev's Async version if they outgrow this (or submit PRs here to improve what we have!)

[khoih-prog]

I totally agree with @earlephilhower out-of-the-box and better approach, which is similar to ESPs'.

Those generic libraries were created because the other boards (SAMD, nRF52, etc.) have no built-in WiFi/Ethernet. Therefore, no ready-made WebServer or HTTPClient library if users would like to use external WiFi/Ethernet.

I haven't tried the core's new WebServer and HTTPClient libraries. But hopefully they are flexible enough to be used for future lwip_XXX libraries.

IMHO, is it better to make WebServer a separate and independent library from WiFi, such as ESP8266WebServer for future lwip_XXX usage ?

[earlephilhower]

IMHO, is it better to make WebServer a separate and independent library from WiFi, such as ESP8266WebServer for future lwip_XXX usage ?

Sorry, I don't quite understand. It is separate in the PR, and only uses the WiFiClient and WiFiClientSecure interfaces. So of those clients use LWIP (as they do here) and we hook in the W5100 or the ENC28J, they will "just work."

I think the original issue here is that the onboard ESP for the Challenger boards only presents at the IP level, not the ETH level, so hooking into LWIP may not be doable...

[khoih-prog]

Sorry, I don't quite understand. It is separate in the PR, and only uses the WiFiClient and WiFiClientSecure interfaces. So of those clients use LWIP (as they do here) and we hook in the W5100 or the ENC28J, they will "just work."

So sorry, my bad. I was looking at the old branch. You actually did make WebServer an independent library.

For onboard ESP for the Challenger boards, I think it's better to use external libraries, such as WiFiEspAT, ESP8266_AT_WebServer, etc.

Otherwise, there will be too many WiFi/Ethernet options to be added to the core, such as WiFiNINA, etc.

[PontusO]

Another option might be to implement a subclass of WiFiClient And WiFiUDP.

Things like the webserver and httpclient should be able to work with that (potentially with some template adjustments)

After looking into to it and playing around a bit this seems to be the way to go for devices that exposes a higher level API. lwip is already included in the AT interpreter so it makes sense to create subclass at a higher level.

[PontusO]

So I've started to play around with different type of implementations for this and I have come up with something that works pretty seamlessly in the Arduino environmen, although not the prettiest solution. Would this master...PontusO:arduino-pico:dev-add-espat-support be an acceptable solution to this. Note, only the WiFiClass has been ported but it builds and works for both the pico-w and ESPAT boards.
Oh, and I should mention that this is based on @JAndrassy https://github.com/JAndrassy/WiFiEspAT library so that there are no misconceptions. My contribution is only the integration.
Basically what I have done is to move the hardware related file(s) out to their own sub libraries (WiFi-rpicow and WiFi-espat) and kept the purely WiFi related files in the original WiFi library. And as mentioned this is a test only and I've only ported the WiFiClass as a POC.
Let me know what y'all think.