A ECU agora conversa — DTCs no firmware, protocolo de console e um Tuner que funciona antes da placa chegar
Uma ECU que só executa não basta: ela precisa contar o que está acontecendo. Esse arco landou diagnóstico DTC no firmware fechado, o protocolo de console completo (live data, mapas, DTCs) e um modo Demo no Tuner que exercita o stack inteiro sem hardware.
Trinta e quatro dias sem post não significa trinta e quatro dias parado — significa o oposto. O arco que fechou agora resolve uma pergunta que toda ECU standalone tem que responder antes de ir pra rua: como a ECU conta o que está acontecendo lá dentro?
A resposta tem duas metades: a ECU precisa diagnosticar (saber quando algo está errado e registrar) e precisa conversar (entregar isso pra quem está calibrando). As duas landaram.
DTCs: a ECU conta o que dói
O firmware fechado ganhou detectores de diagnóstico rodando sobre sinais que ele já tinha: misfire (por cilindro — P0301 dianteiro, P0302 traseiro), circuito de knock, controle de marcha lenta e tensão de bateria. Quando um detector dispara, vira um DTC no padrão que qualquer mecânico reconhece — P0xxx — armazenado na ECU e legível pelo Tuner.
O detalhe de engenharia que importa: o catálogo de DTCs é fonte única em JSON com codegen. Um código novo é uma entrada num arquivo; o gerador propaga a definição pro Tuner (TypeScript), pro app (Dart) e pro dashboard (C). No firmware, as constantes Rust são escritas à mão de propósito — mas um guard de CI compara o conjunto contra o registry a cada commit. Não existe “o app mostra um código que o firmware não conhece” — drift entre superfícies é erro de build, não bug de campo.
O protocolo de console — a ECU como cidadã de primeira classe na bancada
A segunda metade é o protocolo de console runtime: o contrato binário entre a ECU e qualquer ferramenta que conversa com ela. São 10 operações cobrindo o ciclo inteiro de calibração:
- Identificação — PING/PONG e GET_INFO (firmware, hardware, capabilities)
- Live data — stream de telemetria pra dashboards e datalogger
- Mapas — leitura e escrita em chunks de 128 células, com clamp de faixa em cada célula
- Burn — gravar na flash é uma operação separada e explícita; escrever num mapa muda a RAM, gravar exige passar pelo gate de burn
- DTCs — ler e limpar códigos
Cada frame carrega CRC32 — byte corrompido no cabo é frame descartado, não mapa corrompido. O protocolo tem version byte e bitmap de capabilities, então ECU velha + Tuner novo (ou o contrário) negociam o que ambos entendem em vez de quebrar.
E o ponto estrutural: o protocolo vive em crates no_std
compartilhados. O mesmo código que monta o frame no desktop é o que
valida o frame dentro do microcontrolador. Não são duas implementações
que torcemos pra concordar — é uma.
Do lado de dentro: a ECU escuta
Protocolo bonito em PDF não vale nada se o firmware não responde. O firmware agora roda uma task de console na serial: bytes entram, frames são validados (CRC32 incluso), respostas saem. Isso foi provado com o MCU emulado — a gente injeta os bytes de um PING na USART simulada e asserta a resposta PONG byte a byte, CRC incluído, a cada commit. Como esse setup de emulação funciona merece (e ganhou) um post próprio.
Demo-Console: o Tuner inteiro, sem placa nenhuma
Aqui o arco fecha o círculo. O Pistonix Tuner ganhou uma porta especial: “DEMO: Pistonix Demo ECU (console-sim)”. Selecionou, o Tuner conversa com uma ECU simulada — mas usando o stack real do protocolo, frame por frame, CRC por CRC:
- O painel de DTCs mostra códigos do mesmo catálogo do firmware
- O editor de mapas exercita chunking de 128 células, clamps e o gate de burn de verdade
- Live data flui como vai fluir na moto
Quando o hardware chegar, a diferença entre o modo Demo e a ECU real é trocar uma camada de transporte — a serial no lugar do simulador. Todo o resto do Tuner já foi exercitado.
De quebra, quem quiser conhecer o Tuner antes de comprar qualquer coisa vai poder abrir o modo Demo e mexer em mapas à vontade. Test drive de software, sem moto.
O bootloader também tem contrato
No mesmo espírito, o protocolo de atualização de firmware via USB
(bootloader) virou crate compartilhado com spec própria — e o CI compila
todos esses crates de protocolo pro alvo ARM real (thumbv7em), não
só pro PC. Se alguém escrever código de protocolo que não roda no
microcontrolador, o build quebra na hora.
Por que isso importa
O firmware core está em 500 testes; o Tuner em 60 testes Rust + 165 de UI. Mas o número que interessa é outro: a distância entre “hardware chegou” e “primeira calibração de verdade” encolheu pra quase só fio e conector. Diagnóstico, protocolo, ferramenta de calibração — tudo isso já existe, conversa entre si e é testado junto a cada commit.
ECU standalone se compra pela potência que libera, mas se confia pelo que ela te conta quando algo está errado. Essa parte está pronta.