Files
track-core/README.md
T
crosstyan 1005e50be0 feat(track-core): add portable training runtimes
Move scheme and PID training runtime behavior into the pure track_core layer and expose render sinks for injected strip application.

Add ESP compatibility adapters, Python bindings/test scaffolding, and in-memory render support so app_track_bt can consume core render and runtime logic without duplicating it.

Cover circular/linear rendering boundaries, all scheme runtime types, scheme render_to parity, PID sample de-duplication, speed suppression, and live tuning in track-core tests.
2026-05-18 16:15:45 +08:00

35 lines
982 B
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.
## 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.
## 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.