Researched the exact modules the user is building with and fixed three
concrete issues the earlier speculative firmware got wrong:
1. WiFi: confirmed the target board (Waveshare ESP32-P4-Module-DEV-KIT,
chip ESP32-P4NRW32) bridges WiFi through an onboard ESP32-C6
co-processor over a fixed 7-pin SDIO link (CLK18/CMD19/D0-14/D1-15/
D2-16/D3-17/RESET54, cross-confirmed against Espressif's own
esp-hosted-mcu docs). wifi_manager.c's esp_wifi_init()/esp_wifi_start()
calls don't need to change — esp_wifi_remote/esp_hosted provide a
drop-in-compatible API — but the component manifest (new
main/idf_component.yml) and sdkconfig.defaults were missing entirely.
2. Real pin conflict: the presence sensor's original UART pins (17/18)
directly collided with the SDIO CLK/D3 pins above — wiring it there
would have broken WiFi, the sensor, or both. Moved to GPIO4/5.
3. Swapped placeholder parts for the user's actual hardware:
- BME280 -> BMP280 (GY-BMP280 module): temp+pressure only, no humidity.
Rewrote the driver rather than just renaming it — the old code would
have read nonexistent humidity registers and reported garbage
forever. 3.3V-only wiring note added (the BME280 assumption of
5V-tolerant logic doesn't hold for this specific breakout).
- LD2410 -> RD-03E (Ai-Thinker, not Hi-Link — a different manufacturer
with a different, incompatible UART protocol). Rewrote the frame
parser against the RD-03E's actual (if less-documented) 5-byte
simple-report format. Reports numeric distance instead of a boolean,
which better fits both the hardware's actual output and the backend's
statistical anomaly detector.
README, CMakeLists.txt, and all cross-references updated to match.
38 lines
1.2 KiB
CMake
38 lines
1.2 KiB
CMake
# Quantumancy sensor node — main component.
|
|
#
|
|
# device_config.h is intentionally NOT listed as a source: it's a header the
|
|
# seeker generates locally (see device_config.h.example + README.md) and is
|
|
# gitignored. If it's missing, the build will fail on the #include in
|
|
# app_main.c with a clear "file not found" — that's deliberate, it's the
|
|
# signal to go copy the example file and fill it in.
|
|
|
|
idf_component_register(
|
|
SRCS
|
|
"app_main.c"
|
|
"wifi_manager.c"
|
|
"telemetry_client.c"
|
|
"sensor_registry.c"
|
|
"bmp280.c"
|
|
"rd03e.c"
|
|
INCLUDE_DIRS
|
|
"."
|
|
REQUIRES
|
|
esp_wifi
|
|
esp_netif
|
|
esp_event
|
|
nvs_flash
|
|
esp_http_client
|
|
driver
|
|
json
|
|
esp_timer
|
|
log
|
|
)
|
|
|
|
# Note (unverified): recent ESP-IDF versions (v5.3+) split the old
|
|
# monolithic "driver" component into per-peripheral components
|
|
# (esp_driver_i2c, esp_driver_uart, ...); "driver" is kept as a
|
|
# backward-compatible umbrella that still pulls those in, which is why a
|
|
# plain REQUIRES driver is used above. If a real build against your exact
|
|
# IDF version complains it can't find driver/i2c_master.h or driver/uart.h,
|
|
# add esp_driver_i2c / esp_driver_uart explicitly to REQUIRES.
|