Протокол modbus. Вопросы по интерфейсу Опции

[Phuntik]

Здравствуйте.
На работе дали задание разработать интерфейс сообщений между устройствами на основе протокола Modbus.
Суть такова. Есть некоторое количество измерительных приборов, соединённых по RS-485. Нужно сделать так, чтобы с одного прибора можно было управлять другим - устанавливать режимы, принимать архивы измерений и т.д. За основу предложено взять протокол modbus.
Уже месяц сижу и туплю.
Вопросы:
1. Можно ли сделать так, чтобы любое устройство могло взять на себя роль главного?
2. Каким образом вообще передавать информацию главному? Через регистры, что ли?
3. С чего вообще начинать?
Подскажите, пожалуйста, ткните носом во что-нибудь готовое, описание какое-нибудь.
Протокол зачитал, но там, такое ощущение, всё привязано к конкретным контроллерам.

[rezident]

koyodza, @Ark, зачем нужно старую тему поднимать? Думаете, что топикстартер, создавший ее год назад и тогда же последний раз в ней отметившись, прочитает?

[koyodza]

koyodza, @Ark, зачем нужно старую тему поднимать? Думаете, что топикстартер, создавший ее год назад и тогда же последний раз в ней отметившись, прочитает?

Я ответил скорее не топикпастеру, а на фразу defunct по поводу того что "По приему CRC слейв может сразу же приступить к формированию ответа". Поскольку это грубое, но очень сильно распространенное нарушение стандарта, решил указать на это. Сообщения ведь попадают в "Копилку Вечности", вдруг кто-то из начинающих когда-то забредёт сюда (даже в правилах написано - новую тему создавать после того, как ничего не нашел поиском), и подумает что так и нужно делать...

[defunct]

Я ответил скорее не топикпастеру, а на фразу defunct по поводу того что "По приему CRC слейв может сразу же приступить к формированию ответа". Поскольку это грубое, но очень сильно распространенное нарушение стандарта, решил указать на это.

Стандарты порой устаревают. А сильно распространненные нарушения часто становятся частью страндарта.
Грубых нарушений стандарта в упор не вижу, если CRC сошлась ложно, то пакет отбракуется по длине и прием продолжится.
С другой стороны, на кой в холостую ждать 3.5 символьных интервала (это ж вагон и еще маленькая тележка времени особенно на 9600 и ниже), когда их можно потратить с пользой, например на вычитку архива из медленного eeprom'а по текущему запросу мастера.

Сообщения ведь попадают в "Копилку Вечности", вдруг кто-то из начинающих когда-то забредёт сюда (даже в правилах написано - новую тему создавать после того, как ничего не нашел поиском), и подумает что так и нужно делать...

Может для "Копилки Вечности" у вас найдется способ отмерить таймаут в 1.75ms под Windows?

[koyodza]

Стандарты порой устаревают. А сильно распространненные нарушения часто становятся частью страндарта.
Грубых нарушений стандарта в упор не вижу, если CRC сошлась ложно, то пакет отбракуется по длине и прием продолжится.

Данное нарушение пока не стало частью стандарта. И пока это является именно грубым нарушением.
Вы никогда не получали совпадение CRC внутри пакета? Значит Вы не использовали ModBus в реальных проектах. Или Вам просто пока крупно везло.
Или Вы предлагаете после получения совпадения CRC продолжать принимать пакет, параллельно пересчитывая CRC и убеждаясь (по другим признакам) что пакет битый, после чего ждать нового совпадения CRC?

С другой стороны, на кой в холостую ждать 3.5 символьных интервала (это ж вагон и еще маленькая тележка времени особенно на 9600 и ниже), когда их можно потратить с пользой, например на вычитку архива из медленного eeprom'а по текущему запросу мастера.

"Вычитка" архива (да пусть хоть даже и запись) никакого отношения к процедуре обмена не имеет. Даже если вычитываются запрошенные данные, лучше не начинать "вычитку" не приняв до конца запрос.

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

Может для "Копилки Вечности" у вас найдется способ отмерить таймаут в 1.75ms под Windows?

Windows вообще никакого отношения к ModBus не имеет. Ну а если в качестве мастера у Вас выступает РС - никто не запрещает сделать интервал больше, чем 1,75 мсек. Приемлемые таймауты в единицы мсек отрабатываются нормально.

Есть две разные задачи.
1. обеспечить Real-time - см. real-time protocol который с помощью меток времени и блочной передачи, вне зависимости от задержек канала и межпакетного джиттера, гарантирует real-time воспроизведение медиа потока.
2. обеспечить максимально возможный КПД использования канала.

То о чем говорите Вы решает 1), то о чем говорит @Ark решает 2).

Минимальное время реакции на прерывания по разным причинам приходится обеспечивать в большинстве достаточно крупных проектов.
А вот понятия modbus и "максимально возможный КПД использования канала" - не вполне совместимы. Обычно modbus применяется там, где загрузка канала не очень высока. Иначе - нужно выбирать другой протокол, а (возможно) и другую "физику" (т.е. не 485)

[defunct]

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

Разные уровни обмена не нужно смешивать разумеется. Только вот идеи на которые Вы ссылаетесь примерно такого плана: а давайте чтобы сократить время реакции прерывания разобъем канальный уровень на два подуровня, первый подуровень канального уровня будем обслуживать в прерывании, а второй - постобработкой. Ничего что для этого придется обзавестись большим буфером памяти, зато реакция на прерывание будет быстрой. И ради чего? Разница ведь в нано-, микро- секундах исчисляется. Снижаем реакцию на прерывание просто ради получения минимальной реакции?! Дык с тем же успехом можете просто разрешить другие прерывания в обработчике текущего, реакция будет еще быстрее.


Ethernet MAC - пример канального уровня, выдает пакеты, а не байты которые надо собирать в пакеты. И выдает прерывания "пакет" принят а не байт принят. Так вот объясните мне доходчиво если можно, почему модель программиста канального уровня Ethernet должна отличаться от модели канального уровня PPP или того же Modbus? И зачем делать двойную работу? Зачем накапливать в памяти что-то непотребное, - escaped chars, пакеты нам не адресованые, метки времени на каждый принятый символ для определения таймаутов, и прочее г. которое можно отсеяться сразу в прерывании.

[Verifi]

Зачем накапливать в памяти что-то непотребное, - escaped chars, пакеты нам не адресованые, метки времени на каждый принятый символ для определения таймаутов, и прочее г. которое можно отсеяться сразу в прерывании.

Совершенно согласен по началу принятия пакета проверяете адрес ежли это не ваше ,то просто проверяете CRC в буфере приёма,и только если CRC не правильная или ставите флаг и обрабатываете в обработчике ошибки, либо сразу выходите из прерывания с подменой стека со смещением стека на обработчик соответствующий ошибке и соответственно надолго в прерывании не задерживаетесь.
Данным образом реализовал мастер модбус на 51 ядре с буфером приёма-передачи в 128байт интервалы пакетов контролируются в прерываниях по таймеру и по UART.