k155la3 26 17 июля, 2018 Опубликовано 17 июля, 2018 · Жалоба Giihub, SLIP, COBS Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 17 июля, 2018 Опубликовано 17 июля, 2018 · Жалоба Простой, надежный. Переменная длина сообщений вообще радует - сделал себе что-то наподобие мессенджера - при этом не нужны поля размера пакета в структурах обмена и связанные с этим головные боли тоже ушли. COBS слышал, не применял, не знаю :laughing: COBS тоже - простой, надёжный, с произвольной длиной сообщений, кодонезависимый. У байт-стаффинговых протоколов есть существенный недостаток: увеличение длины сообщения после кодирования зависит от содержащихся в сообщении данных. Это может быть существенным минусом например когда нужно заранее перед кодированием знать длину вых.сообщения, или когда пропускная способность канала ограничена. У COBS увеличение длины сообщения после кодирования никак не зависит от данных в сообщении: всегда +1 дополнительный байт на каждые 254 входных байтов. Что я и представил формулой: #define CobsCodedOver(payload) ((sizeof(payload) - 1) / 254 + 1) где sizeof(payload) - длина исходного некодированного сообщения. PS: Естественно никакие "размеры пакета" или "контрольные суммы" никакому из кодонезависимых протоколов (ни байт-стаффинговым ни COBS) не нужны. Всё это элементы протоколов более высокого уровня, над фреймером. Но чайники как правило всё это мешают в кучу. :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 131 17 июля, 2018 Опубликовано 17 июля, 2018 · Жалоба COBS тоже - простой, надёжный, с произвольной длиной сообщений, кодонезависимый. Изучу более детально в ближайшем будущем в своем проекте, спасибо :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 17 июля, 2018 Опубликовано 17 июля, 2018 · Жалоба Ну, например. У Вас максимальный размер поля данных - 4 байта (бинарные) "прореживаете" все поля данных 0x00. Заголовок пакета 5 байт: 0x55 - 0x01 - 0x02 - 0x03 - 0x04 Завершаете пакет 0x00 - 0x00 - 0x00 - CRC_Hi - CRC_Lo (примитив, всяческое охаивание приветствуется) Вот зачем придумывать плохонькое, но свое, если готовых вариантов (в том числе стандартов) не один и не два. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 17 июля, 2018 Опубликовано 17 июля, 2018 · Жалоба Вот зачем придумывать плохонькое, но свое, если готовых вариантов (в том числе стандартов) не один и не два.Не думаю, что это "мое-свое", какой-нибудь частный-урезанный случай вышеупомянутых методов. Зато легко-понимаемый. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 17 июля, 2018 Опубликовано 17 июля, 2018 · Жалоба Не думаю, что это "мое-свое", какой-нибудь частный-урезанный случай вышеупомянутых методов. Зато легко-понимаемый. Это грабли на ровном месте. Себе в будущем. Сколько уже раз так наступал. Помнится в очередном проекте мне упорно доказывали, что: "нафиг не нужна никакая кодонезависимость от протокола, мы отправляемые данные так подберём, чтобы у нас в них не было спец.символов, ограничивающих кадр" (такими символами хотели сделать 0xFF). Пытаюсь доказывать, что устройство будет передавать в том числе и данные с АЦП, где 0xFF обязательно будет. В ответ присылают замороченный алгоритм как преобразовывать данные от АЦП (а там не только сырые данные и но обработанные), чтобы не было 0xFF. С потерями в сигнале, естественно. Говорю: "А в других местах, где надо будет передавать двоичные данные - как?" (таких мест тогда было известно ещё одно). В ответ - опять набор правил как выбирать данные, так чтобы там не было 0xFF. С кучей ограничений. Пытаюсь спросить: "Зачем куча таких ограничений если можно реализовать просто элементарный стандартный протокол с байт-стаффингом???" В ответ что-то невразумительное, типа: "Ваш байт-стаффинг какой-то слишком сложный для нашей задачи. Нам такие сложности не нужны. Можно всё проще сделать". Пытаюсь доказывать, что всё это - сплошной колхоз, обнесённый забором из грабель - бесполезно: "Мы хотим так, заказчик всегда прав". Пытаюсь доказывать, что в будущем почти наверняка потребуется что-то доработать, расширить функционал, а такой кривой протокол будет всегда бить по башке. Не слышат. Как об стенку. :( Чувствую, что не сам это заказчик придумал, а кто-то за ним говорит, его языком. Там у него был такой паренёк, который на компе под виндой должен был взаимодействие по данному протоколу с устройством писать. Чувствую что это он заказчиком рулит - в уши ему дует, а тот слушает (благо - он под боком всё время, а я - далеко). Позже пообщавшись с этим пареньком, по некоторым техническим вопросам реализации собственно обмена, на некоторых аспектах просто выпадаю в осадок - ни о каком уровне профессионализма там даже говорить не приходится! :smile3009: Становится ясно, почему "байт-стаффинг слишком сложный". Ок - пишу для него функции приёма и передачи, которые он просто вставит в свой код, даст приёмной() на вход поток байт, а она ему будет выплёвывать кадры, ну и передающую() - в обратном порядке. Отправляю ему с описанием куда и чего нужно подавать. Проходит время.... тишина - то ли не понял, то ли что-то не получилось. Вобщем - ни в какую не хочет использовать кодонезависимый фрейминг. Ну что делать - пришлось скрепя сердце согласиться делать этот колхоз на квадратных колёсах. Ну и естественно как и ожидалось - ещё даже на этапе написания первых версий ПО, вдруг потребовалась передача дополнительных данных, которые опять произвольные двоичные. Да ещё в них просто так не удалишь какие-то значения заменив на соседние как с данными АЦП (там просто ну чуть больше шума появляется). Что делать? Тот паренёк долго думает, потом придумывает ещё более развесистый колхоз, когда надо было в данных что-то искать (не помню уже что), и "если так - то так, если этак - то этак". Границы кадров сделать по 5 шт. 0xFF. А те данные, где могут появляться 0xFF, обнести другими, в которых 0xFF заведомо нет (максимальный размер каждого данного был 4 байта, поэтому если их проредить другими, то будет не более 4 шт. 0xFF подряд). Вобщем - изобрёл костыль к своему творению. :biggrin: :biggrin: :biggrin: Приходится реализовывать - делать нечего. А ещё - девайс-то батарейный. Этому пареньку то пофигу под виндой, а у меня каждый мА на счету, а тут куча лишних вычислений по перетасовке данных.... :blink: Пытаюсь вразумить заказчика, показывая ему, что сложность реализации и потенциальные глюки получившегося колхоза уже много сложнее всех байт-стаффингов вместе взятых. Он уже молчит. Потом говорит, что уже много девайсов продано. И переделывать всё заново - слишком долго и накладно. Ну сделали - фиг с ним, постарался побыстрее забыть этот мрак. Проходит пару лет, тот же заказчик стучится, просит ещё кой-какой функционал добавить. Оказывается - для полной реализации всех хотелок надо всё-таки нормальные двоичные данные передавать. А с имеющимся колхозом - никак. Говорю: "Я же вас предупреждал ещё тогда, много раз!". В ответ: "Да, надо было делать конечно как правильно, но тогда надо было побыстрее и думали что на том и остановимся и больше ничего не надо будет. Ну а теперь сделай что можешь, а уже лучше мы сделаем в следующем девайсе". Приходится заказчику урезать свои хотелки - сам виноват. Попутно выясняю, что паренёк тот уволился из конторы, бросил этот проект так и не доведя его до рабочего состояния. Заложив им такую кучу г@#$а, что до сих пор разгрести не могут. Вот такая грустная история про самописные протоколы "лишь бы попроще, и так сойдёт". :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 17 июля, 2018 Опубликовано 17 июля, 2018 · Жалоба Мне вот всегда такие объяснения лениво писать даже заказчику, а уж на форуме тем более. Спасибо что выразили всё это письменным языком. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 131 17 июля, 2018 Опубликовано 17 июля, 2018 · Жалоба Вот такая грустная история про самописные протоколы "лишь бы попроще, и так сойдёт". :laughing: Спасибо за рассказ, читал с пониманием всего и вся - тоже проходили такое :wacko: Особенно про "добавить функционал, там же немножечко..." :biggrin: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Segment 3 17 июля, 2018 Опубликовано 17 июля, 2018 · Жалоба Вы почитайте описание протокола и подумайте логически. Нет, все-таки поясните, как Вы можете надежно передать пакет размером >254 байт без участия дополнительного поля общей длины пакета. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 17 июля, 2018 Опубликовано 17 июля, 2018 · Жалоба Нет, все-таки поясните, как Вы можете надежно передать пакет размером >254 байт без участия дополнительного поля общей длины пакета. Единственным нулем только в конце пакета любой длины. Все остальные нули в пакете заменяются смещением на следующий нуль. А если смещение равно FF, то это вставленный нуль, он выбрасывается. https://en.wikipedia.org/wiki/Consistent_Ov...d_Byte_Stuffing Посмотрите строки 8 и 9 в таблице. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Segment 3 17 июля, 2018 Опубликовано 17 июля, 2018 · Жалоба Единственным нулем только в конце пакета любой длины. Все остальные нули в пакете заменяются смещением на следующий нуль. А если смещение равно FF, то это вставленный нуль, он выбрасывается. https://en.wikipedia.org/wiki/Consistent_Ov...d_Byte_Stuffing Посмотрите строки 8 и 9 в таблице. Да, все верно. Внутри пакета меньше 254 байт легко отслеживается состояние пакета, так как знаем количество байт до следующего нуля. Но если байт 0х00 потерян, а за ним следует длинный пакет начинающийся с 0xFF? В случае утери — проскакиваем эту проверку и вычитываем весь (все) следующие пакеты до следующего нуля. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 17 июля, 2018 Опубликовано 17 июля, 2018 · Жалоба Мне вот всегда такие объяснения лениво писать даже заказчику, а уж на форуме тем более. Спасибо что выразили всё это письменным языком. Тема просто у меня наболевшая - долго это тянулось. Вот недавно опять напомнили - просили добавить функционал немного. И опять на эти грабли напоролись. :( Да, все верно. Внутри пакета меньше 254 байт легко отслеживается состояние пакета, так как знаем количество байт до следующего нуля. Но если байт 0х00 потерян, а за ним следует длинный пакет начинающийся с 0xFF? В случае утери — проскакиваем эту проверку и вычитываем весь (все) следующие пакеты до следующего нуля. Естественно - 0 граница кадра. От него и начинаем читать кадр. Если произошёл сбой, то приёмник должен перейти в состояние "несинхронизирован", в котором он просто читает вх. поток в поисках 0. Приёмник должен переходить в состояние "несинхронизирован" при любых ошибках в приёме, в том числе и из-за переполнения (слишком длинный кадр). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 17 июля, 2018 Опубликовано 17 июля, 2018 · Жалоба Это грабли на ровном месте. . . . . Вот такая грустная история про самописные протоколы "лишь бы попроще, и так сойдёт".Это не "история". Это "сага" :) С меня упорно требовали убрать поле CRC в пакете, под тем "соусом", что "кабель короткий и передаваемая инф-я не может исказиться или быть потеряна". У каждого свой реестр таких ситуаций. За критику спасибо, принимается. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 35 17 июля, 2018 Опубликовано 17 июля, 2018 · Жалоба С меня упорно требовали убрать поле CRC в пакете, под тем "соусом", что "кабель короткий и передаваемая инф-я не может исказиться или быть потеряна". Бывает такое, как-то дорабатывал табло, в нем тоже 1200 бод, нет КС, т.к. "комп рядом стоял", а потом начальник взял да и поставил комп в другом крыле, примерно метров 15-20 было... И началось :biggrin: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DogPawlowa 0 18 июля, 2018 Опубликовано 18 июля, 2018 · Жалоба Вообще-то во многих странах на протоколы связи с устройствами есть стандарты. Типичный протокол не предусматривает передачи любых данных. Старый добрый пакет STX data ETX BCC1 BCC2 вместе с запросами и подтверждениями ENQ/ DLE вполне решает все проблемы. Длина/скорость передачи критичны в единицах случаев. Возвращайтесь к истокам, коллеги! ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться