JFly02
dde35551be
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.
43 lines
1.2 KiB
Markdown
43 lines
1.2 KiB
Markdown
# Build and Deploy
|
|
|
|
## Host Side
|
|
|
|
Required tools:
|
|
|
|
- Rust stable toolchain
|
|
- `cargo`
|
|
|
|
Suggested commands:
|
|
|
|
```powershell
|
|
cargo test
|
|
cargo run -p infinity_host_ui
|
|
cargo run -p infinity_host -- validate --config config/project.example.toml --mode structural
|
|
cargo run -p infinity_host -- plan-boot-scene --config config/project.example.toml --preset-id safe_static_blue
|
|
```
|
|
|
|
The native UI currently runs against the host-core mock service so the operator workflow can be exercised before transport and firmware integration are complete.
|
|
|
|
Before any live activation, run:
|
|
|
|
```powershell
|
|
cargo run -p infinity_host -- validate --config config/project.example.toml --mode activation
|
|
```
|
|
|
|
Activation mode is expected to fail until the hardware mapping has been confirmed and the config is updated from `pending_validation` to concrete driver references.
|
|
|
|
## Firmware Side
|
|
|
|
Required tools:
|
|
|
|
- ESP-IDF
|
|
- Xtensa or RISC-V toolchain matching the actual ESP32 variant
|
|
|
|
Suggested layout:
|
|
|
|
- `firmware/esp32_node/`
|
|
- build with `idf.py build`
|
|
- flash with `idf.py -p <serial-port> flash monitor`
|
|
|
|
The firmware skeleton is intentionally conservative. It will not silently select a backend for `UART 6`, `UART 5`, or `UART 4`.
|