Цитата(k155la3 @ Jul 17 2018, 11:56)
Не думаю, что это "мое-свое", какой-нибудь частный-урезанный случай вышеупомянутых методов. Зато легко-понимаемый.
Это грабли на ровном месте. Себе в будущем. Сколько уже раз так наступал.
Помнится в очередном проекте мне упорно доказывали, что: "нафиг не нужна никакая кодонезависимость от протокола, мы отправляемые данные так подберём, чтобы у нас в них не было спец.символов, ограничивающих кадр" (такими символами хотели сделать 0xFF). Пытаюсь доказывать, что устройство будет передавать в том числе и данные с АЦП, где 0xFF обязательно будет. В ответ присылают замороченный алгоритм как преобразовывать данные от АЦП (а там не только сырые данные и но обработанные), чтобы не было 0xFF. С потерями в сигнале, естественно. Говорю: "А в других местах, где надо будет передавать двоичные данные - как?" (таких мест тогда было известно ещё одно). В ответ - опять набор правил как выбирать данные, так чтобы там не было 0xFF. С кучей ограничений.
Пытаюсь спросить: "Зачем куча таких ограничений если можно реализовать просто элементарный стандартный протокол с байт-стаффингом???" В ответ что-то невразумительное, типа: "Ваш байт-стаффинг какой-то слишком сложный для нашей задачи. Нам такие сложности не нужны. Можно всё проще сделать".
Пытаюсь доказывать, что всё это - сплошной колхоз, обнесённый забором из грабель - бесполезно: "Мы хотим так, заказчик всегда прав".
Пытаюсь доказывать, что в будущем почти наверняка потребуется что-то доработать, расширить функционал, а такой кривой протокол будет всегда бить по башке. Не слышат. Как об стенку.
Чувствую, что не сам это заказчик придумал, а кто-то за ним говорит, его языком. Там у него был такой паренёк, который на компе под виндой должен был взаимодействие по данному протоколу с устройством писать. Чувствую что это он заказчиком рулит - в уши ему дует, а тот слушает (благо - он под боком всё время, а я - далеко). Позже пообщавшись с этим пареньком, по некоторым техническим вопросам реализации собственно обмена, на некоторых аспектах просто выпадаю в осадок - ни о каком уровне профессионализма там даже говорить не приходится!
Становится ясно, почему "байт-стаффинг слишком сложный".
Ок - пишу для него функции приёма и передачи, которые он просто вставит в свой код, даст приёмной() на вход поток байт, а она ему будет выплёвывать кадры, ну и передающую() - в обратном порядке.
Отправляю ему с описанием куда и чего нужно подавать. Проходит время.... тишина - то ли не понял, то ли что-то не получилось. Вобщем - ни в какую не хочет использовать кодонезависимый фрейминг.
Ну что делать - пришлось скрепя сердце согласиться делать этот колхоз на квадратных колёсах.
Ну и естественно как и ожидалось - ещё даже на этапе написания первых версий ПО, вдруг потребовалась передача дополнительных данных, которые опять произвольные двоичные. Да ещё в них просто так не удалишь какие-то значения заменив на соседние как с данными АЦП (там просто ну чуть больше шума появляется). Что делать? Тот паренёк долго думает, потом придумывает ещё более развесистый колхоз, когда надо было в данных что-то искать (не помню уже что), и "если так - то так, если этак - то этак". Границы кадров сделать по 5 шт. 0xFF. А те данные, где могут появляться 0xFF, обнести другими, в которых 0xFF заведомо нет (максимальный размер каждого данного был 4 байта, поэтому если их проредить другими, то будет не более 4 шт. 0xFF подряд).
Вобщем - изобрёл костыль к своему творению.
Приходится реализовывать - делать нечего. А ещё - девайс-то батарейный. Этому пареньку то пофигу под виндой, а у меня каждый мА на счету, а тут куча лишних вычислений по перетасовке данных....
Пытаюсь вразумить заказчика, показывая ему, что сложность реализации и потенциальные глюки получившегося колхоза уже много сложнее всех байт-стаффингов вместе взятых. Он уже молчит. Потом говорит, что уже много девайсов продано. И переделывать всё заново - слишком долго и накладно. Ну сделали - фиг с ним, постарался побыстрее забыть этот мрак.
Проходит пару лет, тот же заказчик стучится, просит ещё кой-какой функционал добавить. Оказывается - для полной реализации всех хотелок надо всё-таки нормальные двоичные данные передавать. А с имеющимся колхозом - никак. Говорю: "Я же вас предупреждал ещё тогда, много раз!". В ответ: "Да, надо было делать конечно как правильно, но тогда надо было побыстрее и думали что на том и остановимся и больше ничего не надо будет. Ну а теперь сделай что можешь, а уже лучше мы сделаем в следующем девайсе". Приходится заказчику урезать свои хотелки - сам виноват.
Попутно выясняю, что паренёк тот уволился из конторы, бросил этот проект так и не доведя его до рабочего состояния. Заложив им такую кучу г@#$а, что до сих пор разгрести не могут.
Вот такая грустная история про самописные протоколы "лишь бы попроще, и так сойдёт".
Битые записи в массиве.
Jul 17 2018, 06:18
Особенно про "добавить функционал, там же немножечко..." 
