Skip to content

zephyr: Add network module with WLAN support. - #19666

Open
VynDragon wants to merge 9 commits into
micropython:masterfrom
VynDragon:zephyr_wifi_pr
Open

zephyr: Add network module with WLAN support.#19666
VynDragon wants to merge 9 commits into
micropython:masterfrom
VynDragon:zephyr_wifi_pr

Conversation

@VynDragon

@VynDragon VynDragon commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

Summary

Add a network module that supports WLAN.
Add SSLContext support.
Revamp Socket module.
Add misc features supporting this (PSRAM stuffs, mbedtls, small utility to keep track of things).
Add ESP32-C5-DevKitC board.

The API matches documentation and often extend things to support Zephyr-specific features.

Testing

'Happy Path':

  • Scanning WiFi
  • Connecting to WiFi networks with open security, WPA2-PSK security, WPA3-PSK security.
  • Creating a WiFi AP, open or with security, with a DHCP server
  • using mip.install to install a few packages

On:

  • WIFI6 Bouffalo lab SoCs: BL61x, BL616CL and future socs. Contrast to WIFI4 which are bl60x and bl808.
  • ESP32C5 (network functionalities: sort of Yes, Sockets and TLS: failed) works good now.

Trade-offs and Alternatives

  • SSLContext Implementation is weird and mostly a mockup of a context due to how TLS sockets work in zephyr
  • It is likely possible to implement SSLContext like other ports using MBedTLS directly with whichever version is used in the specific network stack implementation. This is possibly necessary for Espressif support. However this reduces portability.
  • Espressif doesn't work properly: The espressif network stack regularly interrupts execution and the memory organization is not sane, this confuses the micropython GC and results in crashes or things not working as expected / at all. I am not sure if it is a espressif issue, or if the implementation should be robust against this. For comparison, Bouffalolab WIFI6 is a Zephyr-native network stack. One possible solution is keeping every socket and network functions running in a purely zephyr context and instead queue events and queries from micropython context: This is simple for networking as it already works like that and another layer will have minimal effects, but for sockets this is much less practical.
  • Most elements have not been tested, a lot of code is framework rather than effectively usable. I only have bflb and espressif as platforms to test on but I feel it is necessary to test on at least another zephyr-native wifi stack (nordic? NXP?) and at least verify the generic functionalities behave as expected on ethernet LAN and with offloaded networking (esp hosted? rpi pico W?).
  • Would like to have had PPP/802.15.4/Thread support but this is already a humongous PR.

Generative AI

I did not use generative AI tools to write code for this PR.

I used generative AI tools to do research on sockets, documents micropython APIs (seriously it needs more comments, I struggled previously on this and AI is a crutch here), exploring the espressif elements, and debugging mbedtls configuration.

Made possible by donations from @josuah

Add a network module to the zephyr port that supports wifi.

Signed-off-by: Vdragon <mail@massdriver.space>
Revamp socket module and add a SSLContext implementation.

Signed-off-by: Vdragon <mail@massdriver.space>
Allow relocating the MBedTLS heap.

Signed-off-by: Vdragon <mail@massdriver.space>
Allow manually specifing a memory-region.

Intended to workaround nonstandard linkage like espressif's.

Signed-off-by: Vdragon <mail@massdriver.space>
Add a function to query system heap usage.

Signed-off-by: Vdragon <mail@massdriver.space>
Store thread state in a safer way.

Signed-off-by: Vdragon <mail@massdriver.space>
Select new features in mpconfig.
Clean up prj.conf
Add networking.conf describing configuration for network features.

Signed-off-by: Vdragon <mail@massdriver.space>
@VynDragon
VynDragon force-pushed the zephyr_wifi_pr branch 3 times, most recently from fe1479f to f658266 Compare August 28, 2026 18:27
Configure bflb boards to support wifi features.

Signed-off-by: Vdragon <mail@massdriver.space>
Add an ESP32-C5 board.

Signed-off-by: Vdragon <mail@massdriver.space>
@VynDragon

VynDragon commented Aug 28, 2026

Copy link
Copy Markdown
Contributor Author

Thanks to @sylvioalves testing this and reporting it worked fine with the modifications he handed I have now applied, I figured what was 'wrong' with esp32c5:

image

The clone made a single functional change to the devkitc schematic: The board was browning out the entire time and requires one of those bridged out to work properly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant