Files
qtalker---/firmware/esp32p4-sensor-node/main/CMakeLists.txt
Indiana 6e627bae15 firmware: verify against actual target hardware, fix real conflicts
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.
2026-07-24 21:30:37 +00:00

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.