Jump to content

    

Битые записи в массиве.

Recommended Posts

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

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

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

 

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

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

 

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

Share this post


Link to post
Share on other sites

Kabdim

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

 

 

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

DogPawlowa

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

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

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

 

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.