uMCPIno: Пишем простой протокол с гарантированной доставкой для Arduino

[Schrodingers_Kater]

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

[podde]

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

[tnt23]

DDCMP протокол занятный, между прочим его используют как один из протоколов снятия статистики с торговых автоматов — но почему у автора аыбор пал на него? не самый простой все же протокол, как мне кажется, с издержками вроде Link layer, которым в простых случаях вроде нашего можно пренебречь

[AlekDikarev]

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

[edo1h]

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

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

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

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

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

[AlekDikarev]

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

[edo1h]

Что касаемо экранирования сигнатуры начала пакета — пока решил не усложнять.

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

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

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

[AlekDikarev]

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

[edo1h]

а там есть физическая возможность определить что байт однозначно побит (по MSR — Main lobe to sidepeak ratio на приемнике)

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

[Ryppka]

Кажется, что все «счастливые» протоколы сильно одинаковы: очень напомнило XModem и т.д. Общий корень?

[AlekDikarev]

Все подобные протоколы в какой-то степени похожи. XModem вроде попроще, без Pipelining-а, установка соединения там менее устойчива и т.п. Я бы сказал что корень здесь все-таки от DDCMP. Минимальные совпадения XModem случайны и есть в виду похожести решаемых задач (ну, как большинство автомобилей — 4-х колесные).

[ladle]

… DIY-щику перестает хватать гегелевского Arduino как «вещи-в-себе» ...

Скорее уж кантовского.

[AlekDikarev]

О, благодарю, исправил! Отличное замечание!