| |
 Протокол modbus. Вопросы по интерфейсу |
|
|
|
|
 Oct 16 2008, 10:46
|
Группа: Новичок
Сообщений: 2
Регистрация: 16-10-08
Пользователь №: 40 997
|
Здравствуйте.
На работе дали задание разработать интерфейс сообщений между устройствами на основе протокола Modbus.
Суть такова. Есть некоторое количество измерительных приборов, соединённых по RS-485. Нужно сделать так, чтобы с одного прибора можно было управлять другим - устанавливать режимы, принимать архивы измерений и т.д. За основу предложено взять протокол modbus.
Уже месяц сижу и туплю.
Вопросы:
1. Можно ли сделать так, чтобы любое устройство могло взять на себя роль главного?
2. Каким образом вообще передавать информацию главному? Через регистры, что ли?
3. С чего вообще начинать?
Подскажите, пожалуйста, ткните носом во что-нибудь готовое, описание какое-нибудь.
Протокол зачитал, но там, такое ощущение, всё привязано к конкретным контроллерам.
|
|
|
|
|
|
|
 |
Ответов
|
|
Nov 15 2009, 03:22
|
кекс
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326
|
Цитата(rezident @ Nov 15 2009, 05:19)  Считайте, что у меня реализован программный буфер FIFO. Только память, выделяемая под него, не только канальным уровнем используется, но и уровнем приложения.  Только объем буфера в десятки-сотни раз больший требуется, чем величина fifo. Цитата Для сокращения расхода RAM и потому, что ответов с микросекундной задержкой не требуется по условиям моего задания. Где ж тут сокращение расхода RAM? Когда наоборот. У меня командная консолько и та разбита на канальный уровень, на канальном уровне обслуживаются CR, LF, UP, DOWN, CTRL-H, CTRL-C, CTRL-... служебные символы. Самой консольке же идут только осмысленные команды. Требования к буферу - строго детерминированны макс длиной команды, а если просто складывать все принятое подряд какой размер буфера брать?..
|
|
|
|
|
|
|
|
Nov 15 2009, 04:10
|
кекс
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326
|
Цитата(rezident @ Nov 15 2009, 05:59) Это ваша схема выходит, а не моя. Да ну, я то как раз за то, чтобы выделять пакеты адресованные слейву в прерывании. или все-таки сетевые адреса и таймауты у вас обслуживаются в прерывании? Тогда Вы противоречите сами себе. Цитата Зачем 2*256? Если не распознавать адрес и не обслуживать таймаут в прерывании. То как Вы определяете, когда прекращать прием? Цитата Пока уровень приложения обрабатывает запрос, переданный ему с канального уровня, прием вообще запрещен. Не вопрос пусть так, но ведь в RX прерывании складываете все подряд, в т.ч. пакеты адресованные другому слейву и ответы других слейвов. Цитата По истечение времени, выделенного уровню приложения на обработку запроса, если ответ еще не готов, то автоматически формируется типовой ответ "BUSY". Для него большого буфера не нужно. Это же TX буфер, а мы вроде как про RX...
|
|
|
|
|
|
|
|
Nov 15 2009, 18:15
|
Гуру
Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882
|
Цитата(defunct @ Nov 15 2009, 09:10) Да ну, я то как раз за то, чтобы выделять пакеты адресованные слейву в прерывании.
или все-таки сетевые адреса и таймауты у вас обслуживаются в прерывании? Тогда Вы противоречите сами себе. В прерывании. Только не в UARTовом, а в таймерном. Например, 1мс-ном или 1-секундном. Не принципиально. Зависит от требуемой точности определения паузы. Цитата(defunct @ Nov 15 2009, 09:10) Если не распознавать адрес и не обслуживать таймаут в прерывании.
То как Вы определяете, когда прекращать прием? Если в RTU, то как только между двумя (или большим кол-вом, в зависимости от требуемой длительности паузы) 1мс-ыми прерываниями буфер перестал пополняться, то значит нужно считать CRC и при совпадении можно передавать указатель на начало фрейма в буфере на уровень приложения. Если другой формат. то ищутся маркеры начала/конца фрейма в буфере. И адресация тоже определяется нормально. Если адрес был получен не свой, то в таймерном прерывании буфер каждый раз очищается до тех пор, пока не обнаружится начало следующего фрейма. Цитата(defunct @ Nov 15 2009, 09:10) Не вопрос пусть так, но ведь в RX прерывании складываете все подряд, в т.ч. пакеты адресованные другому слейву и ответы других слейвов. Нет. Зачем мне пакеты, адресованные другому слейву, если только у меня не организовано маркерное кольцо для доступа к шине? Цитата(defunct @ Nov 15 2009, 09:10) Это же TX буфер, а мы вроде как про RX... При формате обмена запрос-ответ второй буфер не нужен. Слейв не будет обрабатывать второй и последующий запросы до тех пор, пока не готов ответ на первый или выделенное ему для формирования ответа время не вышло. И еще вопрос-уточнение. А как вы обеспечиваете атомарность при проверке условия Код while (read_index != write_index) ? Ведь если атомарность не будет обеспечена, то последний байт, попавший в буфер в прерывании, может быть пропущен функцией обработки канального уровня.
|
|
|
|
|
|
|
|
Nov 15 2009, 22:27
|
кекс
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326
|
Цитата(rezident @ Nov 15 2009, 20:15) Нет. Зачем мне пакеты, адресованные другому слейву, если только у меня не организовано маркерное кольцо для доступа к шине? Но вы же их принимаете и складываете их данные в буфер... Анализируете свой-чужой - уже в приложении. Цитата При формате обмена запрос-ответ второй буфер не нужен. Слейв не будет обрабатывать второй и последующий запросы до тех пор, пока не готов ответ на первый или выделенное ему для формирования ответа время не вышло. Т.е. отдельный TX буфер не нужен? А куда будем складывать отложенный ответ (тот который формируется, в момент когда уже шлется busy)? После отправки busy, не будем ждать еще одного запроса мастера, чтобы отдать сформированный ответ? Цитата И еще вопрос-уточнение. А как вы обеспечиваете атомарность при проверке условия Код while (read_index != write_index) ? Ведь если атомарность не будет обеспечена, то последний байт, попавший в буфер в прерывании, может быть пропущен функцией обработки канального уровня. Не пропушен (пропущен - это равнозначно потерян), а отложен до следующего прерывания! Да в приведенном варианте есть проблема последнего символа, но она тоже решается, например, запретом прерываний перед очередной проверкой индексов: Код while (read_index != write_index)
{
__enable_interrupt();
rx_cb( fifo_buf[ read_index++ ])
...
__disable_interrupt();
}
... Можно и другим путем. Вот что более интересно, а вам не кажется, что: Цитата если только заранее неизвестно, что сумма всех возможных вложенных прерываний не превысит величины символьного интервала для максимальной скорости передачи (т.е., например, скорость передачи достаточно низкая). относится и к обычному (невложенному обработчику) в точно такой же мере? Приоритет прерывания UART'а в системе как правило далеко не самый высокий, т.о. необходимо чтобы сумма всех возможных и более приоритетных прерываний не превышала символьного интервала для макс скорости передачи, что есть практически одно и тоже с суммой всех возможных вложенных прерываний.
|
|
|
|
|
|
|
|
Nov 15 2009, 22:50
|
Гуру
Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882
|
Цитата(defunct @ Nov 16 2009, 03:27) Но вы же их принимаете и складываете их данные в буфер... Анализируете свой-чужой - уже в приложении. Нет. Анализ уже во втором слое канального уровня, как вы его охарактеризовали, происходит. Та функция которая в 1мс прерывании вызывается и работает с буфером UART. Цитата(defunct @ Nov 16 2009, 03:27) Т.е. отдельный TX буфер не нужен? А куда будем складывать отложенный ответ (тот который формируется, в момент когда уже шлется busy)? Дык в тот же буфер. Или в другой. Маленький, но отдельный. Цитата(defunct @ Nov 16 2009, 03:27) После отправки busy, не будем ждать еще одного запроса мастера, чтобы отдать сформированный ответ? В такой реализации - нет, не будем. Если предусматривать такую возможность, то нужны раздельные буферы, как вы и предлагали. Цитата(defunct @ Nov 16 2009, 03:27) Да в приведенном варианте есть проблема последнего символа, но она тоже решается, например, запретом прерываний перед очередной проверкой индексов: Вот. Все-таки не так все просто, как вы вначале описали.  Цитата(defunct @ Nov 16 2009, 03:27) Вот что более интересно, а вам не кажется, что:
относится и к обычному (невложенному обработчику) в точно такой же мере? К которому именно обработчику? Если к тому, который таймерный, то я там такую же фишку с обходом вызова функции применяю. Почему вам можно, а мне нельзя? И еще. У меня точно также как и у вас канальный уровень абстрагирован от железа. Но в HAL я уложил еще и буфер UART и атомарность доступа к буферу я обеспечиваю там же - в функции работы с буфером UART. При этом решается проблема как с наличием аппаратного FIFO, так и с "отложенными" байтами. P.S. на всякий случай напомню с чего началась дискуссия и ваши возражения. Цитата(rezident @ Nov 8 2009, 07:32) Ради справедливости хотелось бы заметить, что не всегда есть возможность разбирать пакет "на лету" по причине многоуровневой организации связи.
|
|
|
|
|
|
|
|
Nov 15 2009, 23:08
|
кекс
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326
|
Цитата(rezident @ Nov 16 2009, 00:50) Нет. Анализ уже во втором слое канального уровня, как вы его охарактеризовали, происходит. Та функция которая в 1мс прерывании вызывается и работает с буфером UART. Понял. Применительно к modbus-slave я тоже так делал (выделял пакет в обработчике таймера). Но потом отказался от этого пути, потому что один уровень получается размазанным по нескольким обработчикам. И что самое печальное не все протоколы можно эффективно втиснуть в такую модель. Потом получается сложнее портировать код между МК. Цитата Вот. Все-таки не так все просто, как вы вначале описали. Ну а в чем сложность? Сорри допустил ошибку вчера (еще забыл static переменные объявить как volatile), - каюсь  Но код же ж не стал после исправления ошибки, много сложнее? И эффективность ведь не потерялась. Цитата К которому именно обработчику? К обработчику UART'а разумеется. Цитата Если к тому, который таймерный, то я там такую же фишку с обходом вызова функции применяю. Почему вам можно, а мне нельзя? Функция в таймере которая обрабатывает весь пакет - у вас много сложнее моей, обслуживающей строго 1 символ. Поэтому если Вы выделяете целый пакет из кучи принятых байт, вам не то что можно-нельзя, а просто необходимо поступать так и только так, т.к. время выполнения функции будет диким! А вот мне можно и обойтись без вложенности вовсе. Ну а вторая причина - вы про таймер не рассказывали. Я думал у вас обработка делается в аппликейшн. Цитата P.S. на всякий случай напомню с чего началась дискуссия и ваши возражения. Да да, я помню. По прежнему стою на том, что выделять пакеты удобнее всего в обработчике посимвольного приема, т.к. это упрощает разбивку и снижает расход памяти.
|
|
|
|
|
|
|
|
Nov 16 2009, 00:20
|
Гуру
Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882
|
Цитата(defunct @ Nov 16 2009, 04:08) Функция в таймере которая обрабатывает весь пакет - у вас много сложнее моей, обслуживающей строго 1 символ. Поэтому если Вы выделяете целый пакет из кучи принятых байт, вам не то что можно-нельзя, а просто необходимо поступать так и только так, т.к. время выполнения функции будет диким! А вот мне можно и обойтись без вложенности вовсе. Ничуть не сложнее. Обработка зависит от темпа поступления данных. Если темп такой же как частота вызова таймерного прерывания, то также посимвольно получится. Почему нельзя обойтись без вложенности я уже писал. Цитата(defunct @ Nov 16 2009, 04:08) Да да, я помню. По прежнему стою на том, что выделять пакеты удобнее всего в обработчике посимвольного приема, т.к. это упрощает разбивку и снижает расход памяти. С вашего разрешения по второму кругу дискуссию пускать не буду 
|
|
|
|
|
|
|
|
Nov 16 2009, 00:33
|
кекс
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326
|
Цитата(rezident @ Nov 16 2009, 02:20) Ничуть не сложнее. Обработка зависит от темпа поступления данных. Если темп такой же как частота вызова таймерного прерывания, то также посимвольно получится. Почему нельзя обойтись без вложенности я уже писал. темп будет ведь не такой (для 115200 к примеру темп у вас 1:10), потому и нельзя получается. Цитата P.S. на всякий случай напомню с чего началась дискуссия и ваши возражения. Цитата (rezident @ Nov 8 2009, 07:32)
Ради справедливости хотелось бы заметить, что не всегда есть возможность разбирать пакет "на лету" по причине многоуровневой организации связи. Уточно, что "на лету" я предлагаю не разбирать, а выделять пакет из in-stream'a. Разбирать пакет должен следующий уровень работающий в app thread'е.
|
|
|
|
|
|
Сообщений в этой теме
 Phuntik Протокол modbus. Вопросы по интерфейсу Oct 16 2008, 10:46 MrYuran Правильный протокол - на modbus.org
Если нужно мен... Oct 16 2008, 11:24 Phuntik Цитата(MrYuran @ Oct 16 2008, 14:24) Если... Oct 16 2008, 11:27 MrYuran Цитата(Phuntik @ Oct 16 2008, 15:27) Т.е.... Oct 16 2008, 11:33 Andy Great Цитата(MrYuran @ Oct 16 2008, 14:24) Если... Oct 17 2008, 07:56 MrYuran Цитата(Andy Great @ Oct 17 2008, 11:56) P... Oct 17 2008, 08:27 Bovolk Тоже поставили задачу прикрутить Modbus.
В о... Nov 16 2008, 11:01 defunct Цитата(Bovolk @ Nov 16 2008, 13:01) Подчи... Jan 1 2009, 05:05 koyodza Цитата(defunct @ Jan 1 2009, 08:05) По за... Oct 17 2009, 19:30 ucMike Наверное, главной проблемой станет борьба с коллиз... Dec 3 2008, 22:13 ucMike Цитата(ucMike @ Dec 4 2008, 01:13) P.S. С... Dec 4 2008, 11:10 ukpyr modbus plus - multimaster :
http://prodcs.ru/files... Jan 1 2009, 08:40 @Ark ЦитатаВопросы:
1. Можно ли сделать так, чтобы любо... Oct 17 2009, 21:29 rezident koyodza, @Ark, зачем нужно старую тему поднимать? ... Oct 17 2009, 21:36 koyodza Цитата(rezident @ Oct 18 2009, 00:36) koy... Oct 18 2009, 17:51 defunct Цитата(koyodza @ Oct 18 2009, 19:51) Я от... Nov 8 2009, 00:09 koyodza Цитата(defunct @ Nov 8 2009, 02:09) Станд... Nov 9 2009, 17:17 defunct Цитата(koyodza @ Nov 9 2009, 19:17) Или В... Nov 10 2009, 03:21 defunct Цитата(koyodza @ Nov 9 2009, 19:17) Полно... Nov 10 2009, 05:00 Verifi Цитата(defunct @ Nov 10 2009, 08:00) Заче... Nov 10 2009, 07:06 rezident Цитата(defunct @ Nov 10 2009, 10:00) Ниче... Nov 10 2009, 11:41 rezident На досуге я тут кое-что обдумывал и вернулся вот к... Nov 15 2009, 01:53 defunct Цитата(rezident @ Nov 15 2009, 03:53) def... Nov 15 2009, 02:49 demiurg_spb Цитата(defunct @ Nov 8 2009, 03:09) у вас... Nov 28 2009, 20:54 defunct Цитата(demiurg_spb @ Nov 28 2009, 22:54) ... Dec 8 2009, 20:45 demiurg_spb Цитата(defunct @ Dec 8 2009, 23:45) В AMD... Dec 9 2009, 15:43 @Ark Sorry, не посмотрел на дату. Просто тема показал... Oct 17 2009, 21:40 D&M Здравствуйте.У меня такой вопрос: Есть теплосчетчи... Oct 24 2009, 06:12 HARMHARM Цитата(D&M @ Oct 24 2009, 09:12) Можн... Oct 24 2009, 07:18 D&M устройство с виртуальным USB CDC- это как я понял ... Oct 24 2009, 08:13 D&M или как ? жду разных предложений.. Кстати- USB CDC... Oct 24 2009, 20:41 rezident Цитата(D&M @ Oct 25 2009, 01:41) или ... Oct 25 2009, 02:15 D&M Тогда может посоветуете OPC-сервер,который может д... Oct 25 2009, 07:36 D&M Посмотрел,продумал разные варианты и пришел к выво... Oct 26 2009, 15:46 Ronin Цитата(D&M @ Oct 26 2009, 18:46) Посм... Nov 3 2009, 19:15 zltigo Цитата(Ronin @ Nov 3 2009, 22:15) GPRS эт... Nov 4 2009, 19:17 MrYuran Цитата(zltigo @ Nov 4 2009, 22:17) Ну а в... Nov 5 2009, 06:17 zltigo Цитата(MrYuran @ Nov 5 2009, 09:17) По ГП... Nov 5 2009, 15:50 Ronin Цитата(zltigo @ Nov 4 2009, 22:17) Ну а в... Nov 6 2009, 11:21 rezident D&M, я вам в личку написал. Не смотрели? Oct 26 2009, 17:59 D&M ответил Oct 26 2009, 18:23 D&M 1,3 варианты продумал,говорил про модем teleofis-r... Nov 4 2009, 18:49 D&M Нету Modbus-TCP, есть Modbus-RTU в моем рассказе. Nov 5 2009, 15:04 D&M У счетчика Modbus-RTU, а в модеме только CSD.. Nov 6 2009, 12:41 Ronin Цитата(D&M @ Nov 6 2009, 15:41) У сче... Nov 6 2009, 13:10 @Ark Цитата... Я ответил скорее не топикпастеру, а на ф... Nov 8 2009, 01:37 aaarrr Цитата(@Ark @ Nov 8 2009, 04:37) А вот, н... Nov 8 2009, 01:43 @Ark ЦитатаИз всего перечисленного какой-то практически... Nov 8 2009, 01:56 aaarrr Ну, сколько удалось наносекунд сэкономить, а? Серь... Nov 8 2009, 02:01 @Ark Цитата... значит что-то не так с выбором протоколо... Nov 8 2009, 02:21 aaarrr Ну, как и следовало ожидать, конкретные цифры озву... Nov 8 2009, 02:55 rezident Ради справедливости хотелось бы заметить, что не в... Nov 8 2009, 02:32 defunct Цитата(rezident @ Nov 8 2009, 04:32) Но в... Nov 8 2009, 03:27 @Ark ЦитатаНу, как и следовало ожидать, конкретные цифр... Nov 8 2009, 06:30 aaarrr Пример из пальца высосан: вдруг, по команде извне,... Nov 8 2009, 15:11 @Ark Цитата... вдруг, по команде извне, начинаем АЦПиро... Nov 8 2009, 15:30 aaarrr Цитата(@Ark @ Nov 8 2009, 18:30) ... Толь... Nov 8 2009, 15:46 rezident 2 defunct, еще раз обращаю внимание, что я писал п... Nov 8 2009, 16:02 defunct Цитата(rezident @ Nov 8 2009, 18:02) И не... Nov 8 2009, 17:48 rezident Цитата(defunct @ Nov 8 2009, 22:48) Выше ... Nov 8 2009, 18:39 defunct Цитата(rezident @ Nov 8 2009, 20:39) Вот ... Nov 8 2009, 19:51 rezident Цитата(defunct @ Nov 9 2009, 00:51) Не со... Nov 8 2009, 20:08 defunct Цитата(rezident @ Nov 8 2009, 22:08) Вы к... Nov 8 2009, 23:12 rezident Цитата(defunct @ Nov 9 2009, 04:12) Можно... Nov 9 2009, 16:31 @Ark Цитата... скорее вряд ли кому нужно "мгновенн... Nov 8 2009, 16:06 aaarrr Цитата(@Ark @ Nov 8 2009, 19:06) Вашими м... Nov 8 2009, 16:24 @Ark Ну, хорошо, давайте продолжим...
ЦитатаА что будет... Nov 8 2009, 17:15 aaarrr Цитата(@Ark @ Nov 8 2009, 20:15) Ничего с... Nov 8 2009, 17:27 @Ark ЦитатаВыпадет просто, да? А таймаут ответа "с... Nov 8 2009, 17:43 aaarrr Цитата(@Ark @ Nov 8 2009, 20:43) С чего в... Nov 8 2009, 18:25 @Ark ЦитатаКак вы считаете, сколько времени будет сэкон... Nov 8 2009, 19:24 aaarrr Цитата(@Ark @ Nov 8 2009, 22:24) То есть,... Nov 8 2009, 19:42 @Ark ЦитатаЯ предлагаю снабдить слейв минимальным интел... Nov 8 2009, 20:07 aaarrr Цитата(@Ark @ Nov 8 2009, 23:07) Ну, а ка... Nov 8 2009, 20:20 @Ark ЦитатаА реальное время будет спокойно жить в слейв... Nov 8 2009, 20:38 aaarrr Цитата(@Ark @ Nov 8 2009, 23:38) Я опять ... Nov 8 2009, 21:04 @Ark Цитата... что данные будут получены с некоторой ап... Nov 8 2009, 21:24 aaarrr Цитата(@Ark @ Nov 9 2009, 00:24) С какой?... Nov 8 2009, 21:36 @Ark ЦитатаПреимущество блочной передачи вполне очевидн... Nov 8 2009, 21:51 aaarrr Цитата(@Ark @ Nov 9 2009, 00:51) Здесь мы... Nov 8 2009, 22:17 @Ark ЦитатаЦитата(aaarrr @ Nov 9 2009, 00:17)
Да, я вс... Nov 9 2009, 11:09 forever failure Прально, зачем ждать на светофоре зелёного, если н... Nov 10 2009, 07:34
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0
|
|
|
