From 5f7664ac95404cb2c989ad5f9a44fe67be42df19 Mon Sep 17 00:00:00 2001 From: Andy Aragon Date: Fri, 29 May 2026 12:56:25 -0700 Subject: [PATCH] chore(firmware): drop esp-radio coex feature (BLE/Wi-Fi never co-run) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Since #581 made BLE and Wi-Fi mutually exclusive (BLE only when no Wi-Fi SSID is configured), the radio is never shared, so esp-radio's `coex` feature is dead weight — it only exists to schedule airtime between two simultaneously-active stacks. Drop it and the coexist lib it links. Verified on-device (CoreS3, ssid=Interweb): Wi-Fi still connects, DHCP lease, SNTP synced via pool.ntp.org; boots once, no panics. Free internal heap at Wi-Fi start is unchanged (~37 KiB) — coex reserved little at runtime — so the win is binary size + removing unused complexity, not RAM. --- crates/stackchan-firmware/Cargo.toml | 10 ++++++---- crates/stackchan-firmware/src/ble/mod.rs | 8 ++++---- 2 files changed, 10 insertions(+), 8 deletions(-) diff --git a/crates/stackchan-firmware/Cargo.toml b/crates/stackchan-firmware/Cargo.toml index c9e4c8f9..d8bd0f5c 100644 --- a/crates/stackchan-firmware/Cargo.toml +++ b/crates/stackchan-firmware/Cargo.toml @@ -107,10 +107,12 @@ esp-alloc = { version = "0.9.0", features = ["defmt"] } # esp-hal ~1.1.0-rc.0 which would force a wider toolchain bump. # `unstable` is required because esp-hal itself runs with `unstable` # enabled here. `ble` enables the on-chip BLE controller (HCI behind -# the `BleConnector` Transport); `coex` lets Wi-Fi STA and BLE share -# the radio at the cost of ~10–15% Wi-Fi throughput. The bt-hci -# version pin (^0.6) cascades into the trouble-host 0.5.x line. -esp-radio = { version = "~0.17", features = ["defmt", "esp32s3", "wifi", "ble", "coex", "esp-now", "unstable"] } +# the `BleConnector` Transport). No `coex`: BLE and Wi-Fi are brought up +# mutually exclusively in firmware (BLE only when no Wi-Fi SSID is set), +# so the radio is never shared — coexistence would only cost the internal +# RAM the Wi-Fi MAC needs to start. The bt-hci version pin (^0.6) cascades +# into the trouble-host 0.5.x line. +esp-radio = { version = "~0.17", features = ["defmt", "esp32s3", "wifi", "ble", "esp-now", "unstable"] } # BLE host stack. 0.5.1 is the trouble-host release pinned to # `bt-hci ^0.6` (matches esp-radio 0.17). 0.6.0 jumps to `bt-hci 0.8` # and pairs with esp-radio 0.18 — bump together when we move the diff --git a/crates/stackchan-firmware/src/ble/mod.rs b/crates/stackchan-firmware/src/ble/mod.rs index 57ccfe86..7a96738a 100644 --- a/crates/stackchan-firmware/src/ble/mod.rs +++ b/crates/stackchan-firmware/src/ble/mod.rs @@ -37,10 +37,10 @@ //! LCD. Bonds are persisted to the SD card via [`bonds`] so a //! re-paired peer skips the passkey dance. //! -//! Coexistence: BLE rides the same radio as Wi-Fi via esp-radio's -//! `coex` feature. Expect a single-digit-percent Wi-Fi throughput -//! cost — invisible for the dashboard / SSE / settings round-trips -//! the firmware does today. +//! Mutually exclusive with Wi-Fi: BLE is brought up only when no Wi-Fi +//! SSID is configured (see `main.rs`). The two never share the radio, so +//! esp-radio's `coex` feature is left off — enabling it would only reserve +//! internal RAM the Wi-Fi MAC needs to start. //! //! Sync-version note: trouble-host 0.5.x pulls //! `embassy-sync = 0.6` while the rest of the firmware uses 0.7.