🇹🇷 Bu yazının Türkçe versiyonuna buradan ulaşabilirsiniz.
Embedded telemetry becomes useful when it is both cheap to produce on the device and easy to reinterpret on the host. For this STM32F429I-DISC1 project, I built the observer layer around that idea: the microcontroller should emit compact metrics, while the PC should handle parsing, state, history, and visualization.
The architecture follows the board’s practical strengths. The STM32 side can send data through USART1, which is exposed to the computer by the on-board ST-LINK Virtual COM Port. For existing debug workflows, the dashboard also keeps compatibility with SWO/ITM text output. The browser never talks to the STM32 directly; it talks to a local Python bridge that exposes REST endpoints and a WebSocket stream.
The important design choice is that the dashboard is schema-flexible. It still understands the current video_metrics payloads from the firmware, including FPS, render time, CPU load, SRAM, SDRAM, and flash usage. But it does not hard-code the full UI around that single packet type. Every numeric field is flattened into a normalized metric descriptor with an id, label, value, unit, kind, and category. That means a future payload such as temperature.mcu_c or dma2d.fill_rate_mp_s can appear in the dashboard without a frontend rewrite.
I also added multiple ingestion paths. The bridge can read serial VCP data with pyserial, parse stdout from a command, consume TCP streams, read stdin, run a synthetic demo source, or launch the existing ST-LINK SWO path. This keeps the development loop pleasant: the UI can be tested without hardware, while the real board path remains ready for live measurements.
The transport layer accepts two protocol styles. Plain JSON or NDJSON is ideal while the firmware is still changing because it is human-readable and easy to debug. The binary TELM frame described in the architecture document is supported as a more efficient path: it uses a magic header, version, type, payload length, sequence number, uptime, payload, and CRC16-CCITT. The bridge validates CRCs and tracks sequence gaps, so transport problems become visible metrics instead of silent uncertainty.
On the UI side, the dashboard presents stable summary cards for the metrics we already care about, such as FPS, CPU, render time, RAM, SDRAM, and flash. Beside those, it renders a dynamic metric list and chart selector from the normalized metric registry. This gives us the best of both worlds: a focused first screen for the STM32 video workload, and enough generality to absorb the next metric family cleanly.
The result is a small external observability layer that does not force the firmware to become a web server. The STM32 can stay focused on rendering and measurement; the PC bridge can evolve toward logging, replay, SQLite sessions, or richer analysis later. Most importantly, adding the next metric is now a firmware data decision, not a dashboard redesign.
GitHub Repository
The source code for the STM32 observer firmware and the telemetry dashboard bridge is available on GitHub: