Files
track-core/README.md
T
crosstyan cd5c2f64e0 refactor(track-core): remove app-facing track adapters
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.
2026-06-18 17:58:04 +08:00

39 lines
1.2 KiB
Markdown

# 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
```bash
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:
```bash
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.