Pull to refresh

Comments 13

Стиль написания статьи напомнил научно-познавательные передачи из детства — порадовало)

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

DDCMP протокол занятный, между прочим его используют как один из протоколов снятия статистики с торговых автоматов — но почему у автора аыбор пал на него? не самый простой все же протокол, как мне кажется, с издержками вроде Link layer, которым в простых случаях вроде нашего можно пренебречь
Просто когда-то давно он мне попался на глаза, на позапрошлой работе мы с коллегой на его основе целых три уровня разработали. В итоге все конечно ушло в стол. Мне хотелось гарантированную доставку, восстановление после сбоя, решать проблемы по максимуму через таймауты и чтобы все влезло в Arduino — поэтому я запилил этот протокол на основе DDCMP, повыкидывав из него адресацию, NAK-и и знатно переделав framing.

А почему не сделали экранирование UMCP_START_SIGN как в PPP, например?
CRC8 не мало для зашумлённых линий?


Почему тут Боб шлёт "начинаю приём"?
image


И да, не хватает такой же картинки для вашего протокола.


Самое важно в работе с этим флагом то, что один из узлов должен иметь этот флаг по умолчанию, а другой — нет.

то есть инициировать связь может только одна сторона?

Спасибо за замечание по поводу картинки. Ошибка копипасты — все исправлено.
Что касаемо экранирования сигнатуры начала пакета — пока решил не усложнять. Про CRC8 — размер пакета не предусматривается больше 255 байт в принципе (сейчас 64 байта), так что думаю смысла использовать CRC16 нет.
По поводу инициирования связи — инициировать и переинициализировать может (и должна!) любая сторона. В процессе, пока соединение не установлено это допускается.
Что касаемо экранирования сигнатуры начала пакета — пока решил не усложнять.

да там несколько строк кода же


Про CRC8 — размер пакета не предусматривается больше 255 байт в принципе (сейчас 64 байта), так что думаю смысла использовать CRC16 нет.

размер пакета не так важен (если он больше одного байта). важно, что с вероятностью не менее 1/256 случайные данные покажутся правильными.

Согласен, это хорошее предложение и я скорее всего допилю код в плане экранирования сигнатуры.
Про CRC8 тут немного иная ситуация. Так как я хотел применять протокол для наших модемов (можно сказать, это была просто фаза 1), а там есть физическая возможность определить что байт однозначно побит (по MSR — Main lobe to sidepeak ratio на приемнике) или пакет дошел не целиком, то, в принципе, CRC8 там как изолента поверх сварного шва. Я просто пока не уложил в голове, как это удобнее сделать.
С другой стороны, если кому требуется — несложно заменить на CRC16. Может позже добавлю тип CRC как настройку.
а там есть физическая возможность определить что байт однозначно побит (по MSR — Main lobe to sidepeak ratio на приемнике)

кстати, некоторые ЕСС умеют использовать это знание.

Кажется, что все «счастливые» протоколы сильно одинаковы: очень напомнило XModem и т.д. Общий корень?
Все подобные протоколы в какой-то степени похожи. XModem вроде попроще, без Pipelining-а, установка соединения там менее устойчива и т.п. Я бы сказал что корень здесь все-таки от DDCMP. Минимальные совпадения XModem случайны и есть в виду похожести решаемых задач (ну, как большинство автомобилей — 4-х колесные).
… DIY-щику перестает хватать гегелевского Arduino как «вещи-в-себе» ...

Скорее уж кантовского.
О, благодарю, исправил! Отличное замечание!
Sign up to leave a comment.

Articles