iLabs

Hi,

since a while I am working on a project that aims to provide core API compatible modules for networking for CircuitPython builds without native wifi. Boards with native wifi provide modules like wifi, ssl, socketpool in the core, i.e. implemented in C and "baked into" the firmware.

My project (https://github.com/bablokb/circuitpython-esp32at) implements these modules in Python using the ESP32-AT commandset. When everything is implemented, a program written for say the Pico-W should work with minimal changes on boards with ESP32C3 or ESP32C6 co-processor.

There is an existing project from Adafruit (https://github.com/adafruit/Adafruit_Ci ... _ATcontrol), but that project is no longer supported. Besides other problems it is complicated to use, since it has a different interface.

The challenger RP2350+Wifi6+BLE is one of my development environments (thanks to Portus). The second test-device is a Pico connect with a few jumpers to an ESP32C3-SuperMini). The challenger already has the correct ESP32C6 firmware installed. So here you only have to upload the CircuitPython firmware for the challenger.

Currently, basic wifi.radio methods work, i.e. you can set up the co-processor, scan the wlan-environment, connect to a network. DHCP and static IP configuration is supported. Still missing are all AP-related methods of wifi.radio.

The next steps will be to implement the ssl and socketpool modules. When this is done, the challenger should work as a client and be able to connect to servers using UDP, TCP and SSL.

It is still early in development, but anybody wanting to try it, do so and report any issues directly in the Github project.

Bernhard

A short status update:

this is progressing fine. The ESP32C6 is now usable as a basic HTTP-client, i.e. it executes HTTP-GET and HTTPS-GET without problems. Sending UDP also works. I haven't tested other HTTP-request types (POST and so on), but since adafruit_requests maps all of them to the same low-level socket-calls I would not expect problems. But this needs to be tested of course.

Performance is not as good as with native wifi, but this was expected. I don't think UART is slowing us down so much, it is more the fact that some of the logic is now running within the Python-VM and not in the firmware. For many applications this will play no role: when calling a JSON-API in a loop in fixed intervals it does not really matter if the connect will need a second longer or not.

Bernhard

Very nice indeed. I will make sure the ports are integrated into CircuitPython this weekend and also try your library out.

I will need to update the examples once the pins have changed their names.

I have updated the examples to use the newest pin-definitions.

Bernhard

Some further progress: I can use the RP2350+wifi now also as a HTTP-server. I only tested TCP, since SSL needs some more thoughts (and probably a handcrafted firmware for the server-certificate). I also did not test multiple concurrent connections yet. Theoretically, the ESP32C6 can handle five of them, but I am not sure my implementation can cleanly handle that.

The next steps will be to implement the AP stuff. I don't expect any problems here.

One note: the default country-settings for the device are hardwired to Sweden, which I think is ok. I added initialization code that uses the settings from the AP if available. Nevertheless, devices running as SoftAP should take care of a correct configuration. I won't enforce it though.

Good news,
The Challenger+ RP2350 WiFi6/BLE5 board is now merged into circuitpython main and will have official builds available from the Circuitpython site with their next official release.

Yes, I have seen the merge. You can actually already download it from S3: https://adafruit-circuit-python.s3.amaz ... 6_ble5/sv/

Another status-update:

the system works fine as a client. Also, all AP-methods from wifi.radio are implemented and functional, with a single (unimportant) exception where the AT command set does not provide support.

Operation as a HTTP-server also works, but concurrent client access is broken. Since web-browsers tend to open multiple sockets with the same server, this does hurt. One workaround is to use embedded stylesheets and scripts and not to link to external entities.

The fix for concurrency is complicated and needs some internal redesign. This is planned after the implementation of the remaining features.

Performance is mostly on par with native wifi solutions for normal use-cases, even without tweaks like using higher baudrates for the UART.

Bernhard

Very cool, I will be playing with it this weekend