Простое надежное исправление ошибок при передаче ASCII по последовательному порту (RS485)

У меня очень низкоскоростное соединение для передачи данных через последовательный порт (RS485): фактическая скорость передачи данных 9600 бод составляет около 25% от этой.

Последовательная линия проходит через область чрезвычайно высокого ЭМИ. Пиковые колебания могут достигать 3000 кВ.

Я не в состоянии (пока) заставить изменить физический носитель, но мог бы легко предложить простую надежную схему прямого исправления ошибок. Схема должна быть легко реализована на микроконтроллере серии PIC18.

Идеи?


error-handling data-transfer rs485
person michael    schedule 15.07.2010    source источник
comment
Я разрабатываю с помощью устройств PIC18 и в настоящее время использую компилятор MCC18 и PICC18. Несколько недель назад я заметил, что заголовки периферийных устройств для PICC18 неправильно отображают библиотечный макрос Busy2USART() на бит TRMT вместо бита TRMT2. Это вызвало у меня сильные головные боли на короткое время, прежде чем я обнаружил проблему. Простой код:   -  person Nate    schedule 24.09.2010

Ответы (3)


arrow_upward
1
arrow_downward

Этот сайт утверждает, что использует Reed-Solomon на PIC18. Я никогда не использовал его сам, но, возможно, это может быть полезной ссылкой?

person owenmarshall    schedule 15.07.2010

arrow_upward
1
arrow_downward

Поиск алгоритма CRC, используемого в протоколе MODBUS ASCII.

person avra    schedule 02.09.2010

arrow_upward
0
arrow_downward

Я разрабатываю с помощью устройств PIC18 и в настоящее время использую компиляторы MCC18 и PICC18. Несколько недель назад я заметил, что заголовки периферийных устройств для PICC18 неправильно отображают макрос Busy2USART() на бит TRMT вместо бита TRMT2. Это вызвало у меня сильные головные боли на короткое время, прежде чем я обнаружил проблему. Пример, простая передача:

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

Когда макрос Busy2USART() был неправильно сопоставлен с битом TRMT, я никогда не ждал, пока байты покинут регистр сдвига, потому что я отслеживал неправильный бит. До того, как я понял неточный заголовочный файл, единственным способом, которым я смог успешно передать байт больше 485, было ожидание 1 мс между байтами. Моя скорость передачи была 91912, а задержки между байтами убили мою пропускную способность. Я также предлагаю реализовать средства обнаружения коллизий и контрольных сумм. Контрольные суммы дешевы, даже на PIC18. Если вы можете прослушать свои собственные передачи, сделайте это, это позволит вам быть в курсе коллизий, которые могут возникнуть из-за дублирования адресов в одном и том же цикле и неправильной синхронизации.

person Nate    schedule 24.09.2010