[k155la3 26]

Giihub, SLIP, COBS

 

[jcxz 184]

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

COBS слышал, не применял, не знаю :laughing:

COBS тоже - простой, надёжный, с произвольной длиной сообщений, кодонезависимый.

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

У COBS увеличение длины сообщения после кодирования никак не зависит от данных в сообщении: всегда +1 дополнительный байт на каждые 254 входных байтов. Что я и представил формулой:

#define CobsCodedOver(payload) ((sizeof(payload) - 1) / 254 + 1)

где sizeof(payload) - длина исходного некодированного сообщения.

 

PS: Естественно никакие "размеры пакета" или "контрольные суммы" никакому из кодонезависимых протоколов (ни байт-стаффинговым ни COBS) не нужны. Всё это элементы протоколов более высокого уровня, над фреймером. Но чайники как правило всё это мешают в кучу. :laughing:

[Arlleex 131]

COBS тоже - простой, надёжный, с произвольной длиной сообщений, кодонезависимый.

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

[Kabdim 0]

Ну, например. У Вас максимальный размер поля данных - 4 байта (бинарные)

"прореживаете" все поля данных 0x00.

Заголовок пакета 5 байт: 0x55 - 0x01 - 0x02 - 0x03 - 0x04

Завершаете пакет 0x00 - 0x00 - 0x00 - CRC_Hi - CRC_Lo

(примитив, всяческое охаивание приветствуется)

Вот зачем придумывать плохонькое, но свое, если готовых вариантов (в том числе стандартов) не один и не два.

[k155la3 26]

Вот зачем придумывать плохонькое, но свое, если готовых вариантов (в том числе стандартов) не один и не два.

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

 

 

[jcxz 184]

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

Это грабли на ровном месте. Себе в будущем. Сколько уже раз так наступал.

Помнится в очередном проекте мне упорно доказывали, что: "нафиг не нужна никакая кодонезависимость от протокола, мы отправляемые данные так подберём, чтобы у нас в них не было спец.символов, ограничивающих кадр" (такими символами хотели сделать 0xFF). Пытаюсь доказывать, что устройство будет передавать в том числе и данные с АЦП, где 0xFF обязательно будет. В ответ присылают замороченный алгоритм как преобразовывать данные от АЦП (а там не только сырые данные и но обработанные), чтобы не было 0xFF. С потерями в сигнале, естественно. Говорю: "А в других местах, где надо будет передавать двоичные данные - как?" (таких мест тогда было известно ещё одно). В ответ - опять набор правил как выбирать данные, так чтобы там не было 0xFF. С кучей ограничений.

Пытаюсь спросить: "Зачем куча таких ограничений если можно реализовать просто элементарный стандартный протокол с байт-стаффингом???" В ответ что-то невразумительное, типа: "Ваш байт-стаффинг какой-то слишком сложный для нашей задачи. Нам такие сложности не нужны. Можно всё проще сделать".

Пытаюсь доказывать, что всё это - сплошной колхоз, обнесённый забором из грабель - бесполезно: "Мы хотим так, заказчик всегда прав".

Пытаюсь доказывать, что в будущем почти наверняка потребуется что-то доработать, расширить функционал, а такой кривой протокол будет всегда бить по башке. Не слышат. Как об стенку. :(

 

Чувствую, что не сам это заказчик придумал, а кто-то за ним говорит, его языком. Там у него был такой паренёк, который на компе под виндой должен был взаимодействие по данному протоколу с устройством писать. Чувствую что это он заказчиком рулит - в уши ему дует, а тот слушает (благо - он под боком всё время, а я - далеко). Позже пообщавшись с этим пареньком, по некоторым техническим вопросам реализации собственно обмена, на некоторых аспектах просто выпадаю в осадок - ни о каком уровне профессионализма там даже говорить не приходится! :smile3009: Становится ясно, почему "байт-стаффинг слишком сложный".

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

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

Ну что делать - пришлось скрепя сердце согласиться делать этот колхоз на квадратных колёсах.

 

Ну и естественно как и ожидалось - ещё даже на этапе написания первых версий ПО, вдруг потребовалась передача дополнительных данных, которые опять произвольные двоичные. Да ещё в них просто так не удалишь какие-то значения заменив на соседние как с данными АЦП (там просто ну чуть больше шума появляется). Что делать? Тот паренёк долго думает, потом придумывает ещё более развесистый колхоз, когда надо было в данных что-то искать (не помню уже что), и "если так - то так, если этак - то этак". Границы кадров сделать по 5 шт. 0xFF. А те данные, где могут появляться 0xFF, обнести другими, в которых 0xFF заведомо нет (максимальный размер каждого данного был 4 байта, поэтому если их проредить другими, то будет не более 4 шт. 0xFF подряд).

Вобщем - изобрёл костыль к своему творению. :biggrin: :biggrin: :biggrin:

Приходится реализовывать - делать нечего. А ещё - девайс-то батарейный. Этому пареньку то пофигу под виндой, а у меня каждый мА на счету, а тут куча лишних вычислений по перетасовке данных.... :blink:

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

 

Проходит пару лет, тот же заказчик стучится, просит ещё кой-какой функционал добавить. Оказывается - для полной реализации всех хотелок надо всё-таки нормальные двоичные данные передавать. А с имеющимся колхозом - никак. Говорю: "Я же вас предупреждал ещё тогда, много раз!". В ответ: "Да, надо было делать конечно как правильно, но тогда надо было побыстрее и думали что на том и остановимся и больше ничего не надо будет. Ну а теперь сделай что можешь, а уже лучше мы сделаем в следующем девайсе". Приходится заказчику урезать свои хотелки - сам виноват.

Попутно выясняю, что паренёк тот уволился из конторы, бросил этот проект так и не доведя его до рабочего состояния. Заложив им такую кучу г@#$а, что до сих пор разгрести не могут.

 

Вот такая грустная история про самописные протоколы "лишь бы попроще, и так сойдёт". :laughing:

[Kabdim 0]

Мне вот всегда такие объяснения лениво писать даже заказчику, а уж на форуме тем более. Спасибо что выразили всё это письменным языком.

[Arlleex 131]

Вот такая грустная история про самописные протоколы "лишь бы попроще, и так сойдёт". :laughing:

Спасибо за рассказ, читал с пониманием всего и вся - тоже проходили такое :wacko: Особенно про "добавить функционал, там же немножечко..." :biggrin:

[Segment 3]

Вы почитайте описание протокола и подумайте логически.

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

[ViKo 1]

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

Единственным нулем только в конце пакета любой длины. Все остальные нули в пакете заменяются смещением на следующий нуль. А если смещение равно FF, то это вставленный нуль, он выбрасывается.

https://en.wikipedia.org/wiki/Consistent_Ov...d_Byte_Stuffing

Посмотрите строки 8 и 9 в таблице.

[Segment 3]

Единственным нулем только в конце пакета любой длины. Все остальные нули в пакете заменяются смещением на следующий нуль. А если смещение равно FF, то это вставленный нуль, он выбрасывается.

https://en.wikipedia.org/wiki/Consistent_Ov...d_Byte_Stuffing

Посмотрите строки 8 и 9 в таблице.

Да, все верно. Внутри пакета меньше 254 байт легко отслеживается состояние пакета, так как знаем количество байт до следующего нуля. Но если байт 0х00 потерян, а за ним следует длинный пакет начинающийся с 0xFF? В случае утери — проскакиваем эту проверку и вычитываем весь (все) следующие пакеты до следующего нуля.

[jcxz 184]

Мне вот всегда такие объяснения лениво писать даже заказчику, а уж на форуме тем более. Спасибо что выразили всё это письменным языком.

Тема просто у меня наболевшая - долго это тянулось. Вот недавно опять напомнили - просили добавить функционал немного. И опять на эти грабли напоролись. :(

 

Да, все верно. Внутри пакета меньше 254 байт легко отслеживается состояние пакета, так как знаем количество байт до следующего нуля. Но если байт 0х00 потерян, а за ним следует длинный пакет начинающийся с 0xFF? В случае утери — проскакиваем эту проверку и вычитываем весь (все) следующие пакеты до следующего нуля.

Естественно - 0 граница кадра. От него и начинаем читать кадр. Если произошёл сбой, то приёмник должен перейти в состояние "несинхронизирован", в котором он просто читает вх. поток в поисках 0.

Приёмник должен переходить в состояние "несинхронизирован" при любых ошибках в приёме, в том числе и из-за переполнения (слишком длинный кадр).

[k155la3 26]

Это грабли на ровном месте. . . . . Вот такая грустная история про самописные протоколы "лишь бы попроще, и так сойдёт".

Это не "история". Это "сага" :)

С меня упорно требовали убрать поле CRC в пакете, под тем "соусом", что "кабель короткий и передаваемая инф-я не может исказиться или быть потеряна".

У каждого свой реестр таких ситуаций.

За критику спасибо, принимается.

 

 

[mantech 34]

С меня упорно требовали убрать поле CRC в пакете, под тем "соусом", что "кабель короткий и передаваемая инф-я не может исказиться или быть потеряна".

 

Бывает такое, как-то дорабатывал табло, в нем тоже 1200 бод, нет КС, т.к. "комп рядом стоял", а потом начальник взял да и поставил комп в другом крыле, примерно метров 15-20 было... И началось :biggrin:

[DogPawlowa 0]

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

Типичный протокол не предусматривает передачи любых данных.

Старый добрый пакет STX data ETX BCC1 BCC2 вместе с запросами и подтверждениями ENQ/ DLE вполне решает все проблемы.

 

Длина/скорость передачи критичны в единицах случаев.

Возвращайтесь к истокам, коллеги! ;)