Answer to 'can you simulate it?': the UI now renders on the host. - pm-ui: shared no_std embedded-graphics drawing (draw_ui), used by BOTH the firmware and the simulator — single source, no divergence. - uisim: host crate that draws pm-ui onto a framebuffer and exports a PNG (pure Rust, no SDL). Confirmed the bring-up pattern renders correctly off-device, so the black screen is a panel/controller issue, not a draw bug. - pm-kit: use pm_ui::draw_ui; trim the ST7796 extension init to just unlock + 0xB6 (the gamma/VCOM sent after DISPON likely blanked it); LED solid during init then slow 1 Hz blink so hung-init / running / reset-loop are distinguishable. Note: the simulator covers WHAT we draw (layout/colour/logic). It does NOT model the ST7796 controller's hardware quirks (0xB6 line count, MADCTL scan, SPI init) — those still need the bench, but that's a one-time bring-up. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| pm-kit | ||
| pm-ui | ||
| track-format | ||
| uisim | ||
| Containerfile | ||
| README.md | ||
| run.sh | ||
Rust port — track-format crate (Stage 1)
Pure parse/serialize codec for the track DSL, validated against the shared golden
vectors (tests/fixtures/track-format.json) — the third implementation alongside
engine.js and app.py. See docs/rust-port.md for the staged plan.
All tooling runs in a container (per the develop-in-container rule):
./rust/run.sh # cargo test — runs the conformance + idempotency suite
./rust/run.sh cargo build
./rust/run.sh bash # interactive shell in the crate