crosstyan
cd5c2f64e0
Keep track-core focused on portable track state, scheme runtime, PID runtime, memory strip, and render planning. Remove the ESP-IDF/nanopb Track adapter headers and sources from the submodule so app/protobuf ownership can live in a separate firmware component. The standalone CMake and Python binding surface remains unchanged, including the emulator-facing APIs.
track-core
Standalone C++ core for TrackBackFwd track simulation and strip rendering.
This library is intentionally platform-neutral. It does not depend on ESP-IDF, FreeRTOS, protobuf/nanopb, BLE, or hardware LED drivers.
Firmware protobuf/ESP-IDF adapter types for the Track service live in
components/app_track_model in the parent project. Keep this package focused on
portable track state, scheme decoding/runtime, PID runtime, and render planning.
Build
cmake -S . -B build
cmake --build build
ctest --test-dir build --output-on-failure
When used inside an ESP-IDF project under components/track-core, the same
CMakeLists.txt registers an IDF component for the portable core only.
Python bindings
The Python package builds a nanobind extension for the emulator-facing API:
python3 -m venv .venv
. .venv/bin/activate
python -m pip install -e ".[emulator,test]"
python -m pytest python/tests
python -m track_core.emulator
The DearPyGui emulator can either render a manual static report for boundary checks or load an SM, MT, ST, or RSMT scheme and tick the portable training runtime with explicit frame deltas. Both paths render pixels through the same C++ planner used by firmware adapters.