Tsvetik 0 14 марта, 2016 Опубликовано 14 марта, 2016 (изменено) · Жалоба Нужно передавать массивы двоичных данных по UART между двумя устройствами. Так как полезная нагрузка не помещается в пределы 1 байта, необходимо поверх UART использовать некоторый логический протокол, который будет разделять фреймы и как-то управлять потоком. Следовательно из 256 вариантов байта необходимо зарезервировать несколько значений для признаков начала (или конца) фрейма и, возможно, каких-то других управляющий символов. Один из вариантов это /xon /xoff. Его минусы в том, что символы /xon /xoff могут встретиться в передаваемых двоичных данных и их надо экранировать. Плюс этого метода в том, что экранирование можно проводить "на лету" при приеме. Промежуточный буфер для этого не требуется. Второй вариант использовать для кодирования двоичных данных некоторую кодировку. Например, BASE64 или семибитную кодировку, а старшие биты пристегивать отдельным байтом. Тогда символы, не входящие в алфавит BASE64 или со взведенным старшим битом можно считать управляющими. На них можно повесить функции управления протоколом, начала-конца фрейма, повтора передачи, может-быть и адреса устройства и т.п. Обычно кодирование-декодирование требует промежуточного буфера и вносит дополнительные временные издержки. Так вот, подскажите какие-нибудь популярные реализации логических протоколов поверх UART. Необходимы легковесные протоколы, которые будут работать довольно быстро на Tiny AVR. Да, желательно без 9-го бита UART, чтобы с PC было проще отлаживаться Изменено 14 марта, 2016 пользователем Tsvetik Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
АлександрК 0 14 марта, 2016 Опубликовано 14 марта, 2016 · Жалоба ... символы ... могут встретиться в передаваемых двоичных данных и их надо экранировать. Например, начало/конец сообщения обозначить 2-3 символами. И только эта последовательность будет началом/окончанием сообщения. Все символы, входящие в эти последовательности, по отдельности или в другом порядке - есть данные. Управление АТ-командами - вот пример. Начало всегда АТ, а окончание LF, CR. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tsvetik 0 14 марта, 2016 Опубликовано 14 марта, 2016 (изменено) · Жалоба Например, начало/конец сообщения обозначить 2-3 символами. И только эта последовательность будет началом/окончанием сообщения. Все символы, входящие в эти последовательности, по отдельности или в другом порядке - есть данные. Управление АТ-командами - вот пример. Начало всегда АТ, а окончание LF, CR. Те же N символов могут встретиться и в двоичных данных. Например, надо передать AT команду в которой содержится другая AT команда Изменено 14 марта, 2016 пользователем Tsvetik Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iosifk 3 14 марта, 2016 Опубликовано 14 марта, 2016 · Жалоба Нужно передавать массивы двоичных данных по UART между двумя устройствами. .... Так вот, подскажите какие-нибудь популярные реализации логических протоколов поверх UART. Необходимы легковесные протоколы, которые будут работать довольно быстро на Tiny AVR. Стандартно либо передаете данные символьными кодами. А возврат каретки и перевод строки - это конец сообщения. Медленно, т.к. один байт передается двумя посылками, но просто... И годится любая терминалка на хосте... Либо байт-стаффинг. Например WAKE от Ридико... Исходники и описания Леонид выложил... Делать бит-стаффинг нет смысла, т.к. сдвигать массив данных на микроконтроллере долго... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tsvetik 0 14 марта, 2016 Опубликовано 14 марта, 2016 (изменено) · Жалоба За WAKE спасибо. Изменено 14 марта, 2016 пользователем Tsvetik Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iosifk 3 14 марта, 2016 Опубликовано 14 марта, 2016 · Жалоба А это где посмотреть? Wake + Ридико Леонид Иванович + любой поисковик Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Baser 5 14 марта, 2016 Опубликовано 14 марта, 2016 · Жалоба Один из вариантов это /xon /xoff. Его минусы в том, что символы /xon /xoff могут встретиться в передаваемых двоичных данных и их надо экранировать. Что вы называете "экранировать", не знаю, но для выделения уникального кода для управления применяется метод байт-стаффинга (byte stuffing). Но отлаживаться с ним неудобно. Обычно для простейших протоколов применяют разделение пакетов по тайм-аутам. Самый простой и удобный метод. А вообще для простеньких применений чаще всего применяют самопальные протоколы. Правда, хороший самопальный протокол можно придумать только при достаточном опыте работы и предварительном написании кучи плохих самопальных протоколов :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
McSava 0 14 марта, 2016 Опубликовано 14 марта, 2016 · Жалоба В 8b/10b кодировании есть признаки старта / стопа сообщения и синхронизирующие сообщения. Там это сделано для того чтоб подстраивать PLL для извлечения синхросигнала из данных, и получаем сигнал из неповторяющихся длинных последовательностей из "1" или "0". Но этот принцип можно использовать для выбора протокола и по UART. За счёт избытоного кодирования, все вариации восьмибитных данных закладываются внутрь 10 битных посылок. У нас появляются никогда не встречаюся комбинации, в них и вкладываются служебные признаки. Удобно ли конкретно этот протокол, вкладывать в скорости UART - не пробовал, всё таки разработан он немного для других вещей. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tsvetik 0 14 марта, 2016 Опубликовано 14 марта, 2016 · Жалоба Что вы называете "экранировать", не знаю, но для выделения уникального кода для управления применяется метод байт-стаффинга (byte stuffing). Но отлаживаться с ним неудобно. Обычно для простейших протоколов применяют разделение пакетов по тайм-аутам. Самый простой и удобный метод. А вообще для простеньких применений чаще всего применяют самопальные протоколы. Правда, хороший самопальный протокол можно придумать только при достаточном опыте работы и предварительном написании кучи плохих самопальных протоколов :) Байт-стаффинг и есть экранировать иначе, escape sequence Тайм-ауты нафиг. Медленно и не хочу зависимость от таймера. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Baser 5 14 марта, 2016 Опубликовано 14 марта, 2016 · Жалоба Байт-стаффинг и есть экранировать иначе, escape sequence Тайм-ауты нафиг. Медленно и не хочу зависимость от таймера. Ну так типовая структура любого протокола (набор полей): Стартовый байт Поле адреса Поле длины данных Поле данных Поле CRC На все это накладываете байт-стаффинг для стартового байта. Дальше просто вариации из вышеперечисленного. Но 99% протоколов промышленного применения, что я видел, не применяют байт-стаффинг и используют тайм-ауты :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 14 марта, 2016 Опубликовано 14 марта, 2016 · Жалоба Но 99% протоколов промышленного применения, что я видел, не применяют байт-стаффинг и используют тайм-ауты :) Людоеды племени умба-юмба не используют не только таймауты, но и вообще промышленные применения. Темные люди :(, как и 99% "промышленных автоматизаторов" :( :( :(. Ну а таймауты нужны В ЛЮБОМ случае. При том-же байтстаффинге для отработки ошибок использовать таймаут, как аварийное завершение фрейма и по нему-же выброс мусора. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tsvetik 0 14 марта, 2016 Опубликовано 14 марта, 2016 (изменено) · Жалоба Ну так типовая структура любого протокола (набор полей): Стартовый байт Поле адреса Поле длины данных Поле данных Поле CRC На все это накладываете байт-стаффинг для стартового байта. Дальше просто вариации из вышеперечисленного. Но 99% протоколов промышленного применения, что я видел, не применяют байт-стаффинг и используют тайм-ауты :) Да вот что-то не нравится мне эта схема вот чем: Длина идет не первым байтом. Если МК с DMA, то нужно будет несколько входов в обработчик прежде чем можно будет включить DMA. Все, что здесь предлагали это какой-то самопал. Неужели нет чего-то более-менее стандартног-популярного? Может, рекомендованного IEC или еще каким-то международным институтом? Изменено 14 марта, 2016 пользователем Tsvetik Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 2 14 марта, 2016 Опубликовано 14 марта, 2016 · Жалоба Медленно, т.к. один байт передается двумя посылками Сивольные это не обязательно HEX. Можно так-же легко и 3 байта четырьмя символами в стиле UUE, или еще более плотно упаковать. Длина идет не первым байтом. Если МК с DMA, то нужно будет... Могу Вас огорчить до "первого байта" Вы с удручающей вероятностью В РЕАЛЬНОЙ ЖИЗНИ сначала отгребете еще мусора. Так что забудьте о том, что есть какой то "первый байт". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Baser 5 14 марта, 2016 Опубликовано 14 марта, 2016 · Жалоба Людоеды племени умба-юмба не используют не только таймауты, но и вообще промышленные применения. Темные люди :(, как и 99% "промышленных автоматизаторов" :( :( :(. Любите вы, zltigo, туману подпустить в витиеватой форме. Я вот даже не понял, то ли мне улыбаться надо, то ли обижаться Да вот что-то не нравится мне эта схема вот чем: Длина идет не первым байтом. Если МК с DMA, то нужно будет несколько входов в обработчик прежде чем можно будет включить DMA Я не имел ввиду жесткий порядок полей. Встречал всякие варианты. И первым идет адрес (для мультимастер шины и фиксированной длине пакета) И первым идет длина пакета (для переменной длины пакета и удобства применения ДМА) Вариантов море. Если начнете изучать различные стандартные протоколы, то тоже подивитесь разнообразию вкусов разработчиков... Могу Вас огорчить до "первого байта" Вы с удручающей вероятностью В РЕАЛЬНОЙ ЖИЗНИ сначала отгребете еще мусора. Так что забудьте о том, что есть какой то "первый байт". Естественно, если задача предполагает наличие высокого уровня помех, то протокол должен это учитывать. Например разгребать сплошной поток мусора с пакетами после радиомодема. Но там где спешить некуда, можно сделать и попроще... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tsvetik 0 14 марта, 2016 Опубликовано 14 марта, 2016 · Жалоба Могу Вас огорчить до "первого байта" Вы с удручающей вероятностью В РЕАЛЬНОЙ ЖИЗНИ сначала отгребете еще мусора. Так что забудьте о том, что есть какой то "первый байт". Первый байт фрейма. Считайте, что мусор из приемника уже вычищен, а начало фрейма найдено. Чтобы не было необходимости долго побайтово вычитывать заголовок фрейма, хорошо бы, чтобы длина была как можно ближе к началу фреймаю. В идеале закодирована в первом байте. Любите вы, zltigo, туману подпустить в витиеватой форме. Я вот даже не понял, то ли мне улыбаться надо, то ли обижаться Я не имел ввиду жесткий порядок полей. Встречал всякие варианты. И первым идет адрес (для мультимастер шины и фиксированной длине пакета) И первым идет длина пакета (для переменной длины пакета и удобства применения ДМА) Вариантов море. Если начнете изучать различные стандартные протоколы, то тоже подивитесь разнообразию вкусов разработчиков... Ну дайте хоть названия-то этих стандартных протоколов. Что изучать, что гуглить? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться