Протокол 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]

Или Вы предлагаете после получения совпадения CRC продолжать принимать пакет, параллельно пересчитывая CRC и убеждаясь (по другим признакам) что пакет битый, после чего ждать нового совпадения CRC?

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

Данное нарушение пока не стало частью стандарта. И пока это является именно грубым нарушением.

Нет никакого нарушения стандарта, тем более грубого:

Код

1. При совпадении CRC текущего пакета background task создает копию принимаемого пакета,
    и записывает перекресную ссылку (друг на друга) в текщий пакет и его копию,
    а также взводит callback c таймаутом на отправку копии пакета.
2. background task приступает к формированию ответа на запрос незамедлительно,
    ответ на запрос формируется в этой же копии пакета.
3. Взависимости от того что наступит раньше - вызов callback'а по таймауту
    или прием символа по уарту:

     a. вызов callback'а наступает раньше.
          - удаляется перекресная ссылка из пакета и копии пакета (т.е. копия отвязывается от приемника)
          - приемник (оригинал пакета) обнуляется - переход к приему нового пакета
          - проверяется полностью ли сформирован ответ на запрос:
            если ответ сформирован, тогда
            он нативно отправляется ровно через указанный в стандарте минимальный межпакетный интервал
            (в 99% случаев имеет место именно этот случай).
          - если ответ еще не сформирован - повторно взводится callback с таймаутом в одно-символьный интервал.
     b. eсли раньше примется символ, прошло не более 1.5 символьного интервала от последнего принятого символа,
         копия помечается как бракованая (при вызове callback'a удалится автоматически), а символ добаляется к текущему
         пакету и подсчет CRC продолжается.
     с. если раньше примется символ, но 1.5 символьный таймаут уже пройден -
         копия пакета помечается как бракованая и оригинальный пакет обнуляется.

Собсно вот так у меня реализовано, алгоритм ниоткуда не слизанный, просто устройств в сети много, и опрашиваются непрерывно. Эти 1-2% КПД канала это +1..2 устройства в сети без ухудшения характеристик всей системы.

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

Расскажите это мастеру который хочет прочитать данные со слейва которые лежат в i2c eeprom'е. Если быть точнее - расскажете мастеру почему ответ на его запрос появляется не через 3.5 символьных интервала, а через 7 (4-5ms - среднее время i2c транзакции).

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

Я считаю, гоняться за наносекундами в обработчиках прерываний - нет смысла. Что 32 регистра в стек будет сохраняться что 1, какая разница? это вопрос микросекунды. А если что-то совсем совсем критичное ко времени реакции - проще поставить плиску или какой-нибудь мелкий МК в помощь, чем лишать себя свободы в обработчиках прерываний. Тобиш минимальное время реакции это удел мелких проектов. В крупных проектах бывает удобно уменьшать число прерываний как таковых за счет пакетной обработки нескольких прерываний от нескольких периферийных модулей за один заход. Реакция возрастает, но накладные расходы на вход-выход в обработчик снижаются пропорционально количеству обработанных за один заход прерываний.

А вот там где счет идет на миллисекунды, предпочитаю их не терять.
Максимальный КПД канала он к любому протоколу применим, в т.ч. и к Модбас, т.к. в нем минимальное время между пакетами оговоренно стандартом, вот к нему надо стремиться.
Да и на 485-м можно иметь вполне причную скорость ~2Mbps.