Files
Infinity_Vis_Rust/README.md
JFly02 dde35551be Der minimale GUI-Vertical-Slice ist jetzt als eigenes Crate umgesetzt. Die Desktop-App liegt in crates/infinity_host_ui/src/main.rs und crates/infinity_host_ui/src/app.rs: lokales Fenster per eframe, globale Controls für Blackout, Master Brightness und Pattern, eine 6-Node-Übersicht, die 18er Mapping-Tabelle mit Node, top/middle/bottom, physischem Output/Kanal, 106 LEDs, direction, color_order, enable_flag, plus Walk 106-Testtrigger pro Panel und einen Status-/Event-Bereich für online/offline, letzter Kontakt und Fehlerstatus.
Damit die UI sauber getrennt bleibt, habe ich infinity_host zu einer wiederverwendbaren Core-Schicht ausgebaut: crates/infinity_host/src/lib.rs, control.rs und mock.rs definieren Snapshot-/Command-Typen und einen Mock-Simulationsdienst mit Hintergrundthread. Die UI pollt nur Snapshots über HostUiPort; sie treibt keine Realtime-Logik. Den Workspace und die Build-Hinweise habe ich in Cargo.toml, README.md und docs/build_and_deploy.md ergänzt.

Verifikation war hier nur eingeschränkt möglich: cargo und rustc sind in dieser Umgebung nicht installiert, daher konnte ich die App nicht kompilieren oder starten. Der nächste sinnvolle Schritt wäre erst nach deinem Go, den vorhandenen HostUiPort statt des Mock-Backends an echten Transportstatus anzubinden.
2026-04-17 01:45:30 +02:00

39 lines
1.7 KiB
Markdown

# Infinity Vis Rust
Production-oriented greenfield architecture for a low-latency LED control system that targets:
- 6 ESP32-N16R8 nodes
- 3 physical LED outputs per node
- 106 LEDs per output
- 18 logical panels and 1908 LEDs total
The repository is intentionally structured around hard separation of concerns:
- `crates/infinity_config`: versioned project configuration and validation
- `crates/infinity_protocol`: shared control and realtime protocol model
- `crates/infinity_host`: host-side core library, CLI, mock UI service, and runtime skeleton
- `crates/infinity_host_ui`: native Rust desktop GUI vertical slice
- `firmware/esp32_node`: ESP-IDF firmware skeleton with explicit driver abstraction
- `docs/`: architecture, protocol, validation, deployment, testing, and acceptance artifacts
- `config/`: example configuration files
The current baseline is intentionally strict about unresolved hardware facts. `UART 6`, `UART 5`, and `UART 4` are treated as unvalidated labels until the real electrical meaning is confirmed.
## Quick Start
1. Install a current Rust toolchain.
2. Review the open validation checklist in [docs/validation_open_points.md](docs/validation_open_points.md).
3. Start from [config/project.example.toml](config/project.example.toml).
4. Start the desktop GUI with `cargo run -p infinity_host_ui`.
5. Use the host CLI to validate the project config before attempting activation.
## Docs
- [Architecture](docs/architecture.md)
- [Protocol](docs/protocol.md)
- [Config Schema](docs/config_schema.md)
- [Build and Deploy](docs/build_and_deploy.md)
- [Testing](docs/testing.md)
- [Acceptance Template](docs/acceptance_template.md)
- [Legacy XML Reference](docs/legacy_xml_reference.md)