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

[Phuntik]

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

[rezident]

2 defunct, еще раз обращаю внимание, что я писал про общий случай, а не про тот, когда устройство только связью занимается. И не про канальный уровень, а про физический, когда обработка прерывания по времени должна занимать как можно меньше времени. Потому, что могут быть и другие прерывания тоже критичные ко времени. Ничего не имею против вашего мнения, но получается, что вы сами себе возражали, т.к. переиначили мое сообщение так, чтобы вам было удобно возражать

[defunct]

И не про канальный уровень, а про физический,

Выше Вы привели ссылку на модель OSI, вы ее читали?

Физический уровень
Самый нижний уровень модели предназначен непосредственно для передачи потока данных. Осуществляет передачу электрических или оптических сигналов в кабель или в радиоэфир и, соответственно, их приём и преобразование в биты данных в соответствии с методами кодирования цифровых сигналов. Другими словами, осуществляет интерфейс между сетевым носителем и сетевым устройством.

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

Физический уровень это сугубо природа сигналов, трансивер и иже с ним сдвиговый регистр и схема битового кодированая (манчестер, инверсия и т.п.). А выделением из мусора битов входного потока осмысленных данных, проверкой ошибок, занимается уже канальный уровень, на ступеньку выше. Прерывание от UART "кадр принят" это не физ, а канальный уровень.

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

просто показал что имеет смысл собирать пакеты побайтово прямо в прерывании, а не наваливать бездумно все байты в буфер перекладывая тем самым работу канального уровня на сетевой уровень. Для примера взял PPP который в отличие от Modbus является протоколом строго канального уровня.

[rezident]

Выше Вы привели ссылку на модель OSI, вы ее читали?

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

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

в моем описании отсутствует. Вообще сетевая модель OSI это лишь идеал. В реальности крайне мало (стеков) протоколов которые бы полностью укладывались в эту модель. Возможно я вообще зря ее упомянул.

[defunct]

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

Не совсем, у Вас в описании просматривается часть характеристки канального уровня - проверка правильности принятых данных (по крайней мере четность).

Вообще сетевая модель OSI это лишь идеал. В реальности крайне мало (стеков) протоколов которые бы полностью укладывались в эту модель. Возможно я вообще зря ее упомянул.

Согласен, однако если грань между верхними тремя уровнями (session/presentation/app) настолько мала что ее часто трудно найти особенно в embedded сфере, то границы между нижними уровнями физ, канал, транспорт - просматриваются довольно четко. И хотя бы на этих трех уровнях можно пытаться стремиться к идеалу:

<физ уровень> --> сводится к драйверу железа или эмулятору железа (программый UART/ программный SPI)
<канальный уровень> ---> разбиение пакетов на голые байты и передача их драйверу железа, прием голых данных от железа и укладка в пакеты
<сеть> --> маршрутизация (проверка сетевого адреса).
<транспорт> --> укладка и выделение пользовательских данных в/из пакетов.

сетевой уровень (который лежит между транспортом и каналом) можно взависимости от конкретного протокола, объединять или с транспортным или с канальным уровнем. В случае одноранговой сети Modbus его выгоднее объединить с канальным уровнем, в случае многоранговой IP сети - с транспортным.

[rezident]

Не совсем, у Вас в описании просматривается часть характеристки канального уровня - проверка правильности принятых данных (по крайней мере четность).

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

<физ уровень> --> сводится к драйверу железа или эмулятору железа (программый UART/ программный SPI)
<канальный уровень> ---> разбиение пакетов на голые байты и передача их драйверу железа, прием голых данных от железа и укладка в пакеты
<сеть> --> поиск и проверка маршрутов
<транспорт> --> укладка и выделение пользовательских данных в/из пакетов.

ОК. Достаточно. Я вас понял. Вы канальный уровень вешаете на прерывания. Я где-то раньше так тоже делал. Но в других проектах мне показалось это нецелесообразным.