Mensagens UART com delimitação e timeout

A UART entrega bytes em sequência. Embora cada byte viaje em um quadro UART, esses quadros não informam onde começa ou termina uma mensagem da aplicação.

Por exemplo, os bytes podem chegar como Q, :, 0, 1, \n, R, :, 0, 1, \n. Sem uma regra do protocolo, o firmware vê apenas um fluxo contínuo. Neste tutorial, a regra de fronteira será: LF (\n) termina uma mensagem.

Use um contrato textual pequeno e restrito:

• Pedido: Q:01\n
• Resposta: R:01\n

Q significa pedido e R significa resposta. O caractere : ocupa sempre a segunda posição. Os dois últimos caracteres são o identificador da tentativa, sempre com dois algarismos.

A resposta repete o identificador do pedido: R:01 corresponde a Q:01. Durante os ensaios, não reutilize um identificador em outra tentativa. Isso permite distinguir uma resposta antiga da resposta esperada.

O identificador liga pedido e resposta; o LF cria a fronteira entre as linhas.

No protocolo, o LF é o único terminador. Muitos monitores seriais enviam CRLF: nesse caso, o CR (\r) é ignorado e o LF (\n) conclui a mensagem.

• Q:01\n → linha completa.
• Q:01\r\n → a mesma linha completa.
• Q:01\r → ainda incompleta.
• Q:01 → ainda incompleta.

Ignorar CR impede que CRLF seja interpretado como duas mensagens. Um CR isolado nunca fecha a linha.

A UART pode entregar uma linha em vários momentos. Em vez de esperar os próximos bytes, o loop() lê apenas o que já está disponível, guarda os caracteres de conteúdo e volta às outras tarefas.

Use um vetor de 16 posições: linha[0] até linha[14] recebem no máximo 15 caracteres; linha[15] fica reservado para \0. O índice n informa quantos caracteres de conteúdo já foram armazenados.

LF ('\n') pertence à mensagem recebida como delimitador, mas não é armazenado como conteúdo. Ao recebê-lo, o firmware escreve \0 no vetor para que a linha possa ser tratada como texto em C.

\0 não é um byte que o protocolo envia para terminar a linha: ele existe apenas na representação local. Já CR ('\r') é ignorado, conforme o contrato do passo anterior.

Trecho para inserir em um sketch; processLine() representa o processamento da linha completa.

Receber LF só informa que uma linha terminou. Ainda falta decidir se os bytes formam uma mensagem permitida pelo contrato.

Neste tutorial, o conteúdo de uma mensagem tem exatamente quatro caracteres:

• Q:01 — pedido
• R:01 — resposta

O primeiro caractere só pode ser Q ou R; o segundo é obrigatoriamente :; os dois últimos são algarismos do identificador. O LF chega depois desses quatro caracteres e não faz parte do conteúdo armazenado.

Assim, Q:01 pode seguir para tratamento. Já Q:01X, Q:0, Z:01 e uma linha vazia chegam completos ao LF, mas não são mensagens válidas.

A validação confere primeiro o tamanho exato e só então acessa os campos fixos. Depois, verifica o tipo, o separador e cada algarismo do identificador.

Nada deve ser executado enquanto os caracteres ainda chegam. Somente a rotina chamada após o LF recebe uma linha candidata.

Troque a chamada feita quando chega LF por processarLinhaCompleta(linha, n). A função abaixo usa o tamanho recebido, não strlen(), e só produz efeito depois de uma validação completa.

Uma linha inválida é ignorada: ela não executa comando, não vira pedido e não representa resposta válida.

Trecho para chamar somente quando o receptor encontrar LF. Ele mantém o contrato Q:01 e R:01.

Complete a condição inteira que aceita somente um pedido ou resposta com os quatro bytes previstos. Ela deve rejeitar tanto Q:01X quanto Q:\0, mesmo que o começo pareça correto.

O vetor de 16 posições aceita no máximo 15 caracteres de conteúdo; a última posição é reservada para o terminador local \0. Se chegar mais um caractere de conteúdo antes do LF, a linha inteira é inválida.

Não processe os 15 primeiros caracteres como se fossem uma mensagem. Eles podem ser apenas o prefixo de uma linha excessiva. Em vez disso, entre no estado DESCARTANDO: pare de gravar no vetor e ignore tudo até encontrar o próximo LF.

Trecho para integrar ao receptor incremental dos steps anteriores. Chame receberByte(Serial.read()) para cada byte disponível. A função de processamento recebe o vetor e o comprimento explícito, preservando a validação estrita do step anterior.

A comparação de limite ocorre antes da escrita, portanto nenhuma posição além de linha[15] é acessada.

Zerar indice ao detectar o excesso só invalida a cópia local. Isso não permite iniciar outra mensagem imediatamente: DESCARTANDO impede que o sufixo da linha longa seja tratado como um novo comando. Quando chega LF, processarLinhaCompleta() não é chamada para a linha excessiva; a próxima linha começa do zero.

Complete as lacunas que protegem o vetor e restabelecem a recepção somente após o delimitador. O caractere que excede o limite não é armazenado; a linha longa inteira não chega à validação.

Considere uma linha que já ocupou os 15 caracteres permitidos. Chega um 16º caractere, depois mais bytes, depois LF. Em seguida, chega Q:01\n, que cabe no vetor e respeita o formato do protocolo. Ordene os eventos.

Uma linha em montagem não pode ocupar o receptor para sempre. Use um timeout de montagem de 3 segundos, contado a partir do primeiro caractere de conteúdo.

A marca de início é registrada uma única vez. Cada byte posterior apenas completa a mesma linha: ele não reinicia o prazo. O caractere CR ('\r') continua ignorado e também não inicia nem prolonga a contagem.

Assim, enviar Q:01 muito lentamente por mais de 3 segundos não torna a mensagem aceitável só porque o LF chegou no final. Os 3 segundos facilitam os ensaios manuais no Monitor Serial; não são um valor universal para todo protocolo.

Verifique o vencimento em todas as passagens pelo loop(), inclusive quando Serial.available() é zero. Não use delay() nem espere em um laço pela chegada do próximo byte.

Quando o prazo vence, o conteúdo parcial é invalidado: zere indice, desative linhaAtiva e entre em DESCARTANDO. Nesse estado, os bytes são consumidos sem armazenamento até chegar LF. Esse LF recupera a fronteira entre linhas, mas não valida a mensagem que expirou.

A política para linha vazia continua a mesma dos steps anteriores: quando LF chega durante a recepção normal, processarLinhaCompleta(linha, indice) é chamado mesmo se indice for zero. A validação então rejeita a linha vazia sem efeito.

Acrescente o timeout ao receptor incremental dos steps anteriores. Mantenha o comprimento explícito ao entregar uma linha completa para a validação.

A saída da UART também usa um buffer finito. Antes de colocar uma mensagem curta nele, consulte o espaço livre com Serial.availableForWrite().

A regra é enviar a mensagem inteira somente quando houver espaço para todos os bytes dela. Se faltar espaço, não espere em um laço e não envie apenas o começo: mantenha uma única saída pendente e tente novamente na próxima passagem pelo loop().

Assim, enquanto a UART libera espaço, o firmware continua atendendo a recepção incremental, os timeouts e as demais tarefas.

Mantenha uma única mensagem pendente e chame atenderSaida() pelo fluxo principal a cada passagem do loop(). A string usa a mesma resposta R:01\n definida no protocolo.

Complete a condição que preserva a mensagem inteira. Se não houver espaço para os cinco bytes de R:01\n, a função retorna e deixa respostaPendente verdadeira para uma passagem futura do loop().

Uma tentativa usa um único pedido e tem três estados:

• LIVRE: não há tentativa ativa.
• ENVIO_PENDENTE: o pedido foi preparado e entrou na única fila de saída, mas ainda não foi aceito pelo buffer de transmissão.
• AGUARDANDO: os cinco bytes de Q:nn\n já foram aceitos pelo buffer; agora existe uma resposta pendente.

O resultado final é SUCESSO ou SEM_RESPOSTA, e então o estado volta para LIVRE.

No Monitor Serial, Q:01 é um comando local de teste: ele solicita uma tentativa. O Uno transmite Q:01\n; depois, você digita R:01\n como interlocutor simulado. Use um identificador ainda não reutilizado em cada ensaio.

O prazo de resposta começa somente após Serial.write() aceitar todos os cinco bytes de Q:nn\n: Q, :, dois algarismos e LF. Enquanto a fila ainda não puder aceitar o pedido, ou enquanto o buffer UART não tiver espaço, a tentativa não passa a aguardar resposta.

O instante registrado inclui o tempo de transmissão física que ainda falta e o tempo para o interlocutor responder. Colocar bytes no buffer não prova que eles já chegaram ao outro lado.

Este bloco substitui a saída fixa do passo anterior por uma única fila que também identifica o tipo da mensagem. Ele pressupõe que formatoValido() e a recepção incremental já existem.

Verifique o timeout de resposta em toda passagem pelo loop(), mesmo quando não chegou byte algum. Ao vencer, a tentativa recebe SEM_RESPOSTA e volta a LIVRE.

Uma linha só gera sucesso se já estiver completa e válida, a tentativa estiver em AGUARDANDO e os dois algarismos coincidirem com idEsperado. A recepção parcial continua sujeita ao timeout de montagem de 3 segundos implementado antes.

Use estas funções junto à fila de saída e ao receptor já construído. tratarLinhaCompleta() deve ser chamado somente depois do LF, com o comprimento explícito da linha.

Complete as transições que encerram uma tentativa. A primeira condição representa ausência de resposta após 10 segundos. A segunda registra sucesso apenas para uma resposta completa, válida e com o identificador esperado.

Uma resposta só representa sucesso quando três condições coincidem: existe uma tentativa em AGUARDANDO, os dois algarismos são iguais a idEsperado e o prazo de 10 segundos ainda não venceu.

Exemplo: se o Uno enviou Q:08\n, apenas R:08\n recebido a tempo encerra a tentativa com SUCESSO. Uma antiga R:07\n tem formato válido, mas é inesperada para a tentativa 08.

Use identificadores diferentes nos ensaios. Isso ajuda a rejeitar uma resposta antiga; não é uma garantia para uma sessão longa em que os identificadores sejam reutilizados.

Substitua as funções de timeout e de tratamento de linha do step anterior por estas versões. Elas preservam EstadoTentativa, ResultadoTentativa, estadoTentativa, resultadoTentativa, inicioResposta, idEsperado e PRAZO_RESPOSTA_MS.

No ramo que trata LF do receptor, faça a limpeza do estado de montagem antes de chamar tratarLinhaValida(). Isso permite que um timeout de resposta detectado nessa função diferencie uma linha completa de uma linha ainda parcial.

Chame verificarTimeoutResposta(millis()) em toda passagem pelo loop(), como no step anterior. Se ela vencer enquanto linhaAtiva for verdadeira, encerrarSemResposta() limpa o conteúdo parcial e coloca o receptor em DESCARTANDO. Os bytes restantes são consumidos até LF, sem serem interpretados como a próxima mensagem.

resultadoTentativa é alterado somente em transições: para SUCESSO ou SEM_RESPOSTA. Não envie continuamente textos como “aguardando” pelo loop(): mensagens repetidas podem ocupar o buffer de transmissão. Se você decidir exibir resultados, faça uma única emissão quando esse resultado mudar.

Use somente o Arduino Uno R3 conectado por USB ao computador. Não conecte dispositivos externos aos pinos 0 e 1: a ponte USB–UART e o Monitor Serial serão o interlocutor.

Os três blocos a seguir compõem um único sketch, na ordem apresentada. O comando local Q:nn inicia uma tentativa; o Uno transmite Q:nn\n. Somente R:nn\n, com o mesmo identificador e antes de 10 s, registra sucesso.

O LED integrado pisca enquanto há uma linha em montagem, descarte, envio pendente ou espera por resposta. Isso oferece uma evidência visual de que o loop() continua sendo executado.

Bloco 1 de 3 — coloque no início de um arquivo novo na IDE. A fila de saída guarda também o tipo da mensagem: somente uma saída marcada como SAIDA_PEDIDO pode iniciar o prazo de resposta.

Bloco 2 de 3 — continue imediatamente após o bloco anterior.

Bloco 3 de 3 — finalize o mesmo arquivo, grave no Uno e abra o Monitor Serial em 9600 baud.

Abra o Monitor Serial em 9600 baud. Para os casos usuais, selecione Nova linha (LF). No ensaio CRLF, selecione CR e LF. Aguarde cada resultado final antes de começar a próxima tentativa.

No teste parcial, há dois eventos independentes: após 3 s, a linha parcial expira e o receptor entra em descarte; o LF posterior apenas recupera a fronteira. A tentativa iniciada antes continua aguardando até receber a resposta correta ou vencer o prazo de 10 s.

Complete a condição que impede uma saída de diagnóstico de iniciar o prazo de resposta. O instante só deve ser registrado quando a mensagem transmitida for o pedido da tentativa que está em ENVIO_PENDENTE.