Correção de erros simples e robusta para transmissão de ascii via serial (RS485)

Question

Eu tenho uma conexão de dados serial de velocidade muito baixa (RS485):9600 BAUD A taxa de transmissão de dados é de cerca de 25% disso.

A linha serial está passando por uma área de EMR extremamente alta.As flutuações de pico podem chegar a 3.000 KV.

Não estou (ainda) em posição de forçar uma mudança no meio físico, mas poderia facilmente oferecer a implementação de um esquema simples e robusto de correção direta de erros.O esquema precisa ser fácil de implementar em um micro da série PIC18.

Ideias?

Answer 1

Este site afirma implementar o Reed-Salomon no PIC18.Eu nunca usei isso sozinho, mas talvez possa ser uma referência útil?

Answer 2

Pesquisar por algoritmo CRC usado no protocolo Modbus ASCII.

Answer 3

Desenvolvo com dispositivos PIC18 e atualmente utilizo os compiladores MCC18 e PICC18.Percebi há algumas semanas que os cabeçalhos periféricos do PICC18 mapeiam incorretamente a macro Busy2USART() para o bit TRMT em vez do bit TRMT2.Isso me causou grandes dores de cabeça por pouco tempo antes de descobrir o problema.Exemplo, uma transmissão simples:

putc2USART(*p_value++);
while Busy2USART();
putc2USART(*p_value);

Quando a macro Busy2USART() foi mapeada incorretamente para o bit TRMT, eu nunca esperei que os bytes saíssem do registrador de deslocamento porque estava monitorando o bit errado.Antes de perceber o arquivo de cabeçalho impreciso, a única maneira de transmitir com êxito um byte acima de 485 era esperar 1 ms entre os bytes.Minha taxa de transmissão era 91912 e os atrasos entre os bytes mataram minha taxa de transferência.Sugiro também implementar um meio de detecção de colisões e somas de verificação.Checksums são baratos, mesmo em um PIC18.Se você conseguir ouvir suas próprias transmissões, faça-o, pois isso permitirá que você esteja ciente de colisões que podem resultar de endereços duplicados no mesmo loop e horários incorretos.