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

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

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

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

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

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

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

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

Например, начало/конец сообщения обозначить 2-3 символами. И только эта последовательность будет началом/окончанием сообщения. Все символы, входящие в эти последовательности, по отдельности или в другом порядке - есть данные.
Управление АТ-командами - вот пример. Начало всегда АТ, а окончание LF, CR.

Те же N символов могут встретиться и в двоичных данных.
Например, надо передать AT команду в которой содержится другая AT команда

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

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

За WAKE спасибо.



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

Wake + Ридико Леонид Иванович + любой поисковик

Что вы называете "экранировать", не знаю, но для выделения уникального кода для управления применяется метод байт-стаффинга (byte stuffing).
Но отлаживаться с ним неудобно.

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

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

В 8b/10b кодировании есть признаки старта / стопа сообщения и синхронизирующие сообщения. Там это сделано для того чтоб подстраивать PLL для извлечения синхросигнала из данных, и получаем сигнал из неповторяющихся длинных последовательностей из "1" или "0".
Но этот принцип можно использовать для выбора протокола и по UART.
За счёт избытоного кодирования, все вариации восьмибитных данных закладываются внутрь 10 битных посылок. У нас появляются никогда не встречаюся комбинации, в них и вкладываются служебные признаки.
Удобно ли конкретно этот протокол, вкладывать в скорости UART - не пробовал, всё таки разработан он немного для других вещей.

Байт-стаффинг и есть экранировать иначе, escape sequence

Тайм-ауты нафиг. Медленно и не хочу зависимость от таймера.

Ну так типовая структура любого протокола (набор полей):
Стартовый байт
Поле адреса
Поле длины данных
Поле данных
Поле CRC

На все это накладываете байт-стаффинг для стартового байта.
Дальше просто вариации из вышеперечисленного.

Но 99% протоколов промышленного применения, что я видел, не применяют байт-стаффинг
и используют тайм-ауты

Людоеды племени умба-юмба не используют не только таймауты, но и вообще промышленные применения. Темные люди , как и 99% "промышленных автоматизаторов" .
Ну а таймауты нужны В ЛЮБОМ случае. При том-же байтстаффинге для отработки ошибок использовать таймаут, как аварийное завершение фрейма и по нему-же выброс мусора.

Да вот что-то не нравится мне эта схема вот чем:
Длина идет не первым байтом. Если МК с DMA, то нужно будет несколько входов в обработчик прежде чем можно будет включить DMA.

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

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

Сивольные это не обязательно HEX. Можно так-же легко и 3 байта четырьмя символами в стиле UUE, или еще более плотно упаковать.



Могу Вас огорчить до "первого байта" Вы с удручающей вероятностью В РЕАЛЬНОЙ ЖИЗНИ сначала отгребете еще мусора. Так что забудьте о том, что есть какой то "первый байт".

Любите вы, zltigo, туману подпустить в витиеватой форме.
Я вот даже не понял, то ли мне улыбаться надо, то ли обижаться


Я не имел ввиду жесткий порядок полей.
Встречал всякие варианты.
И первым идет адрес (для мультимастер шины и фиксированной длине пакета)
И первым идет длина пакета (для переменной длины пакета и удобства применения ДМА)
Вариантов море.

Если начнете изучать различные стандартные протоколы,
то тоже подивитесь разнообразию вкусов разработчиков...


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

Первый байт фрейма. Считайте, что мусор из приемника уже вычищен, а начало фрейма найдено. Чтобы не было необходимости долго побайтово вычитывать заголовок фрейма, хорошо бы, чтобы длина была как можно ближе к началу фреймаю. В идеале закодирована в первом байте.




Ну дайте хоть названия-то этих стандартных протоколов. Что изучать, что гуглить?