0966fa8cfc
The firmware has never been flashed, and a real bug already reached the repo because of it: RD03E_FRAME_LEN was 5 for a 6-byte frame, so the footer check collided with the distance high byte and EVERY distance reading was garbage — always `lo | 0x5500`, about 218 metres, regardless of what the sensor saw. That was pure logic with no hardware dependency. It should have been catchable on a laptop, and there was simply no way to run the code. Extracted the hardware-free logic out of the three drivers — rd03e_parse, bmp280_compensate, mems_level — as moves rather than rewrites, carrying the explanatory comments along with the code they explain. The drivers now own only their bus I/O and call into the pure units, so nothing changes for the real device. `./run_tests.sh` builds them with gcc -Wall -Wextra -Werror plus a dependency-free assert harness: 175 checks, 0 failed, from a clean tree. Proven to catch the actual bug rather than assumed to: reintroducing FRAME_LEN 5 fails four checks, including one that reads "a simple-report frame is 6 bytes, not 5", plus the truncated-frame and 5-byte-window cases. Restored, green again. This does NOT make the firmware verified, and the README says so plainly — it is called a narrow exception and scoped to pure logic. Wiring, timing, real register behaviour and the reconstructed RD-03E frame format all still need the physical board. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
48 lines
1.7 KiB
CMake
48 lines
1.7 KiB
CMake
# Quantumancy sensor node — main component.
|
|
#
|
|
# The *_parse / *_compensate / *_level units are ESP-IDF-free pure logic,
|
|
# split out of their drivers so they can also be compiled and tested on a
|
|
# host with plain gcc — see ../test/run_tests.sh. They are listed here too
|
|
# because the on-device build needs them linked in exactly the same way.
|
|
#
|
|
# 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"
|
|
"bmp280_compensate.c"
|
|
"rd03e.c"
|
|
"rd03e_parse.c"
|
|
"mems_mic.c"
|
|
"mems_level.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, esp_driver_i2s, ...); "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, driver/uart.h,
|
|
# or driver/i2s_std.h, add esp_driver_i2c / esp_driver_uart / esp_driver_i2s
|
|
# explicitly to REQUIRES.
|