Purpose
The Dashboard is the driver's window into the car and the driver's way of talking back to it. It sits on the vehicle CAN bus next to the ECU, BMS, gateways, and Telemetry, renders a live TouchGFX UI on a Riverdi RVA35HI panel, reads driver input off the same touchscreen, and does three things with that:
- Displays live vehicle state: speed, SoC, instant power draw, TS temperatures, lap timing, fault indicators.
- Forwards driver commands onto the bus: sensor recalibration triggers, cooling activation, slip control on/off and mode, SD logging and telemetry toggles.
- Persists driver-configurable state (recal flags, logging/telemetry toggles, slip control mode) across power cycles via flash-emulated EEPROM.
Everything is built around the same idea the rest of the ARTTU firmware uses: a single shared snapshot of CAN-derived data (can_input_data) and UI/driver-intent state (ui_data), written by one side and read by the other, glued together through TouchGFX's Model/Presenter/View pattern.
What the board owns
- Display & TouchGFX renders the UI to the ILI9488 panel over an 8-bit FMC parallel bus, paced by the panel's tearing-effect (TE) signal and moved by GPDMA.
- UI screens present live data and collect driver input across seven TouchGFX screens (main, two button/config screens, lap data, startup, save-config, and a placeholder screen).
- Communication owns the FDCAN1 peripheral: an RX task that ingests filtered vehicle CAN traffic into
can_input_data, and a TX task that packs driver-intent flags into a periodicDASH_Buttonsframe. - Lap timing tracks lap time, delta-to-best, and a distance-indexed lap profile in the
Model, gated by two flags that are meant to be driven by an external CAN trigger (see Lap Timing). - Storage persists driver-configurable button/toggle state to flash-emulated EEPROM and reloads it at boot.
Hardware & stack
| Layer | What we use |
|---|---|
| MCU | STM32H563ZIT6 (Cortex-M33) |
| RTOS | FreeRTOS (CMSIS-RTOS2 API) |
| Display | Riverdi RVA35HI, ILI9488 controller, 320x480, over 8-bit FMC parallel (Intel 8080) |
| Display DMA | GPDMA1 Channel 6, halfword to byte exchange |
| UI framework | TouchGFX 4.26 (Designer-generated plus hand-owned HAL) |
| Touch | I2C2 capacitive touch controller |
| CAN | FDCAN1, classic CAN, 500 kbps |
| Persistent storage | Flash-emulated EEPROM (NimaLTD ee library) for driver-configurable state |
| External flash | W25Q64 QSPI/OCTOSPI, memory-mapped, holds TouchGFX assets |
How the data flows
Producers (the CAN RX task, touch handlers) each own their own slice of shared state and update it as data arrives. Consumers (screen presenters, the CAN TX task) read it back on their own schedule: Model::tick() runs once per rendered frame, canTxTask wakes on a button-change flag or a 1 ms periodic-scheduler tick. See CAN for the ring-buffer/scheduler details, and TouchGFX Integration for how the Model reaches the screens.
Where to go next
Start with the Module Index for the full task inventory, or jump into a group:
- Display: TouchGFX Integration, FMC Hardware Bring-Up
- UI: Screens
- Communication: CAN
- Lap Timing: Lap Tracking
- Storage: Flash Config
At the track or debugging hardware? Skip the theory and go straight to Track Operations: DIP switch settings, bring-up checklist, and failure-signature reference.
Configuration
Peripheral and pin configuration is driven by the .ioc file and regenerated through STM32CubeMX. Hand-edit generated files only inside USER CODE markers, or a regeneration will silently revert you (see the FMC bring-up gotchas for a concrete example of this happening on this board). TouchGFX-owned files (TouchGFX/generated/**, TouchGFXGeneratedHAL.*) are regenerated separately from TouchGFX Designer, not from CubeMX. Don't hand-edit those either; put board-specific logic in the TouchGFXHAL.* files or the screen View/Presenter files instead.
One value worth knowing by name: configTOTAL_HEAP_SIZE in Core/Inc/FreeRTOSConfig.h. If it's too small, osThreadNew() fails silently and returns NULL. No crash, no log, just a task that never runs. This happened for real (see CAN) and cost a long debugging session before the fix turned out to be a one-line heap bump.
NOTE
Keep this live: if you change a screen's data flow, add a CAN message, or touch the display driver, update the matching page under docs/modules/ in the same PR.