fupsrl

01 – Platform Architecture and Real-Time Boundaries

1 min read Updated 16 July 2026

RT-STACK is intentionally split into layers. The STM32G474 owns deterministic, time-critical actions; an optional single-board computer owns higher-level strategy, logging, user interfaces and integration. Keeping this boundary clear is the foundation for a robust project.

Architecture at a glance

Layer Responsibility Deterministic?
Trigger inputs Capture crank/cam timing edges and establish angle and RPM. Yes
STM32G474 Decode timing, schedule injection/ignition, manage low-level outputs and publish status. Yes
CAN Expose telemetry and integrate with tools or a supervisory controller. Timing-aware
Optional SBC Control models, UI, logging and non-critical strategy. No

Hardware capability and firmware configuration

The board has resources for 12 injection and 12 ignition channels, but the checked-in firmware begins with an inline-four example. V12 readiness describes channel count and hardware architecture; it does not mean a V12 can be connected without an engine-specific configuration and validation program.

Why the STM32 owns the fast path

The firmware timestamps trigger edges with the Cortex-M DWT cycle counter, runs the trigger decoder and exposes ignition/injection scheduling modules close to the hardware. Linux, network traffic, graphical tools and high-level control are valuable, but their jitter and failure modes make them unsuitable as the only owner of coil or injector timing.

Typical integration pattern

  1. Bring up the STM32 board on the bench and prove trigger decoding and outputs.
  2. Use CAN telemetry to observe state outside the controller.
  3. Add a companion computer only after the real-time layer is stable.
  4. Make commands, update rate, units, watchdog behaviour and loss-of-connection behaviour explicit.

Suggested illustration: sensors to STM32 to outputs, with CAN and the optional SBC as side paths.