6e627bae15
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.
52 lines
2.1 KiB
C
52 lines
2.1 KiB
C
// Quantumancy ESP32-P4 Sensor Node — entry point.
|
|
//
|
|
// UNVERIFIED AGAINST REAL HARDWARE. Nobody working on this workstream has a
|
|
// physical ESP32-P4 (or the BMP280 / RD-03E modules) to flash and test
|
|
// against. This firmware is real, structurally-sound ESP-IDF C, reasoned
|
|
// about carefully against ESP-IDF's documented APIs and the public
|
|
// datasheets/protocol docs for each sensor -- but "compiles and reads
|
|
// correctly" is where the verification stops. See README.md's "What's
|
|
// verified vs. not" section before treating any of this as field-tested.
|
|
//
|
|
// Boot sequence: bring up Wi-Fi station mode (device_config.h credentials),
|
|
// wait (briefly, non-fatally) for an initial connection, initialize every
|
|
// registered sensor driver, then hand off to the telemetry task, which
|
|
// periodically samples the sensor registry and POSTs the results to the
|
|
// backend. Wi-Fi reconnection and per-cycle "are we online" checks happen
|
|
// independently after this, so a boot-time Wi-Fi hiccup doesn't wedge the
|
|
// device -- it just starts reporting once the connection comes up.
|
|
|
|
#include "wifi_manager.h"
|
|
#include "sensor_registry.h"
|
|
#include "telemetry_client.h"
|
|
#include "esp_err.h"
|
|
#include "esp_log.h"
|
|
#include "freertos/FreeRTOS.h"
|
|
#include "freertos/task.h"
|
|
|
|
static const char *TAG = "app_main";
|
|
|
|
// How long to wait at boot for the first Wi-Fi connection before giving up
|
|
// on blocking and handing off to the telemetry task anyway (which will
|
|
// simply skip cycles until wifi_manager's own retry logic connects).
|
|
#define BOOT_WIFI_WAIT_MS 20000
|
|
|
|
void app_main(void) {
|
|
ESP_LOGI(TAG, "Quantumancy sensor node starting");
|
|
|
|
ESP_ERROR_CHECK(wifi_manager_start());
|
|
|
|
esp_err_t err = wifi_manager_wait_connected(pdMS_TO_TICKS(BOOT_WIFI_WAIT_MS));
|
|
if (err == ESP_OK) {
|
|
ESP_LOGI(TAG, "Wi-Fi connected at boot");
|
|
} else {
|
|
ESP_LOGW(TAG, "Wi-Fi not connected within %d ms at boot -- continuing anyway, "
|
|
"wifi_manager will keep retrying in the background", BOOT_WIFI_WAIT_MS);
|
|
}
|
|
|
|
sensor_registry_init_all();
|
|
telemetry_client_start_task();
|
|
|
|
ESP_LOGI(TAG, "startup complete, telemetry task running");
|
|
}
|