Dica de protocolo para Rx Tx

[ÁgioFelipe]

Amigos, estou comunicando dois dispositivos do seguinte modo:

uC <--> MODEM <----Canal-----> MODEM<--->uC

Onde a comunicação entre o uC e o MODEM é via porta serial, enviando pacotes de apenas 8 bits.

Saberiam me informar algum protocolo que eu possa implementar para evitar que esses bytes cheguem com erro ao seu destino?

[Rodrigo_P_A]

Você tem que implementar várias coisas, vou dar um exemplo simples

Se você quiser enviar dados binários por exemplo:
Start byte - exemplo 01
Stop byte - exemplo 02
Mark byte - exemplo 03 -
se enviar 03 04 = 01
se enviar 03 05 = 02
se enviar 03 06 = 03

para que serve o mark byte? Se você quer mandar dados binários, vc sinaliza com ele se for enviar um dado reservado (start/stop/mark)

Exemplo de dado que vc quer enviar: 01 02 03 00 09 10 11 12

Faça uma rotina que vai transformar em:
01 - start
03 - mark
04 - dado 02
03 - mark
06 - dado 03
00
09
10
11
12
02 - stop

e crie uma rotina que receba e conforme for recebendo monte um buffer retirando o start/stop e mark bytes

Preveja os problemas abaixo:
- preveja em seu protocolo a confirmação do recebimento do dado
- preveja em seu protocolo timeout para receber as confirmações
- aguarde sempre a resposta, retransmita se passar X tempo... depois de Y tentativas informe erro

não tem mágica, existem várias formas, mas é mais ou menos isso que você tem que fazer.

Do jeito que estou informando, os bytes 01 02 03 são reservados, ou seja qdo vc recebe, vc já sabe que é uma instrução para o protocolo, eles nunca fazem parte dos dados. O problema é que se tiver uma repetição longa de bytes reservados, eles serão enviados de 2 em 2 (2 bytes para informar 1, pois será enviado o mark byte + mark info byte).

Existem outras formas de fazer, informando o tamanho do dado por exemplo e enviando o pacote. sem start/stop

Dá pra fazer start/stop por temporização ( eu num gosto).

[ÁgioFelipe]

Poisé, mas será se já não existe isso feito? Estou achando q vou reinventar a roda.

[pamv]

A porta serial do MCU já usa algo como o controle mostrado e a paridade (https://en.wikipedia.org/wiki/Parity_bit). O que você pode adicionar é algo como um checksum para blocos de bytes.

Editando:
Outra coisa que esqueci, os modems que você usa não possuem nenhum tipo de ECC (error correction code) ? Normalmente isso vem embutido neles. Consulte o manual

[Rodrigo_P_A]

Poisé, mas será se já não existe isso feito? Estou achando q vou reinventar a roda.

Pronto, MODBUS, num lembro de mais nenhum

[pamv]

Eu acho que todos os modems modernos possuem mecanismo automático de detecção e correção de erro que pode ser ativado ou desativado. Procurando agora achei os comandos do USR Robotics

Código: Selecionar todos

&M0 AT&M0 Desativar a correção de erros em transferências a 1.200 bps e mais rápidas
   
&M4 AT&M4 Permitir a correção de erros V.42 ou MNP em transferências a 1.200 bps e mais rápidas



Eu não achei nenhum modem digital no google para verificar se eles também fazem isso

[Rodrigo_P_A]

Se for para ser robusto, tem que implementar um protocolo com verificação de chegada, tratamento de dados, timeouts, etc..., mesmo se fosse para transportar via TCP em uma rede local cabeada. Essa é a minha opinião.

[pamv]

Esses modems de acessar provedor por linha telefônica se encarregavam de cuidar disso, só se a linha era muito ruim é que eles falhavam e avisavam o sistema operacional, isso tudo na camada 2.

[ÁgioFelipe]

A porta serial do MCU já usa algo como o controle mostrado e a paridade (https://en.wikipedia.org/wiki/Parity_bit). O que você pode adicionar é algo como um checksum para blocos de bytes.

Editando:
Outra coisa que esqueci, os modems que você usa não possuem nenhum tipo de ECC (error correction code) ? Normalmente isso vem embutido neles. Consulte o manual

Os modems só aceitam 8N1, ou seja, sem paridade. Tbm não têm ECC.

[pamv]

Que modem são esses?
Aqueles digitais, sem linha telefônica no meio? Faz uns 20 anos que não lido com eles, na última vez que eu lidei, eu usava um par deles para conectar dois prédios separados por uns 90m tendo um unix de cada lado e usando SLIP e 9600 bps. Eu não lembro de ter erros nesse link a não ser quando um dos lados era ligado ou reiniciado.
Como é isso no seu caso?

[andre_luis]

mas será se já não existe isso feito? Estou achando q vou reinventar a roda.

De um modo geral, quanto maior a camada do protocolo, mais uma camada de vulnerabilidade, e também necessário mais uma camada de segurança a ser adicionada já que as coisas começam a ser padronizadas. Isso significa que se voce está numa camada bem baixa, programando em C baremetal por exemplo, não seria nada exotérico criar algo proprietário. Não é comum interoperabilidade nesse nivel, e com um grau de liberadade voce poderia não só se proteger de erros de comunicação devido ao meio, mas também contra reengenharia. Além das dicas de bytes de verificação já mencionados (CRC, checksum, etc...) seria o caso de se considerar também por exemplo um indexador para os bytes recebidos, de modo que fosse esperado no byte seguinte um certo valor que se não estivesse correto seria indicador de erro; a forma mais direta seria incrementar uma contagem qualquer...enfim, existem muitas possibilidades.

[ÁgioFelipe]

Implementei no arduino e parece que tá dando certo, rsrsrsr
Mas deu trabalho por não ter uma forma de depurar, a única ferramenta que tinha era o printf no monitor serial, algumas vezes tive q sair espalhando vários pelo meu código: printf("passou aqui"), printf("passou acola") kkk

O tempo q se ganha por ter funções de mais alto nível em relação ao pic e maior facilidade no hardware se perde por não poder depurar corretamente.

[pamv]

Você implementou a comunicação ou o protocolo ? O seu problema era depurar o programa de comunicação no PIC ou corrigir erros?

[ÁgioFelipe]

Você implementou a comunicação ou o protocolo ? O seu problema era depurar o programa de comunicação no PIC ou corrigir erros?

Implementei o protocolo e coloquei para funcionar com os modems.
Meu problema era depurar no arduino!

[pamv]

Qual protocolo você adotou?