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

Question

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

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

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

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

Answer 1

Последовательный опыт работы с UART, а не исследование.

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

1. SOFrame
2. (длина может быть)
3. данных (адрес, в, из, типа, последовательность #, опкода, байтов и т.д.)
4. CheckCode
5. EOFrame

Неизменно, полученные "FAMEs" включают в себя:

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

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

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

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

CRC Рекомендовать более 2-х байт. Короткий чек-код не улучшает меня. Я бы предпочел не иметь чек-код, чем 1-байтовый. Если ошибки происходят время от времени, они могут быть пойманы чек-кодом, я хочу что-то лучше, чем 2-байтовый 99.999% времени, мне нравится 4-байт 99.99999997%

EOF так полезно!

КСТАТИ: Если протокол ASCII (вместо двоичной), рекомендуют не использования cr или lf как EOFrame. Может быть, использовать их только вне кадра, если они не являются частью сообщения.

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

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