[Tsvetik 0]

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

 

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

 

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

 

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

 

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

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

 

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

Необходимы легковесные протоколы, которые будут работать довольно быстро на Tiny AVR.

 

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

Изменено 14 марта, 2016 пользователем Tsvetik

[АлександрК 0]

... символы ... могут встретиться в передаваемых двоичных данных и их надо экранировать.

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

Управление АТ-командами - вот пример. Начало всегда АТ, а окончание LF, CR.

[Tsvetik 0]

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

Управление АТ-командами - вот пример. Начало всегда АТ, а окончание LF, CR.

 

Те же N символов могут встретиться и в двоичных данных.

Например, надо передать AT команду в которой содержится другая AT команда

Изменено 14 марта, 2016 пользователем Tsvetik

[iosifk 3]

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

 

....

 

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

Необходимы легковесные протоколы, которые будут работать довольно быстро на Tiny AVR.

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

Либо байт-стаффинг. Например WAKE от Ридико... Исходники и описания Леонид выложил...

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

[Tsvetik 0]

За WAKE спасибо.

 

 

Изменено 14 марта, 2016 пользователем Tsvetik

[iosifk 3]

А это где посмотреть?

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

 

[Baser 5]

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

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

Но отлаживаться с ним неудобно.

 

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

Самый простой и удобный метод.

 

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

Правда, хороший самопальный протокол можно придумать только при достаточном опыте работы и предварительном написании кучи плохих самопальных протоколов :)

[McSava 0]

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

Но этот принцип можно использовать для выбора протокола и по UART.

За счёт избытоного кодирования, все вариации восьмибитных данных закладываются внутрь 10 битных посылок. У нас появляются никогда не встречаюся комбинации, в них и вкладываются служебные признаки.

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

[Tsvetik 0]

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

Но отлаживаться с ним неудобно.

 

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

Самый простой и удобный метод.

 

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

Правда, хороший самопальный протокол можно придумать только при достаточном опыте работы и предварительном написании кучи плохих самопальных протоколов :)

 

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

 

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

 

 

 

 

[Baser 5]

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

 

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

Ну так типовая структура любого протокола (набор полей):

Стартовый байт

Поле адреса

Поле длины данных

Поле данных

Поле CRC

 

На все это накладываете байт-стаффинг для стартового байта.

Дальше просто вариации из вышеперечисленного.

 

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

и используют тайм-ауты :)

 

 

[zltigo 0]

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

и используют тайм-ауты :)

Людоеды племени умба-юмба не используют не только таймауты, но и вообще промышленные применения. Темные люди :(, как и 99% "промышленных автоматизаторов" :( :( :(.

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

[Tsvetik 0]

Ну так типовая структура любого протокола (набор полей):

Стартовый байт

Поле адреса

Поле длины данных

Поле данных

Поле CRC

 

На все это накладываете байт-стаффинг для стартового байта.

Дальше просто вариации из вышеперечисленного.

 

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

и используют тайм-ауты :)

 

Да вот что-то не нравится мне эта схема вот чем:

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

 

Все, что здесь предлагали это какой-то самопал.

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

Изменено 14 марта, 2016 пользователем Tsvetik

[zltigo 0]

Медленно, т.к. один байт передается двумя посылками

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

 

 

Длина идет не первым байтом. Если МК с DMA, то нужно будет...

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

[Baser 5]

Людоеды племени умба-юмба не используют не только таймауты, но и вообще промышленные применения. Темные люди :(, как и 99% "промышленных автоматизаторов" :( :( :(.

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

Я вот даже не понял, то ли мне улыбаться надо, то ли обижаться

 

Да вот что-то не нравится мне эта схема вот чем:

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

Я не имел ввиду жесткий порядок полей.

Встречал всякие варианты.

И первым идет адрес (для мультимастер шины и фиксированной длине пакета)

И первым идет длина пакета (для переменной длины пакета и удобства применения ДМА)

Вариантов море.

 

Если начнете изучать различные стандартные протоколы,

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

 

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

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

Например разгребать сплошной поток мусора с пакетами после радиомодема.

Но там где спешить некуда, можно сделать и попроще...

 

[Tsvetik 0]

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

 

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

 

 

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

Я вот даже не понял, то ли мне улыбаться надо, то ли обижаться

 

 

Я не имел ввиду жесткий порядок полей.

Встречал всякие варианты.

И первым идет адрес (для мультимастер шины и фиксированной длине пакета)

И первым идет длина пакета (для переменной длины пакета и удобства применения ДМА)

Вариантов море.

 

Если начнете изучать различные стандартные протоколы,

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

 

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