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

[Phuntik]

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

[rezident]

Ну вот и консенсус наметился Считайте, что у меня реализован программный буфер FIFO. Только память, выделяемая под него, не только канальным уровнем используется, но и уровнем приложения. Для сокращения расхода RAM и потому, что ответов с микросекундной задержкой не требуется по условиям моего задания.

[defunct]

Считайте, что у меня реализован программный буфер FIFO. Только память, выделяемая под него, не только канальным уровнем используется, но и уровнем приложения.

Только объем буфера в десятки-сотни раз больший требуется, чем величина fifo.

Для сокращения расхода RAM и потому, что ответов с микросекундной задержкой не требуется по условиям моего задания.

Где ж тут сокращение расхода RAM? Когда наоборот.
У меня командная консолько и та разбита на канальный уровень, на канальном уровне обслуживаются CR, LF, UP, DOWN, CTRL-H, CTRL-C, CTRL-... служебные символы.
Самой консольке же идут только осмысленные команды. Требования к буферу - строго детерминированны макс длиной команды, а если просто складывать все принятое подряд какой размер буфера брать?..

[rezident]

Только объем буфера в десятки-сотни раз больший требуется, чем величина fifo.

Не преувеличивайте. Размер буфера определяется максимальной длиной фрейма ответа. Для случая ModBus RTU это 256 байт.

[defunct]

Не преувеличивайте. Размер буфера определяется максимальной длиной фрейма ответа. Для случая ModBus RTU это 256 байт.

А где преувеличение? Сколько байт fifo потребуется? 2? 4? 8? 256 / 8 = 32. В 32 раза.

Следуя вашей схеме - сетевые адреса в прерывании у вас не обслуживаются и таймауты тоже - значит приемный буфер должен покрывать два RTU пакета - а это 256x2 байт.
А что с консолькой? Что с PPP? и там и там управляющие символы есть. Даже при известном MRU наличие упр. символов увеличивают требования к буферу - 2*MRU, а если учесть что ранжирование на пакеты делается приложением получается требования к буферу 4 * MRU.

[rezident]

Следуя вашей схеме - сетевые адреса в прерывании у вас не обслуживаются и таймауты тоже - значит приемный буфер должен покрывать два RTU пакета - а это 256x2 байт.

Это ваша схема выходит, а не моя. Зачем 2*256? Пока уровень приложения обрабатывает запрос, переданный ему с канального уровня, прием вообще запрещен. По истечение времени, выделенного уровню приложения на обработку запроса, если ответ еще не готов, то автоматически формируется типовой ответ "BUSY". Для него большого буфера не нужно.

[defunct]

Это ваша схема выходит, а не моя.

Да ну, я то как раз за то, чтобы выделять пакеты адресованные слейву в прерывании.
или все-таки сетевые адреса и таймауты у вас обслуживаются в прерывании? Тогда Вы противоречите сами себе.

Зачем 2*256?

Если не распознавать адрес и не обслуживать таймаут в прерывании.
То как Вы определяете, когда прекращать прием?

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

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

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

Это же TX буфер, а мы вроде как про RX...