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

[Tsvetik]

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

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

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

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

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

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

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

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

[iosifk]

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

....

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

Стандартно либо передаете данные символьными кодами. А возврат каретки и перевод строки - это конец сообщения. Медленно, т.к. один байт передается двумя посылками, но просто... И годится любая терминалка на хосте...
Либо байт-стаффинг. Например WAKE от Ридико... Исходники и описания Леонид выложил...
Делать бит-стаффинг нет смысла, т.к. сдвигать массив данных на микроконтроллере долго...

[jcxz]

Делать бит-стаффинг нет смысла, т.к. сдвигать массив данных на микроконтроллере долго...

Это смотря какой микроконтроллер....
Недавно делал опцию отображения содержимого LCD 320x240x4bpp на МК в окно приложения под виндой. Соответственно - периодическая передача содержимого видеоОЗУ (по обновлению оного) в комп по
USB.
Просто гнать массив - довольно накладно получалось - порядка ~40кБ. А картинка на LCD - это обычный юзер-интерфейс без пиксельной графики - результат вывода текста + линии/многоугольники и т.п.
Сделал сжатие картинки на лету на МК - стало гораздо бодрее
Траффик упал в неск. раз и МК не помер. Ресурсов это заняло немного. А сжатие - сплошные манипуляции с битами и преобразование в битовый поток.
Хотя МК канеш не AVR - LPC4370 с тактовой до 204МГц

Обычно для простейших протоколов применяют разделение пакетов по тайм-аутам.
Самый простой и удобный метод.

Годится только для "железного" UART, коих на ПК практически не осталось.
Как только пропускаем эти пакеты через UART-USB - все ваши разделения идут лесом.
А если автор захочет этот поток например через GPRS-канал пропустить с его непредсказуемыми задержками???......

[zltigo]

Сделал сжатие картинки на лету на МК - стало гораздо бодрее

Ну экраны с пользовательскими интерфейсами жать на лету с очень заметным эффектом можно очень простыми алгоритмами ввиду офигительной избыточности.