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

[Tsvetik]

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

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

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

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

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

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

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

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

[Александр1]

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

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

[Tsvetik]

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

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

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

[iosifk]

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

....

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

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

[Tsvetik]

За WAKE спасибо.



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

[iosifk]

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

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

[Baser]

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

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

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

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

[Kaligooola]

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

[Tsvetik]

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

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

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

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

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

[Baser]

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

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

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

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

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

[zltigo]

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

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

[Tsvetik]

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

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

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

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

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

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

[zltigo]

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

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

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

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

[Baser]

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

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

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

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

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

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

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

[Tsvetik]

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

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

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


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

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

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

[zltigo]

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

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

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

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

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

Про переменную длинну - писал ранее. Про "удобство ДМА", прежде всего следует озаботится тем, что бы НЕ загружать ни DMA ни последующие обработчики приемом и отсеиванием мусора.

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

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

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

Для того, что бы понять, как следует стремиться что-то протокольное делать, следует в качестве общего развития понять, как и почему хотя-бы дедушка всех ПРАВИЛЬНЫХ стеков протоколов - X.25 сделан так, как он сделан. После чего уже сможете отделять "вкусы разработчиков" от их дурости безошибочно.

В идеале закодирована в первом байте.

Это НЕ идеал. Это одна узкая точка зрения в вашем случае "ДМА". Как минимум одну причину НЕ иметь размер первым байтом уже назвал.

[iosifk]

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

А вот давайте не будем придумывать новые термины. Ибо если не знаете протоколов, то и термины применяйте общепринятые...
8b/10b можно даже не обсуждать...
Можно поговорить о 9-м бите "чет-нечет", как в MSC51. В микроконтроллере это легко, а вот в хосте не очень...

[Corvus]

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

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

Из общеизвестных сходу вспоминаются:
MODBUS (ASCII/RTU)
SLIP (CSLIP)
WAKE
...
?

[Ruslan1]

разделение на фреймы:
SLIP (RFC1055)
https://tools.ietf.org/html/rfc1055

просто, стандартно, надежно. Внутри- по вкусу (у меня, например, дополнительно код в начале и CRC16 в конце, а между ними данные в соответствии с кодом).

[Baser]

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

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

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

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

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

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

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

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

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

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

[zltigo]

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

Я, естественно, тоже писал по своему опыту.

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

Но ПОДХОДЫ к созданию протоколов должны быть универсальными. Рожать протоколы по принципу у меня тут DMA и ему будет удобнее..., есть неправильно. Любой протокол требует определенных компромиссов. В данном случае вообще Автором намечатся использование DMA через анус - типа я буду разгребать побайтно мусор и искать начало, а потом получив ОДИН байт, который тоже, между прочим, может быть мусором, как запущу DMA, да как получу целую кучу всего, да как потом начну разбираться в том, что получил, и в том числе опять искать в принятом начало фрейма, если размер оказался мусором... В общем фигня зачем-то поставленая во главу протокола.

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

Совет, какой смотреть и вникать в ОБЩИЕ принципы многоуровневого построения протоколов, уже был.

Из общеизвестных сходу вспоминаются:
MODBUS (ASCII/RTU)

Тихий ужас. ASCII хоть фрейминг имеет, правда огромной ценой.

SLIP (CSLIP)

Это не пртокол, это фреймер. То есть нижний уровень протокола. Если физический уровень байтовый, то этот фреймер и надо использовать в большинстве случаев, а для 485 - в 98% случаев.

WAKE

Слиповский фреймер с небольшими надстройками в стиле MODBUS. Как прямая альтернатива модбасовскому выкидышу - отлично. На продвинутость, естественно, не перетендует.

[jcxz]

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

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

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

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

[zltigo]

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

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

[iosifk]

Это смотря какой микроконтроллер....
...
Траффик упал в неск. раз и МК не помер. Ресурсов это заняло немного. А сжатие - сплошные манипуляции с битами и преобразование в битовый поток.
Хотя МК канеш не AVR - LPC4370 с тактовой до 204МГц

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

[jcxz]

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

Не смешивайте уровни обработки. Драйвер DMA не должен никак зависеть от протокола в котором передаётся поток. Он вообще ничего не должен знать о протоколе.
Программируете DMA на любой удобный размер, запускаете и дополнительно, по таймеру отслеживаете состояние работы DMA, с принудительным завершением и перезапуском при простое принимаемого потока.

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

Ну понятно. Это просто вспомнилось. К месту или не к месту

[mempfis_]

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

Посмотрите как передают NMEA-строки
$GPGGA,.........*AB\r\n
Есть стартовая последовательность ($)
Тип пакета (если он нужен, GPGGA)
Данные. Контрольная сумма сообщения (отделена от тела пакета *, в данном случае xorc сообщения, но может быть crc или lrc в зависимости от требований).
Стопова комбинация (\r\n, реально всегда хватает только \r)
Защищена от бинарного мусора т.к. передача ведётся в ASCII-кодированных символах.
Легко парситься из-за наличия старт-стоповых комбинаций.
В вашем случае для передачи бинарных данных можно передавать пары символов '0' '0' == 0x00, 'A' 'F' == 0xaf и т.д.
Данные легко декодируются даже на мелкой Tiny13 табличным методом, занимая при этом минимум кода.

[Огурцов]

Адрес идет первым не по причине мультимастера, а по причине быстрого принятия решения по маршрутизации

зачем самому принимать решение, если решение может принимать железо uart автоматом, переключенное в режиме мультимастера мультипроцессора

[zltigo]

зачем самому принимать решение, если решение может принимать железо uart автоматом, переключенное в режиме мультимастера мультипроцессора

Вы это чего написали? Есть два 485 приемопередатчика. Нужно принимать решение о предаче фреймов между сегментами сети к которым они подключены. Ну и?

[Tsvetik]

Не смешивайте уровни обработки. Драйвер DMA не должен никак зависеть от протокола в котором передаётся поток. Он вообще ничего не должен знать о протоколе.
Программируете DMA на любой удобный размер, запускаете и дополнительно, по таймеру отслеживаете состояние работы DMA, с принудительным завершением и перезапуском при простое принимаемого потока.


Ну понятно. Это просто вспомнилось. К месту или не к месту

Ну, с одной стороны tiny, а с другой ARM7 или PC при тестах и отладке. Так что требование к DMA вторично.

С одной стороны, когда DMA не знает ничего о протоколе будет легко разделить передачу на различные уровни обработки. С другой стороны, добавление уровней обработки часто означает добавление дополнительных буфферов и сильного увеличения уровня вложенности функций.

[sigmaN]

С одной стороны, когда DMA не знает ничего о протоколе будет легко разделить передачу на различные уровни обработки. С другой стороны, добавление уровней обработки часто означает добавление дополнительных буфферов и сильного увеличения уровня вложенности функций.

Опять решения по проектированию протокола получается подгоняются под какие-то детали его реализации с имеющимся на данный момент у вас скиллом программирования.
Способ передачи данных между уровнями протокола и кол-во вложенности функций должны определяться уже на этапе проектирования реализации протокола, а не самого протокола. Понимаете? Это то-же самое, о чем говорил zltigo, в его посте про DMA.

На вскидку:
1.Буферы там особо могут и не понадобиться.. Всегда можно использовать указатель на буйер, который передается по стеку(читать между функциями).
2.Уровень вложенности функций....
Все это очень будет зависеть от того как именно организован код и что делают те самые функции.
ИМХО, сам по себе высокий уровень вложенности редко является проблемой. До тех пор пока в фокусе программиста, при работе с какой-то подсистемой, находится разумный уровень вложенности - все ок. Никого сильно не волнует, что при этом от main() до самой дальней функции в проекте получается 100500 вложений. В больших проектах это кстати неизбежно.

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

[jcxz]

С одной стороны, когда DMA не знает ничего о протоколе будет легко разделить передачу на различные уровни обработки. С другой стороны, добавление уровней обработки часто означает добавление дополнительных буфферов и сильного увеличения уровня вложенности функций.

Не понял - о чём Вы? Сколько каких уровней?
Вам же вроде надо только выделять кадры из потока байт (определять границы кадра в потоке байт)?
Тут хоть с DMA хоть без (на прерываниях) будет только два процесса: 1-ый пишущий в кольцевой буфер байт; 2-ой - читающий из кольцевого буфера поток байт и разбирающий его на кадры. Всё.
Если в этих кадрах у Вас инкапсулирован другой протокол - тогда да - дальше будет уровень парсинга уже его кадров из полученных ранее кадров протокола 1-го уровня. Но у Вас вроде только один протокол без вложенных.

Если драйвер UART реализован без DMA: ISR UART пишет принимаемые байты в кольцевой буфер и пингует задачу, читающую этот буфер и парсящую поток байт на кадры.
Если с DMA - то же самое: DMA пишет в тот же самый буфер и ISR завершения DMA-транзакции так же пингует задачу парсера. Единственно, что наверное записываемые группы байт будут больше, чем в варианте драйвера по прерываниям.
В остальном - никакой разницы. Парсер протокола никак не должен зависеть от реализации драйвера UART и каким образом тот кладёт байты в кольцевой буфер.

[Ruslan1]

У меня в одном устройстве используется по приему кольцевой буфер DMA плюс прерывание по совпадению байта, и RFC1055 (SLIP).
Основано на том, что в SLIP есть специальный байт "конец фрейма", только по нему и прерываюсь.
под FreeRTOS это выглядит замечательно: прерывание добавляет адрес начала нового фрейма в очередь для задачи, которая разбирается с пакетами.
А разборки идут уже в самой задаче, которая ждет непустой очереди или таймаута(по таймауту проверяется работоспособность и отсутствие ошибок в работе модуля приема-передачи).
Таким образом, удается обеспечить прием не одного фрейма, а многих (сколько влезет в кольцо), если они идут группой и иногда обрабатываются дольше чем начинается новый фрейм.
Очень дубово, надежно, и не ест лишних ресурсов.

[=AK=]

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

Если массивы не очень большие, не более 255 байт, то проще всего использовать COBS. Тогда появление в потоке 0 будет означать "конец сообщения", этого будет достаточно. COBS можно применять и для длинных сообщений, но тогда продется заводить отдельный буфер для кодирования, ибо в процессе кодирования длина сообщения может немного увеличиваться. А для коротких сообщений заранее известно, что после кодирования COBS длина сообщения увеличится ровно на 1 байт, поэтому можно без дополнительного буфера обойтись.

[Tsvetik]

Если массивы не очень большие, не более 255 байт, то проще всего использовать COBS. Тогда появление в потоке 0 будет означать "конец сообщения", этого будет достаточно. COBS можно применять и для длинных сообщений, но тогда продется заводить отдельный буфер для кодирования, ибо в процессе кодирования длина сообщения может немного увеличиваться. А для коротких сообщений заранее известно, что после кодирования COBS длина сообщения увеличится ровно на 1 байт, поэтому можно без дополнительного буфера обойтись.

СУПЕР!!
COBS - это как раз именно то, что мне нужно.
и реализация миниатюрнейшая

Большое спасибо.

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

[AlexandrY]

COBS - это как раз именно то, что мне нужно.

Однако это кодировка с размножением ошибок.
Скверный выбор.

[Tsvetik]

Однако это кодировка с размножением ошибок.
Скверный выбор.

Что вы имеете ввиду?

[zltigo]

Однако это кодировка с размножением ошибок.
Скверный выбор.

Да это как раз проблема равная 0, если в этот фреймер не запихивать данные с избыточным кодированим для восстановления. А вот то, что на лету нельзя кодировать, это уже может для очень многих случаев быть тоскливым. Причем пробегать буфер придется два раза - для контрольной суммы и собственно кодирования. А вообще этот COBS муть голубая - подставив вместо первого байта размер, а вместо последного 0x00 гарантированный таймаут получим привычную хрень, которая первой приходит в голову любому начинающему изобретателю фреймера. Только это будет уже БЕЗ ненужных дополнительных плясок с "кодированием" и с бонусом в виде аварийного выброса неполного фрейма по таймауту.