Комментарии 28
Переизобрели модель OSI ? :)
Видится, что автор сделал ровно наоборот. Смешал мух и котлеты. Протокол должен быть легко разделяем по уровням. Потому как преамбулы и пакетизация должны находиться на одном уровне, а к примеру, пэйлоад и контрольные суммы на другом. Если в качестве транспорта используется udp — нет смысла городить пакетизацию, преамбулы и прочая — это все уже реализовано, оставляем только часть ответственную за обработку пэйлоада. Если у нас голый битовый/байтовый поток типа uart — да, все это может понадобится в каком-то виде. Но обработчик пейлоада не меняется, над ним появляется надстройка которая выковыривает с транспорта собсно пейлоад и отправляет на обработку. Есть, конечно, нюансы в виде таймштампов или там контрольных сум, на каком уровне они должны быть, но это вопрос требований к точности и достоверности.
А пассаж про бигендиан вообще прекрасен, видите ли так удобней кожаным мешкам интерпретировать дату на осциле или в хексе, а то что бедный процессор будет переворачивать эти данные каждый раз (если он литтлендиан, что наиболее вероятно) никого не заботит. Отлаживают протокол все таки меньше времени, нежели он используется, все эти миливатты потраченные железом на бессмысленное вращение байтов наносит ущерб экологии )
Про шифрование тоже хорошо. И была б это рекомендация или пожелание, одно дело, а то ведь маст хэв. Хардкорного эмбедда на 8битных контроллерах вам в хату.
Зачем нужен бит "честности" при живом CRC? Чтобы что?
В упустили главное правило: "не начинайте колхозить протокол с формата пакетов"
C чего же тогда вести разработку протокола если не с формата пакета?
По заветам ПМБука, с анализа ситуации, в т.ч ошибок предшественников.
Вообще-то, желание упорядочить требования к протоколу заслуживает одобрения, я считаю.
Хотя классификации подобного рода встречались и ранее
животные делятся на:
а) принадлежащих Императору,
б) набальзамированных,
в) прирученных,
г) молочных поросят,
д) сирен,
е) сказочных,
ж) бродячих собак,
з) включённых в эту классификацию,
и) бегающих как сумасшедшие,
к) бесчисленных,
л) нарисованных тончайшей кистью из верблюжьей шерсти,
м) прочих,
н) разбивших цветочную вазу,
о) похожих издали на мух.
Видите ли, формат пакета - технический компромисс, получающийся в результате анализа требований к протоколу, как части системы, обеспечивающей решение какой-то задачи. Поэтому начинать надо с другого.
Во-первых, посмотреть на модель ISO/OSI, как вам уже указали ранее. Как справедливо замечено, вы увидите, что в ваших требованиях смешаны части формата, отвечающие за различные уровни. После этого надо раскаяться и все-таки почитать про эту модель, она вам понадобится, если вы хотите реализовать хороший протокол.
Во-вторых, понять, что в первую очередь надо рассмотреть уровни модели от 8 и выше, которых в текущей редакции модели нет. Это требования к системе, в которой будет применяться протокол. Здесь поможет внимательное чтение ПМБука или даже ГОСТ на ТЗ для АСУ.
Вот, примерно накидал (здесь также смешаны уровни, но это и не статья):
Имеет смысл рассматривать сценарии использования на всех этапах жизненного цикла вашего оборудования. Например, может оказаться, что протокол предназначен для настройки системы обслуживающим персоналом, в этом случае часто удобно делать его текстовым. Для payload M2M протоколов часто используется JSON или XML, в том числе, со сжатием, в этом случае объем сравним с бинарным представлением. Библиотеки для работы с ними не очень сложные. Таким образом, п.1 можно вычеркнуть. Программисты серверной части скажут вам спасибо.
Можно проанализировать окружение: протокол нужен для связи между микроконтроллером и датчиком в пределах одной платы или для контроля транспортных средств в пределах региона? Система состоит из однородных или разнородных элементов? Протокол открытый или закрытый? Планируется ли расширение номенклатуры, совместимость с имеющимися устройствами или подключение устройств сторонних производителей? Например, если у вас внутренний протокол между электронными платами по шине SPI с сигналом #CS, то пп.2,3,4,5,6,8,12,15,16,17 можно вычеркнуть, если по шине I2C, то можно вычеркнуть пп.2,3,5,10,15.
Кроме того, стоит рассмотреть физические ограничения: вычислительная мощность узлов, энергопотребление, требуемая скорость обмена, задержки, надежность. Предполагаемая среда передачи данных и/или аппаратная реализация. Например, если интерфейс CAN, то п.2,4,5,6,7,8,10,15,17 не имеют смысла. Если оптика, то п.14 не выглядит необходимым.
Таким образом, аргументированным выглядит только п.13.
Вооружившись средствами редактирования электронных таблиц и моделью ISO/OSI следует определить требования к уровням сверху вниз, возможно, не все уровни модели будут необходимы:
Имеет смысл прикинуть API, лучше для каждого уровня.
Будет полезно описать виды передаваемых данных и требования к ним.
Также не лишним будет подумать над структурой сети: точка-точка, ведущий-ведомый, мультимастер, одноранговая сеть, ретрансляция т.п.
После этого станут яснее требования к алгоритмам взаимодействия узлов: handshaking, PnP, подписки, каналы, разделяемая память, квитирование, таймауты, арбитраж, асинхронные сообщения и т.п.
пп.1-4 повторять до просветления.
После этого оценить затраты на реализацию. Не стоит забывать про альтернативные варианты. (Имеет смысл их все-таки изучить, потому что CAN и ModeBus это немного про разное).
Описать форматы пакетов.
Начинаю читать и вижу "канальный протокол ModeBus". Ну с кем не бывает - опечатка. А потом вижу эту опечатку в тексте не раз.
А дальше читаю о том, что "многие российские компании просто не могут себе позволить купить на них лицензию и спецификацию". На открытый протокол Modbus. Купить не могут.
И ведь очень правильно вы пишете: "Не надо изобретать очередной проприетарный протокол". Я полностью с этим согласен, особенно когда есть ряд открытых, давно отлаженных протоколов, для которых существует масса библиотечных реализаций.
Но читать я дальше не стал - нет доверия к техническому тексту, который начинается такими ляпами.
раді інтереса посмотрел, какойжэ он убогій, этот ваш модбас, ні заголовка ні конца передачі.
паузы как часть протокола это вапшчэ трэш - попробуй отправіть длінный пакет спод говновіндозы на большой скорості без пауз.
Вы правы, для таких применений Modbus не лучший выбор.
Однако, несмотря на древность, если необходимо обеспечить в оборудовании считывание данных и запись настроек на небольших скоростях, я бы рекомендовал использовать именно его.
Кстати, какой протокол используете вы?
посмотрел у мелкочіп из AN851 AN1310. по этому протоколу можно перепрограммировать микроконтроллеры (сами себя) из старого мплаб или отдельной оболочки или из своей програмки. только добавил по аналогии команды для рам.
по описанию он весьма близок вашей статье.
Спасибо. Типичный протокол для своей области применения. Запомню, возможно, пригодится.
Модель представления устройств примерно как у Modbus, только адресация 3 байта.
Байт-стаффинг обычно применяется, если необходимо выделять пакеты в потоке байтов на шине при спорадическом подключении. Или при недостатке ресурсов. Судя по всему, памяти было впритык.
В целом, я обычно как раз Modbus применяю в таких случаях - области памяти можно страницами переключать. Не оптимально, зато стандартно - тестирование и документирование проще.
На мой взгляд использовать байт-стаффинг для канального уровня гораздо лучше, чем альтернативы: не надо знать заранее размер передаваемых данных; границы пакета всегда чётко определены; если использовать COBS, избыточность контролируема; подходит под любые скорости.
Неочевидные преимущества для программной реализации. С какими альтернативами контроля границ пакета вы сравниваете?
Насчет контролируемой избыточности: тоже сомнительный аргумент, это понадобится разве что на грани пропускной способности линии. Но в этом случае, скорее BER будет расти так, что все преимущества будут нивелированы.
При этом, байт-стаффинг вообще прост для аппаратной реализации, потому что не требует больших ресурсов - можно сразу пакеты в память начинать выдавать, например Я однажды использовал для синхронизации устройств по UART, сейчас не уверен, что поступил бы также.
Сравнивал я с определением границ кадра по преамбуле, с определением границы по таймауту, с использованием длины данных в заголовке.
Эти все варианты зачастую порождают сложные эмпирические алгоритмы по восстановлению/синхронизации, теряют корректные кадры, если предыдущие потеряли символ.
Контролируемая избыточность это сильный аргумент: простые алгоритмы байт-стаффинга могут привести к удвоению размера всего кадра, а это и лишняя память под буферизацию, искажение временных характеристик -- это не дело, когда в зависимости от содержимого кадры передаются за разное время. В COBS, например, максимальные затраты это 1 байт на 254 байта исходного кадра.
Байт-стаффинг очень универсален -- подходит под любые скорости и устройства, не чувствителен к буферизации в устройствах ввода, его можно реализовать и отладить отдельно от верхних уровней протокола.
За 10 лет опыта никогда не видел чтобы кто-то использовал в Embedded прошивках Байт-стаффинг.
Обычно всем хватает пакетной синхронизации по TimeOut или захват пакета по преамбуле.
Ну, пример для обновления прошивки PIC привели выше (20 лет). Сейчас ресурсов обычно достаточно, поэтому не часто встречается. Но бит или байт стаффинг аппаратно реализуется во многих шинах.
И это печально, что такой более совершенный метод не используется.
C таймаутами возникает проблема по полной утилизации линии, а с преамбулами, как я писал выше, встречал странные алгоритмы восстановления синхронизации.
Байт-стаффинг очень универсален -- подходит под любые скорости и устройства, не чувствителен к буферизации в устройствах ввода, его можно реализовать и отладить отдельно от верхних уровней протокола.
Реализовать и отладить выборку фреймов можно, но все равно придется обрабатывать ошибки - здесь все преимущества потеряются. Оправдано, на линии точка-точка с малыми потерями если скорость определяется ресурсами микроконтроллера
Или при недостатке ресурсов. Судя по всему, памяти было впритык.
последней редакцыи документа 20 лет, а исходникам еще больше. ходовые мк имели рам до 1к.
Очередное частное мнение, выданное под заголовком общих правил...
Вы бы хотя бы область применимости утверждений обозначили.
Кстати, по поводу CRC. Когда Вы пишете CRC, Вы подразумеваете именно CRC или же любой алгоритм вычисления контрольной суммы?
Хочется много и по пунктам рассказать автору. Но, если коротко, он выдал свой собственный опыт как он его понимает, поделился. Видимо, есть богатый опыт изобретения собственных протоколов, который ему и говорит, что их изобретать было не нужно.
19 Атрибутов Хорошего Канального Протокола Передачи Данных