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
RP2350+Wifi6+BLE: Adding wifi support for CircuitPython
Re: RP2350+Wifi6+BLE: Adding wifi support for CircuitPython
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
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
Re: RP2350+Wifi6+BLE: Adding wifi support for CircuitPython
Very nice indeed. I will make sure the ports are integrated into CircuitPython this weekend and also try your library out.
Re: RP2350+Wifi6+BLE: Adding wifi support for CircuitPython
I will need to update the examples once the pins have changed their names.
Re: RP2350+Wifi6+BLE: Adding wifi support for CircuitPython
I have updated the examples to use the newest pin-definitions.
Bernhard
Bernhard
Re: RP2350+Wifi6+BLE: Adding wifi support for CircuitPython
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.
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.