Какой тип кадрирования использовать в последовательной связи

Какой предпочтительный метод кадрирования/синхронизации в канале последовательной связи?

  • кадрирование с помощью SOF и экранирование последовательностей, как в HDLC?
  • полагаться на использование заголовка с информацией о длине и CRC?

Это встроенная система, использующая передачу данных DMA из UART в память. Я думаю, что метод кадрирования с SOF наиболее привлекателен, но, может быть, другого достаточно?

У кого-нибудь есть плюсы и минусы этих двух методов?


uart serial-communication
person user2479653    schedule 12.06.2013    source источник

Ответы (1)


arrow_upward
6
arrow_downward

Следование основано на серийном опыте UART, а не на исследованиях.

Я обнаружил меньше проблем со связью, когда включено следующее - или, другими словами, выполняйте как SOF/EOF, так и (длина - возможно)/checkcode. Рамка:

  1. SOFrame
  2. (длина может быть)
  3. Данные (адрес, кому, откуда, тип, номер последовательности, код операции, байты и т. д.)
  4. Контрольный код
  5. EOFrame

Неизменно полученные «славы» включают:

  1. хорошие - без проблем.
  2. Повреждено из-за того, что отправитель не отправил полное сообщение (оно зависло, выключено или прервало передачу при включении питания) (получатель должен таймаутить устаревшие неполные сообщения).
  3. Поврежден из-за шума или помех при передаче. (ошибки кадрирования байтов, четность, неверные данные)
  4. Поврежден из-за того, что приемник запускается в середине отправленного сообщения или отсутствует несколько байтов из-за переполнения входного буфера.
  5. Совместные столкновения автобусов.
  6. Перерыв - это законно в вашей системе?

Какой бы фрейм вы ни использовали, убедитесь, что он устойчив к этим типам сообщений, быстро проверяет #1 и быстро идентифицирует 2-5 и готов к следующему фрейму.

SOF имеет огромное преимущество: его легко начать заново, если приемник потерян из-за предыдущего дерьмового кадра и т. д.

Длина — это хорошо, но ИМХО наименее полезно. Это может ограничить пропускную способность, если длина должна быть в начале сообщения. Некоторые операции с малой задержкой просто не знают длину, прежде чем они будут готовы начать передачу.

CRC Рекомендуется более 2 байт. Короткий контрольный код для меня недостаточно улучшает ситуацию. Я бы предпочел не иметь контрольного кода, чем 1-байтовый. Если время от времени возникают ошибки, их можно поймать только с помощью контрольного кода, я хочу что-то лучше, чем 2-байтовый 99,999% времени, мне нравится 4-байтовый 99,99999997%

EOF очень полезен!

Кстати: если ваш протокол ASCII (вместо двоичного), рекомендуется не использовать cr или lf в качестве EOFrame. Возможно, используйте их только вне кадра, где они не являются частью сообщения.

Кстати 2: Если ваш приемник может автоматически определять скорость передачи, это избавляет от многих проблем с настройкой.

BTW3: отправитель может рассмотреть возможность отправки байта «ничего» (до SOF), чтобы обеспечить правильную синхронизацию SOF.

person chux - Reinstate Monica    schedule 19.06.2013
comment
Несоответствие скорости передачи, бит на слово, четность, неожиданные уровни сигнала также вызывают проблемы. - person chux - Reinstate Monica; 11.08.2016