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>
11 lines
474 B
Bash
Executable File
11 lines
474 B
Bash
Executable File
#!/usr/bin/env bash
|
|
# Repo-root entry point for the firmware host tests.
|
|
#
|
|
# These are the tests that need NOTHING but gcc — no ESP-IDF, no Python
|
|
# venv, no node_modules, no database. They cover the sensor firmware's pure
|
|
# logic (frame parsing, byte order, compensation and level maths) and
|
|
# nothing else; the backend and frontend suites are run separately (see
|
|
# README.md).
|
|
set -euo pipefail
|
|
exec "$(dirname "$0")/firmware/esp32p4-sensor-node/test/run_tests.sh" "$@"
|