Diagnóstico de firmware temporizado

Antes de mudar o firmware, descubra em que etapa ele parou. O fluxo tem quatro etapas:

1. Compilação: o código é traduzido; erros apontam construções inválidas, nomes desconhecidos ou tipos incompatíveis.
2. Ligação: as partes já compiladas são combinadas; falhas indicam, por exemplo, uma definição prometida mas não encontrada ou duplicada.
3. Gravação: o programa gerado é transferido para o Uno pela conexão selecionada.
4. Execução: a placa inicializa e roda a versão que foi gravada.

Cada etapa exige uma evidência diferente. Um LED com comportamento inesperado só é evidência de execução; ele não explica um erro que impediu a compilação ou a gravação.

Você altera o código para mudar o ritmo do LED. A IDE mostra erro de gravação. Mesmo assim, o LED continua piscando como antes.

Qual é a conclusão mais bem sustentada?

Quando a IDE falhar, não comece pelo resumo final, como “erro ao compilar”. Leia o primeiro diagnóstico que aponta um arquivo, uma linha e um problema específico. Mensagens abaixo dele podem ser consequências do mesmo erro.

Siga este roteiro:

1. Localize a primeira linha relevante.
2. Abra o arquivo e a linha indicados.
3. Relacione o símbolo ou a construção ao código nessa posição.
4. Faça uma correção localizada.
5. Compile novamente antes de interpretar o restante.

Assim, você evita corrigir sintomas em cascata ou alterar nomes ao acaso.

O fluxo visual mostra por que a primeira mensagem específica deve guiar a investigação.

Nem todo símbolo não reconhecido tem a mesma causa. Use o contexto do arquivo, da placa selecionada e da linha indicada para separar hipóteses.

No Uno R3, símbolos como OCR1A, TCCR1B e TIMER1_COMPA_vect pertencem ao ambiente AVR. Se a placa selecionada não for compatível com AVR, esses nomes não representam o hardware selecionado. Volte à seleção da placa antes de editar o firmware.

Se a placa for o Uno R3 e apenas um nome próximo falhar, examine a grafia. OCR1AA não é um registrador válido: acrescentar ou remover um caractere pode ser a única correção necessária.

Um erro de ligação como “multiple definition of __vector_11” costuma indicar que duas partes do programa definiram a mesma rotina de interrupção. A causa pode estar em dois trechos do sketch ou em um arquivo incluído.

Não troque o nome do vetor apenas para fazer o erro desaparecer. Para a comparação A do Timer1 no Uno R3, o vetor continua sendo TIMER1_COMPA_vect. Procure todas as ocorrências de ISR( e deixe um único responsável por esse vetor. Se houver comportamentos necessários nas duas rotinas, reúna o registro mínimo de eventos em uma única ISR curta e deixe o processamento para o loop().

Mantenha somente uma definição para o vetor de comparação A do Timer1.

Após mudar uma grafia, uma inclusão ou uma definição duplicada, compile de novo imediatamente. Só depois avalie a próxima mensagem que permanecer. Uma correção localizada pode eliminar vários avisos derivados.

Use uma sequência curta de verificação:

1. Salve a alteração mínima.
2. Confirme que a placa correta continua selecionada.
3. Compile.
4. Se houver erro, leia novamente o primeiro diagnóstico relevante.

Enquanto a compilação falha, não investigue o comportamento da placa: a nova versão ainda não está pronta para ser gravada.

Um caso reproduzível é uma receita de teste: outra execução, nas mesmas condições, deve permitir comparar o resultado. Antes de remover ou alterar código, registre:

1. Versão do programa: preserve uma cópia da referência conhecida.
2. Placa e conexão: Uno R3, porta selecionada e cabo USB de dados.
3. Montagem: botão entre D2 e GND; LED externo com resistor em série entre D3 e GND.
4. Condição inicial: por exemplo, após reset e com o botão solto.
5. Sequência: ações e esperas na mesma ordem.
6. Esperado e observado: descreva o que deveria ocorrer e o que você realmente viu.

“Não funciona” não é reproduzível. Já “após reset, D13 alterna; após um pressionamento estável em D2, D3 troca de brilho” define uma sequência verificável.

Crie um sketch novo na sua IDE. Copie os três blocos a seguir no mesmo arquivo e nesta ordem. Esta referência mantém responsabilidades separadas:

• D2 recebe o botão com pull-up interno;
• D3 recebe PWM pelo Timer2;
• D13 alterna lentamente por comparação do Timer1;
• a ISR registra ticks e permanece curta;
• o loop() lê ticks como instantâneo protegido;
• Timer0 não é reconfigurado.

Compile e grave a referência antes de testar uma variante. Só compare o comportamento após a IDE confirmar a gravação.

Bloco 1 — cole no início do mesmo sketch.

Bloco 2 — cole logo após o bloco 1.

Bloco 3 — cole após o bloco 2. O sketch estará completo. Compile, grave e confira visualmente o resultado na sua montagem.

Faça a sequência sem Monitor Serial:

1. Pressione reset e aguarde cerca de 3 segundos.
2. Observe D13 e o brilho inicial de D3.
3. Pressione D2 e mantenha por tempo suficiente para o debounce.
4. Solte D2.
5. Pressione e solte novamente.

Registre observações, não causas. Exemplo útil: “referência; reset; D13 alternou visualmente; primeiro pressionamento mudou D3 para brilho alto; segundo pressionamento retornou ao brilho baixo”.

Ao investigar uma variante, mantenha a referência intacta e trabalhe em uma cópia. Retire ou neutralize uma função por vez, compile, grave e repita a sequência registrada.

Uma simplificação só é útil se o sintoma continuar e se as dependências do sintoma permanecerem. Se a pergunta é “D3 muda de brilho após D2?”, retirar temporariamente o Timer1 pode ser uma redução válida: botão e PWM continuam presentes. Remover a leitura de D2, porém, invalida a comparação, porque o evento que deveria provocar a mudança desapareceu.

Após cada alteração isolada, anote o que permaneceu, o que foi retirado e se o sintoma ainda ocorreu.

Uma marca de diagnóstico responde a uma pergunta delimitada: “a execução chegou até este ponto?” Escolha pontos que separem caminhos possíveis: antes e depois de uma chamada suspeita, na transição de estado ou na entrada e na saída de uma ISR.

No caso-base, reserve D7 para a marca. Não use D13, que já é a sinalização temporal, nem D3, que permanece sob PWM. Assim, o diagnóstico não disputa o pino cuja função você quer verificar.

Para observar um nível persistente por LED, desconecte o USB e monte um LED próprio em D7: D7 → resistor em série → ânodo do LED; cátodo → GND. Use corrente pequena, como nas práticas anteriores. Reconecte somente depois de conferir a montagem. Se tiver osciloscópio ou analisador lógico, também pode observar D7 diretamente com a ponta no pino e a referência do instrumento no GND da montagem.

No sketch de referência do step anterior, não copie outro setup() nem outro loop(). Faça somente estas alterações localizadas:

1. Perto das constantes já existentes, acrescente const uint8_t PINO_MARCA = 7;.
2. Dentro do setup() que já existe, acrescente a configuração de D7.
3. Dentro do bloco que trata um pressionamento estável, deixe D7 alto imediatamente antes da chamada real analogWrite(...) e baixo logo depois dela.

Esse primeiro teste usa uma chamada que realmente existe no caso-base. Ela normalmente retorna muito rápido: o LED em D7 pode não mostrar nada visível, mas um instrumento pode revelar um pulso. Em uma variante que contenha uma chamada realmente suspeita, use as mesmas duas marcas ao redor daquela chamada, sem alterar sua posição no fluxo.

Linhas para acrescentar ao sketch de referência. A segunda parte substitui somente a chamada analogWrite(...) que já está dentro de if (botaoEstavel == LOW).

A marca alta antes de uma chamada e baixa depois dela tem uma interpretação limitada, mas útil:

• D7 permanece alto: o fluxo alcançou a marca anterior, mas não alcançou a marca posterior durante o teste. A chamada pode estar bloqueada ou ter seguido um caminho que não retornou.
• Subida e descida em D7: o fluxo passou pela região observada. Isso não mede, por si só, o tempo exato da chamada.

Para marcar uma ISR, o princípio é o mesmo: coloque D7 alto na entrada e baixo antes de sair. Não use delay(), laços de espera nem uma marca baseada apenas em millis(). Se a hipótese for interrupções globais desabilitadas, uma observação dependente de serviços temporais pode falhar junto com aquilo que você tenta investigar.

Um LED parado é um sintoma, não um diagnóstico. Para separar causas, observe marcas em três regiões independentes:

• fluxo principal: uma marca breve em cada passagem relevante de loop();
• transição: uma marca somente quando o estado realmente muda;
• ISR: uma marca na entrada e outra na saída da rotina.

Compare essas marcas após uma sequência conhecida: reset, pressionar o botão, manter pressionado, soltar e aguardar. Uma hipótese ganha força quando explica o conjunto de evidências — não apenas uma saída imóvel.

Importante: o PWM é gerado pelo hardware. Um LED com brilho PWM pode continuar aceso mesmo se o loop() estiver bloqueado. Da mesma forma, o Timer1 pode continuar comparando enquanto sua ISR não é atendida.

Uma sequência conhecida também revela erros lógicos sem depender de “acontecer por acaso”. Suponha que, após reset, o firmware esteja em ESPERA e que um pressionamento de botão deva levá-lo a ATIVO.

No trecho abaixo, a condição pede simultaneamente botão pressionado e estado ATIVO. Como o botão é justamente o evento que deveria sair de ESPERA, essa transição nunca acontece. A marca do loop pode continuar normal; o que falta é a marca de entrada em ATIVO.

Trecho para inspecionar: o estado inicial é ESPERA.

Outro erro frequente preserva a condição correta, mas apaga o tempo decorrido. Se esta linha estiver dentro do trecho executado repetidamente enquanto o estado é AGUARDANDO, a referência é renovada antes de completar 500 ms. A condição temporal permanece falsa.

A evidência esperada é: o fluxo principal continua passando, mas a transição temporal não ocorre. Verifique se a marca de entrada no estado foi alterada uma única vez na transição, e não em toda passagem pelo estado.

Trecho para inspecionar: entradaEstado deveria representar o instante de entrada no estado.

Quando uma função deixa de responder, não suponha que a última linha alterada seja a causa. Faça uma auditoria dos escritores: para cada recurso, registre sua função esperada, todos os trechos que podem configurá-lo ou comandá-lo e quando isso acontece.

Um recurso pode ser um pino, um registrador ou um temporizador. Dois escritores podem parecer funcionar isoladamente, mas disputar o mesmo hardware ao longo da execução.

Use uma tabela curta para tornar concorrências visíveis. Inclua tanto chamadas da API quanto escritas diretas em registradores: elas podem controlar o mesmo hardware.

Este trecho reúne duas disputas. A primeira é de temporizador: após colocar o Timer1 em CTC, o programa espera PWM padrão no D9, que depende do Timer1. A segunda é de pino: o digitalWrite() repetido toma o controle digital do D3, que deveria permanecer sob PWM do Timer2.

Trecho para inspecionar; não o use como versão corrigida.

Uma variável é compartilhada quando a ISR e o loop() a leem ou escrevem. Antes de corrigir, faça uma auditoria curta: quem escreve, quem lê, qual é a largura do dado e qual operação precisa ser indivisível.

No Uno R3, uma leitura de 16 bits pode envolver mais de uma operação do processador. Também é composta a sequência “testar uma flag e depois limpá-la”. volatile mantém os acessos visíveis ao compilador, mas não impede uma ISR de ocorrer entre essas partes.

Trecho para analisar; não é necessário executá-lo agora.

Nem toda falha compartilhada é uma leitura de vários bytes:

• Leitura incoerente: uma cópia de dado largo mistura instantes. Use um instantâneo protegido.
• Flag perdida: o loop() vê pendente, mas a ISR pode definir a flag novamente antes de o loop() limpá-la. A transferência “copiar e limpar” deve ser indivisível.
• Flag agregada: várias ocorrências enquanto a flag já é verdadeira continuam parecendo apenas uma. Se a quantidade importa, registre-a em um contador.

A seção crítica deve conter somente a cópia ou transferência. Decisão, cálculos e comandos de saída ficam depois dela.

Uma transferência protegida consome a pendência sem apagar uma nova ocorrência que chegue no meio da operação.

Complete a proteção da cópia. Ela restaura o estado de interrupções que já existia antes do bloco, em vez de supor que elas estavam habilitadas. A proteção é curta; processar() continua fora dela.

Use uma cópia do caso-base, mantendo a versão conhecida sem alterações. Nesta variante, a gravação é confirmada pela IDE e, após reset, D13 alterna visualmente e D3 começa em brilho baixo.

Ao pressionar D2 e manter o botão pressionado, D3 não muda. Ao soltar D2, porém, D3 muda de brilho. D13 continua alternando durante toda a sequência.

Classifique primeiro: como a compilação e a gravação foram confirmadas, a evidência aponta para comportamento em execução. A continuidade de D13 também torna menos provável atribuir o sintoma ao Timer1. Antes de editar, reproduza a mesma sequência e registre exatamente em qual ação D3 muda.

Crie uma cópia do sketch de referência e substitua seu conteúdo por esta variante completa. Ela é intencionalmente defeituosa, mas compila e pode ser gravada no Uno R3. Use a montagem já conhecida: botão entre D2 e GND e LED externo com resistor em D3. Não altere nada antes de executar a sequência da tela anterior e conferir o comportamento.

Salve a alteração mínima, compile e grave novamente. Só compare a versão corrigida depois da confirmação de gravação da IDE. Repita a sequência idêntica: reset; aguarde alguns intervalos; pressione D2; mantenha pressionado; solte; aguarde novamente.

Preencha a matriz no seu registro local. “D13 alternou visualmente” e “D3 pareceu manter brilho” são observações. “O intervalo é preciso” e “o PWM tem certa frequência” não são conclusões verificadas apenas olhando LEDs.