Опять UART, надоело городить самопальные протоколы Опции

[Tsvetik]

Нужно передавать массивы двоичных данных по UART между двумя устройствами.

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

Следовательно из 256 вариантов байта необходимо зарезервировать несколько значений для признаков начала (или конца) фрейма и, возможно, каких-то других управляющий символов.

Один из вариантов это /xon /xoff. Его минусы в том, что символы /xon /xoff могут встретиться в передаваемых двоичных данных и их надо экранировать. Плюс этого метода в том, что экранирование можно проводить "на лету" при приеме. Промежуточный буфер для этого не требуется.

Второй вариант использовать для кодирования двоичных данных некоторую кодировку. Например, BASE64 или семибитную кодировку, а старшие биты пристегивать отдельным байтом.
Тогда символы, не входящие в алфавит BASE64 или со взведенным старшим битом можно считать управляющими. На них можно повесить функции управления протоколом, начала-конца фрейма, повтора передачи, может-быть и адреса устройства и т.п. Обычно кодирование-декодирование требует промежуточного буфера и вносит дополнительные временные издержки.

Так вот, подскажите какие-нибудь популярные реализации логических протоколов поверх UART.
Необходимы легковесные протоколы, которые будут работать довольно быстро на Tiny AVR.

Да, желательно без 9-го бита UART, чтобы с PC было проще отлаживаться

Сообщение отредактировал Tsvetik - Mar 14 2016, 11:37

[Baser]

Ни то, ни другое - НИКОГДА не ссылаться на "промышленных автоматизаторов" в качестве хоть какого-то авторитета.

Тут я позволю себе обратить вминание на то, что это была моя личная точка зрения основанная на личном практическом опыте:

Но 99% протоколов промышленного применения, что я видел, ...

Я не претендую на истинность и не считаю себя большим авторитетом. Ну, да и ладно

Глупостей и ошибок всегда можно наделать до бесконечности и еще чуть чуть. Но разумных и продуманно-сбалансированных вариантов ничтожно мало

Вот с этим я совершенно согласен.

Ну так назовите этот самый "разумный". Или это недостижимая мечта вроде коммунизма?

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

Случай из жизни.
Лет 7 назад мы с коллегой решили разработать новый универсальный протокол для применения в приборах нашей фирмы
(для конкретной области применения, а не вообще),
написали свои пожелания, я все продумал, написал проект, обсудили, утвердили.
Я его даже реализовал в ОДНОМ макете, который не пошел дальше макета. И все, лежит, уже интегрированый в наши тестовые программы.
Всем замечательный протокол, очень гибкий. Но немного сложноват в реализации.
Так что мы так и применяем то, что уже применяли на фирме лет 20 - минималистический протокол с коротким фиксированным пакетом.
А где нужно больше данных гонять, начали применять по просьбе заказчиков MODBUS, хотя мне и сильно не нравиться его регистровая направленность.

Так что не скажу я вам, что ОБЯЗАТЕЛЬНО нужно изучать. Я просто по работе сталкивался то с одним, то с другим протоколом, так и нахватался отрывистых знаний.
Теоретического курса по протоколостроению никогда не слушал.