Diagnóstico de aquisição e falhas de comunicação

Uma leitura estranha não aponta automaticamente para uma causa. Antes de mudar código, cabos ou parâmetros, localize em qual camada do percurso o problema pode ter surgido.

Use este mapa: alimentação e referência → sinal físico → configuração da interface → transação → interpretação do dado → valor apresentado.

Cada camada deixa indícios diferentes. O objetivo inicial não é adivinhar: é escolher a próxima observação que elimine possibilidades.

Separe três coisas:

• Sintoma: o que foi observado. Ex.: “a tela mostra 0”, “não chegaram bytes” ou “a temperatura é implausível”.
• Hipótese: uma explicação possível. Ex.: entrada em 0 V, endereço I2C incorreto, bytes invertidos.
• Evidência: uma observação que pode apoiar ou enfraquecer uma hipótese. Ex.: medir a entrada, conferir a contagem de bytes ou comparar os bytes com um caso conhecido.

Um sintoma pode ter várias hipóteses. Portanto, evite mudar várias configurações ao mesmo tempo: se o resultado mudar, você não saberá qual alteração foi relevante.

Uma escolha inicial prática:

• Não há resposta, caracteres truncados ou quantidade inesperada de bytes: investigue configuração e transação antes de converter qualquer dado.
• Há resposta completa, mas o valor físico é incoerente: compare sinal ou referência e bytes brutos; o problema pode estar na cadeia elétrica ou na interpretação.
• Há bytes completos e coerentes, mas a conversão mostrada diverge do resultado esperado: concentre-se na montagem da palavra, sinal, máscara ou escala.

“Transferir algo” não confirma, por si só, que o dado representa uma medição correta.

Associe cada sintoma à camada que deve ser investigada primeiro. Considere que esta é apenas a primeira direção da investigação, não uma conclusão definitiva.

Uma investigação útil registra o bastante para comparar tentativas, sem transformar o diagnóstico em uma nova fonte de falhas. Para cada operação, anote: interface e dispositivo/canal, instante, estado da transação, quantidade de bytes recebidos, bytes brutos e, somente se a resposta estiver completa e aceita, o valor convertido.

O estado explica o que ocorreu; os campos numéricos mostram a evidência. Exemplo: I2C MCP9808 t=1250 ms estado=PARCIAL n=1 bruto=0x01 valor=indisponível.

Não invente informação ausente. Se nenhum byte chegou, bytes brutos e valor convertido são indisponíveis. Se chegaram menos bytes que o esperado, registre apenas os bytes efetivamente recebidos e não converta a resposta.

Exemplo de publicação limitada: a aquisição pode continuar em seu ritmo; o monitor recebe apenas um resumo periódico ou um evento novo.

Um código ADC repetidamente em 0 ou no máximo não condena o conversor sozinho. Localize primeiro o ponto em que a evidência deixa de ser coerente:

1. Meça a tensão de entrada em relação ao terra da montagem.
2. Confira a referência realmente usada pelo ADC.
3. Compare esses valores com o código bruto.

Entrada próxima de 0 V pode justificar código baixo; entrada próxima ou acima da referência pode justificar saturação alta. Se a tensão estiver dentro da faixa esperada, mas o código permanecer extremo, ainda há hipóteses sobre conexão, canal, referência ou aquisição a investigar.

Uma tensão contínua conhecida e compatível com a entrada é um teste de separação útil. Ela não precisa ser “perfeita”: basta conhecer seu nível por uma medição segura e mantê-lo estável durante a comparação.

Se essa tensão produz um código coerente, a cadeia de aquisição ganha evidência favorável; investigue então o sinal variável, sua faixa ou sua amostragem. Se ainda produz resultado incoerente, concentre a investigação na entrada, referência, canal ou configuração de aquisição.

O multímetro é apropriado para comparar níveis contínuos, como entrada e referência. Porém, seu valor médio não revela necessariamente pulsos, bordas, ruído rápido nem a integridade de uma comunicação digital.

Quando a hipótese depende de variação no tempo, o osciloscópio — se disponível — permite observar nível, variação e bordas. Compare a taxa de amostragem registrada com o comportamento esperado do sinal; uma variação aparente pode ser aliasing, mas exige evidência adicional.

Um indício de comunicação só ganha significado dentro da interface e da fase em que apareceu. Antes de mudar configuração ou fiação, registre o sintoma e escolha uma observação que separe hipóteses.

• UART: caracteres incoerentes sugerem configuração incompatível, como taxa ou enquadramento. Isso é diferente de mensagem incompleta ou de nenhum byte recebido.
• I2C: ACK e NACK pertencem a fases específicas da transação; ainda é preciso confirmar quantos bytes chegaram.
• SPI: transferir bytes mostra que o controlador gerou clocks e leu níveis em MISO. Não existe ACK padronizado que confirme a presença do periférico.

Uma resposta já validada na transação ainda precisa passar por três conferências antes de ser aceita como medida:

1. bytes brutos recebidos;
2. palavra digital montada a partir deles;
3. valor convertido para a unidade física.

Use uma resposta conhecida e compare cada etapa lado a lado. A primeira divergência orienta a investigação:

• bytes diferentes do vetor esperado: investigue antes da interpretação;
• bytes corretos, mas palavra errada: revise ordem dos bytes, máscara ou sinal;
• palavra correta, mas valor errado: revise escala, referência assumida ou cálculo numérico.

Uma resposta completa e um número plausível não provam, isoladamente, que a interpretação está certa. Aqui, considere que a quantidade de bytes já foi validada: o foco é não atribuir ao transporte um erro que está na conversão.

A montagem da palavra e a conversão para temperatura são etapas distintas. Os sufixos .0f impedem divisão inteira e preservam a parte fracionária.

Uma leitura não é apenas um número. Para apresentá-la com segurança, mantenha três informações separadas:

• valor: resultado numérico da última leitura aceita;
• amostraValida: informa se já existe uma amostra aceita;
• instanteAceito: marca de tempo da última atualização aceita.

Assim, 0 continua sendo uma medição possível. Ele não precisa significar “não recebi nada”.

Use o limite de idade adequado à aplicação. Por exemplo, uma amostra pode ser considerada atual por até 2 segundos. A idade é calculada a partir da última leitura aceita, não do início da tentativa atual.

A tentativa em andamento ou recém-falha tem seu próprio estado. Ela não apaga, não valida novamente e não rejuvenesce a amostra anterior. Portanto, uma falha às 11 900 ms não torna atual uma amostra aceita às 9 000 ms.

Trecho para estudar: valor, amostraValida e instanteAceito só mudam depois que a resposta passa pelos critérios de aceitação. O estado da tentativa muda separadamente.

Uma operação de leitura precisa terminar em sucesso ou em falha explícita. Defina quatro elementos:

• prazo por tentativa: quanto tempo uma tentativa pode permanecer em andamento;
• máximo total de tentativas: inclui a primeira tentativa;
• intervalo entre tentativas: espera antes de repetir após uma falha;
• estado final de falha: destino quando o limite se esgota.

Use uma convenção sem ambiguidade: MAX_TENTATIVAS = 3 significa, no máximo, as tentativas 1, 2 e 3. Se a terceira não for aceita, a operação termina em FALHOU.

O contador pertence à operação em curso. Ele é zerado quando um evento explícito solicita uma nova leitura, e não a cada passagem pelo loop(). Sucesso ou falha encerram a operação atual.

Neste exemplo, a comunicação segue uma arquitetura por consulta: iniciarConsulta() dispara a solicitação e retorna rapidamente; consultarResposta() informa depois se ela está pendente, completa ou inválida.

A primeira tentativa começa diretamente quando ocorre o evento. Somente depois de uma tentativa inválida ou vencida é aplicado INTERVALO_MS antes da próxima. Assim, o loop() continua atendendo as demais tarefas entre consultas e entre tentativas.

Este modelo exige que a interface, a biblioteca ou uma camada já existente no firmware realmente ofereça esse comportamento. Em uma API exclusivamente síncrona, use apenas um timeout documentado e reconheça que a chamada ocupará o processador até retornar.

Esqueleto para estudar. Como consultarResposta() não informa o instante em que a resposta chegou, uma resposta observada depois do prazo é rejeitada. O prazo é verificado antes de aceitar COMPLETA.

Complete o trecho derivado da máquina de estados. As lacunas devem: liberar a repetição após o intervalo, detectar o prazo da tentativa atual, reconhecer o limite total e realmente agendar a próxima tentativa quando ainda houver uma disponível.

Uma recuperação começa pela camada já diagnosticada. Reiniciar uma interface pode ser apropriado diante de uma falha de transação, mas não corrige uma máscara, ordem de bytes, sinal ou escala errada no firmware.

Antes de agir, encerre a tentativa que falhou. Bytes parciais e respostas chegadas depois do prazo não podem ser promovidos a resposta da próxima tentativa. Trate ou descarte esses dados conforme as regras da interface e preserve a última amostra aceita com seu instante original.

Organize o procedimento para uma tentativa que não recebeu todos os bytes esperados. Considere que já existe uma camada diagnosticada e uma ação de recuperação documentada para ela.

Um teste de falha útil é reversível: ele cria uma condição prevista, permite observar a reação do firmware e permite restaurar a operação sem expor a montagem a uma condição elétrica perigosa.

Planeje antes de testar:

1. Hipótese: o que a ausência ou a resposta incompleta deve acionar?
2. Condição inicial: qual é a última amostra válida e seu instante?
3. Uma alteração: qual resposta será omitida ou truncada?
4. Resultado esperado: timeout, tentativas limitadas e estado de falha.
5. Critério de interrupção: quando parar e restaurar a condição normal?

Mude somente uma variável por teste. Assim, o resultado pode sustentar ou enfraquecer uma hipótese específica.

Você pode testar a lógica sem desconectar nada. Considere este caso apresentado:

• A última leitura aceita foi 24,50 °C no instante 10 000 ms.
• Cada tentativa espera no máximo 50 ms por 2 bytes.
• A política permite 1 tentativa inicial + 2 novas tentativas.
• Uma leitura só é aceita com exatamente 2 bytes.

Durante o teste, a sequência simulada é: nenhuma resposta; 1 byte; nenhuma resposta. Depois, a resposta normal de 2 bytes é restaurada.

Caso integrado: temperatura por I2C

Uma aplicação usa um MCP9808. Às 10:00:00, a última leitura aceita foi 25,00 °C. Às 10:00:10, uma nova aquisição falhou: cada tentativa recebeu NACK na seleção do endereço; portanto, não houve bytes de temperatura nem conversão válida.

A política já definida permite 3 tentativas no total (a inicial mais 2 novas), com prazo de 20 ms por tentativa e intervalo de 200 ms. Depois do terceiro NACK, o sistema entra em falha explícita.

A conexão do módulo foi conferida e restaurada somente com todas as fontes desligadas. Após religar, uma leitura nova foi aceita às 10:00:14. Seu trabalho é transformar esses fatos em uma conclusão rastreável — sem chamar a amostra de 10:00:00 de leitura atual durante a falha.

Compare os registros pelo que eles realmente comprovam. NACK durante a seleção do endereço é um indício de transação sem resposta naquele ponto; ele não autoriza inventar bytes, converter um valor ou substituir a ausência por zero.

A intervenção é uma hipótese testada, não a prova final. A evidência de recuperação é a nova transação completa aceita às 10:00:14. Durante a falha, a aplicação pode preservar 25,00 °C como histórico identificado, mas deve informar que a última atualização aceita foi às 10:00:00 e que a tentativa atual falhou.