The post below is in Portuguese. We will translate critical announcements as the project gains an English-speaking audience.
The ECU now talks back — firmware DTCs, a console protocol, and a Tuner that works before the board arrives
An ECU that only executes isn't enough: it needs to tell you what's going on. This arc landed DTC diagnostics in the closed firmware, the complete console protocol (live data, maps, DTCs), and a Demo mode in the Tuner that exercises the entire stack with no hardware.
Thirty-four days without a post doesn’t mean thirty-four days standing still — it means the opposite. The arc that just closed answers a question every standalone ECU has to answer before it goes on the street: how does the ECU tell you what’s happening inside?
The answer has two halves: the ECU needs to diagnose (know when something is wrong and record it) and it needs to talk (deliver that to whoever is tuning). Both landed.
DTCs: the ECU tells you what hurts
The closed firmware gained diagnostic detectors running on signals it already had: misfire (per cylinder — P0301 front, P0302 rear), knock circuit, idle control and battery voltage. When a detector trips, it becomes a DTC in the format any mechanic recognizes — P0xxx — stored on the ECU and readable from the Tuner.
The engineering detail that matters: the DTC catalog is a single source of truth in JSON with codegen. A new code is one entry in one file; the generator propagates the definition to the Tuner (TypeScript), the app (Dart) and the dashboard (C). In the firmware, the Rust constants are hand-written on purpose — but a CI guard compares the set against the registry on every commit. There’s no “the app shows a code the firmware doesn’t know” — drift between surfaces is a build error, not a field bug.
The console protocol — the ECU as a first-class citizen on the bench
The second half is the runtime console protocol: the binary contract between the ECU and any tool that talks to it. Ten operations covering the whole tuning cycle:
- Identification — PING/PONG and GET_INFO (firmware, hardware, capabilities)
- Live data — telemetry stream for dashboards and the datalogger
- Maps — read and write in 128-cell chunks, with range clamping on every cell
- Burn — writing to flash is a separate, explicit operation; writing a map changes RAM, persisting it has to pass the burn gate
- DTCs — read and clear codes
Every frame carries a CRC32 — a corrupted byte on the cable is a discarded frame, not a corrupted map. The protocol has a version byte and a capabilities bitmap, so an old ECU with a new Tuner (or the reverse) negotiates what both understand instead of breaking.
And the structural point: the protocol lives in shared no_std
crates. The same code that builds the frame on the desktop validates
the frame inside the microcontroller. It’s not two implementations we
hope agree — it’s one.
From the inside: the ECU listens
A pretty protocol in a PDF is worth nothing if the firmware doesn’t answer. The firmware now runs a console task on the serial port: bytes come in, frames get validated (CRC32 included), replies go out. This was proven with the MCU emulated — we inject the bytes of a PING into the simulated USART and assert the PONG reply byte by byte, CRC included, on every commit. How that emulation setup works deserves (and got) its own post.
Demo-Console: the entire Tuner, no board required
This is where the arc closes the loop. Pistonix Tuner gained a special port: “DEMO: Pistonix Demo ECU (console-sim)”. Select it, and the Tuner talks to a simulated ECU — using the real protocol stack, frame by frame, CRC by CRC:
- The DTC panel shows codes from the same catalog as the firmware
- The map editor exercises 128-cell chunking, clamps and the real burn gate
- Live data flows the way it will flow on the bike
When the hardware arrives, the difference between Demo mode and a real ECU is swapping one transport layer — the serial port in place of the simulator. Everything else in the Tuner has already been exercised.
As a bonus, anyone who wants to get to know the Tuner before buying anything will be able to open Demo mode and play with maps freely. A software test ride, no bike needed.
The bootloader has a contract too
In the same spirit, the USB firmware-update protocol (bootloader)
became a shared crate with its own spec — and CI compiles all these
protocol crates for the real ARM target (thumbv7em), not just for
the PC. If someone writes protocol code that doesn’t run on the
microcontroller, the build breaks immediately.
Why this matters
The firmware core sits at 500 tests; the Tuner at 60 Rust tests + 165 UI tests. But the number that matters is a different one: the distance between “hardware arrived” and “first real tuning session” has shrunk to mostly wire and connectors. Diagnostics, protocol, tuning tool — all of it already exists, talks to each other, and is tested together on every commit.
You buy a standalone ECU for the power it unlocks, but you trust it for what it tells you when something goes wrong. That part is ready.