Core Reference

System Architecture

What exists, where each responsibility lives, and how data moves through firmware and UI.

Core architecture layers

CAN ingestion Telemetry state Lock calculations Frame shaping HTTP API UI client

Layer responsibilities

Design principle

UI is replaceable. Firmware control path is authoritative. Any custom UI should obey firmware state and endpoint contracts rather than duplicating mode and calculation logic in-browser.

State ownership model

Domain Owner Persistence Notes
Current mode state.mode Runtime + storage Set by /api/mode, constrained when debug capture profile is active.
Input mappings mapped_input_* Storage via /api/settings Keys resolved at runtime into DBC bindings.
Curves/maps state.cpp arrays Storage + map files Used by dynamic modes; UI edits data, firmware runs interpolation.
Live telemetry received_* values Runtime only Updated by mapped decode first, then fallback decode when stale/missing.
Logs filelog.cpp LittleFS Scoped logs (all, can, error) with rotation.

Safety boundaries

Related references

Try the OpenHaldex Firmware Demo

Preview the real OpenHaldex firmware UI in your browser with simulated live CAN traffic and interactive pages for tuning, diagnostics, logs, setup, and OTA workflows.

Open firmware demo