1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
//! Low-level radio helpers shared by every node role.
//!
//! Band selection, HT40 channel setup, and the one piece of ESP-NOW handling
//! this crate still needs: silencing esp-radio's built-in ESP-NOW receive
//! dispatcher. See [`suppress_espnow_rx`].
use ;
use cratelog_ln;
/// Permanently unregister esp-radio's ESP-NOW receive callback.
///
/// `esp_radio::wifi::new` eagerly builds `EspNow` (via `EspNow::new_internal`),
/// which calls `esp_now_init()`, registers esp-radio's heap-allocating `rcv_cb`,
/// and adds a broadcast peer — whether or not anything in this crate speaks
/// ESP-NOW. From that instant, and `esp_rtos` is already running, every
/// overheard ESP-NOW vendor action frame is `Box`ed and `push_back`ed into a
/// heap-backed `VecDeque<ReceivedData>` that nothing drains. Any blocking Wi-Fi
/// call during startup (`set_protocols`, `set_csi`) gives that callback time to
/// fire and grow the deque; on the small ESP32-S3 heap the next grow allocation
/// can fail, panicking in `handle_alloc_error` *inside esp-radio's `rcv_cb`*.
///
/// No role in this crate consumes ESP-NOW data, so the callback is dropped
/// outright at bring-up: overheard frames are then discarded at the C layer with
/// zero allocation. This also keeps Wi-Fi ISR work out of the way while a
/// dual-band ESP32-C5 radio is still being reconfigured, which was a recurring
/// source of interrupt-watchdog timeouts during `set_protocols` / `set_config` /
/// `set_csi`.
pub
/// Select the 2.4 / 5 GHz band from a primary channel number.
///
/// Only the dual-band ESP32-C5 has a band to choose; a no-op elsewhere. Without
/// this, a run on a 2.4 GHz channel can stay pinned to 5 GHz from a previous
/// application's radio state.
///
/// **The controller must already be configured and started** — `esp_wifi_set_band_mode`
/// requires it, and calling this earlier fails silently apart from the log line.
pub
/// Select both bands (dual-band scan) on a 5 GHz-capable part.
///
/// For a station with no channel hint this is the only correct choice: pinning a
/// single band means an access point on the other one is simply invisible, and
/// leaving the band alone inherits whatever a previous run selected. `Auto` is the
/// platform default on these parts, so this restores it explicitly rather than
/// trusting that nothing has changed it.
///
/// Only exists on the dual-band part; single-band chips have no band to choose and
/// no caller, so the whole function is gated rather than left as a no-op stub.
pub
/// Put the radio on an HT40 channel pair and raise the interface to 40 MHz.
///
/// `set_channel` only configures the secondary-channel offset; without also
/// widening the interface bandwidth the radio keeps a 20 MHz RX/TX path and
/// HT40 frames cannot be decoded. That applies on every chip, not just the C5.
pub