MSP & RS485 Опции

[AVN]

У MSP нет прерывания по опустошению сдвигового регистра, как у AVR. Каким образом мне поймать момент опустошения сдвигового регистра, чтобы переключить направление передачи? Сделал по таймеру, но в этом случае отправляется лишний байт и как-то не нравится такое решение. Кто может что-то предложить?

[rezident]

Не нужно стремиться включать драйвер как можно быстрее. Если у вас разрабатывается поддержка сетевого устройства, а не "настольный" вариант конвертора, то предвосхищая трудности стыковки в одной сети вашего устройства с устройствами других производителей, следует заложить в реализацию настраиваемые задержки.
1) задержка между переключением драйвера RS485 на передачу и началом передачи
2) задержка после окончания передачи, перед переключением драйвера в режим приема.
Еще раз подчеркиваю, что это должны быть настраиваемые пользователем задержки.

[AHTOXA]

2) задержка после окончания передачи, перед переключением драйвера в режим приема.
Еще раз подчеркиваю, что это должны быть настраиваемые пользователем задержки.

А это зачем? ИМХО, что чем быстрее устройство отпустит шину после передачи, тем лучше. Какие могут быть причины задерживать момент отключения?

[MrYuran]

А это зачем? ИМХО, что чем быстрее устройство отпустит шину после передачи, тем лучше. Какие могут быть причины задерживать момент отключения?

Переходные процессы в линии

[AHTOXA]

Переходные процессы в линии

Для их подавления служит задержка перед началом передачи. А смысла в задержке по окончании передачи я не вижу никакого.

[rezident]

Для их подавления служит задержка перед началом передачи. А смысла в задержке по окончании передачи я не вижу никакого.

Для RTU-ных протоколов связи, в которых конец пакета отслеживается по паузе тишины, смысл в формировании этой паузы удержанием драйвера в режиме передачи имеется. К тому же я написал - настраиваемая задержка. Параметр, имеющий величину - 0, означает отсутствие этой задержки

[AHTOXA]

Для RTU-ных протоколов связи, в которых конец пакета отслеживается по паузе тишины, смысл в формировании этой паузы удержанием драйвера в режиме передачи имеется.

Во-первых, эта задержка нужна для протокола, а не для собственно передачи по RS-485. А во-вторых, если эта задержка задаётся протоколом, то зачем её дополнительно настраивать?

К тому же я написал - настраиваемая задержка. Параметр, имеющий величину - 0, означает отсутствие этой задержки

По закону тов. Мерфи, если есть настройка, то обязательно найдётся пользователь, который настроит неправильно

[rezident]

Во-первых, эта задержка нужна для протокола, а не для собственно передачи по RS-485. А во-вторых, если эта задержка задаётся протоколом, то зачем её дополнительно настраивать?

Чтобы реализовать протокольную часть связи, нужно иметь возможность реализации на физическом уровне, не так ли?

По закону тов. Мерфи, если есть настройка, то обязательно найдётся пользователь, который настроит неправильно

Закон Мерфи гласит, что если вероятность неприятного события отлична от нуля, то оно обязательно произойдет, причем в самый неподходящий момент Заложить дополнительную возможность это как соломки себе подстелить. Неоднократно встречались ситуации, когда производитель оборудования был вынужден модифицировать аппартно-программную часть, для реализации возможности подключения его оборудования в уже существующую сеть приборов. Причем доработки были связаны именно с введением дополнительных задержек, реализации поддержки протокола и, например, введения гальванической развязки RS485. Но если вам нравится ходить по чужим и уже известным граблям, то ради Бога! Шагайте!

[AHTOXA]

Чтобы реализовать протокольную часть связи, нужно иметь возможность реализации на физическом уровне, не так ли?

Ерунда. Протокольные задержки реализуются протоколом, задержки физического уровня - на физическом. Если заложить "настраиваемые задержки" на физическом уровне, то протоколу придётся учитывать ещё и их.

Закон Мерфи гласит, что если вероятность неприятного события отлична от нуля, то оно обязательно произойдет, причем в самый неподходящий момент

Вот именно. Потому каждая лишняя настройка потенциально ведёт к неприятному событию.

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

Предлагаете и гальваноразвязку делать в качестве настраиваемого параметра? Ещё раз: это — протокольные дела. Подстройка протокола - это нормально. Но вопрос стоял о работе физического уровня. Я так понял, что для него удержание линии по окончании передачи таки не нужно.

Но если вам нравится ходить по чужим и уже известным граблям, то ради Бога! Шагайте!

Когда кончаются аргументы, начинают пугать граблями и рассказывать о своём богатом опыте, ага. А я-то надеялся, что Вы что-то умное мне поведаете...

[rezident]

Ерунда. Протокольные задержки реализуются протоколом, задержки физического уровня - на физическом. Если заложить "настраиваемые задержки" на физическом уровне, то протоколу придётся учитывать ещё и их.

Конечно, А как же без этого если реализованы поддержки различных протоколов на одном физическом уровне? Кроме того, задержки в любом случае нужно учитывать, т.к. линия связи RS485 может быть удлинена репитерами. А каждый репитер вносит задержку.

Вот именно. Потому каждая лишняя настройка потенциально ведёт к неприятному событию.

В руках дурака и рогатка - самострел

Предлагаете и гальваноразвязку делать в качестве настраиваемого параметра?

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

Ещё раз: это — протокольные дела. Подстройка протокола - это нормально. Но вопрос стоял о работе физического уровня. Я так понял, что для него удержание линии по окончании передачи таки не нужно.

Исходя из вероятности возникновения коллизий, чем меньше время удержания, тем меньше вероятность коллизии. С этой точки зрения нет, не нужно. Но для поддержания протокольной части и увеличения надежности связи - весьма полезно. "Растяжку" линии тоже ведь широко используют для этой же цели (увеличение надежности связи), а ее ведь в стандарте EIA/TIA-475-A нет и в обязательном порядке для функционирования RS485 она не нужна.

Когда кончаются аргументы, начинают пугать граблями и рассказывать о своём богатом опыте, ага.

Пугать? Да ни в коем разе. Всего лишь обмен опытом. Как говорится Sapenti sat.

[AHTOXA]

Конечно, А как же без этого если реализованы поддержки различных протоколов на одном физическом уровне? Кроме того, задержки в любом случае нужно учитывать, т.к. линия связи RS485 может быть удлинена репитерами. А каждый репитер вносит задержку.

Тут скорее всё же нужно подстраивать задержку перед началом передачи, нежели задержку по окончании приёма.

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

Не обижайтесь, я пошутил

Исходя из вероятности возникновения коллизий, чем меньше время удержания, тем меньше вероятность коллизии. С этой точки зрения нет, не нужно.

Здесь полный консенсус

Но для поддержания протокольной части и увеличения надежности связи - весьма полезно. "Растяжку" линии тоже ведь широко используют для этой же цели (увеличение надежности связи), а ее ведь в стандарте EIA/TIA-475-A нет и в обязательном порядке для функционирования RS485 она не нужна.

А вот здесь я всё же пока не понимаю. Растяжка - понятно. Она держит незанятую линию в определённом состоянии. А какая польза от удержания линии занятой после окончания передачи? Или Вы имеете в виду, что, зная задержку ответа устройства и удерживая линию занятой после запроса почти всё это время, мы уменьшаем таким образом время незанятого (восприимчивого к помехам) состояния линии?

[rezident]

Тут скорее всё же нужно подстраивать задержку перед началом передачи, нежели задержку по окончании приёма.

Дык выше она у меня под №1 шла. А против которой вы возражаете - №2.

А вот здесь я всё же пока не понимаю. Растяжка - понятно. Она держит незанятую линию в определённом состоянии. А какая польза от удержания линии занятой после окончания передачи? Или Вы имеете в виду, что, зная задержку ответа устройства и удерживая линию занятой после запроса почти всё это время, мы уменьшаем таким образом время незанятого (восприимчивого к помехам) состояния линии?

А вы рассмотрите линию как со стороны передатчика, так и со стороны приемника. Начальные условия. Растяжки нет, есть только терминальные резисторы.
- линия свободна и нагружена только на терминальные резисторы. При наличии помех приемники возможно ловят их как ошибочные символы.
- включился драйвер RS485 мастера. Произошел перезаряд линии. Приемники возможно опять словили ошибочный символ. Поэтому здесь для реализации RTUного протокола нужно сделать паузу перед началом передачи, иначе пакет уйдет в никуда. Слейв обязан начать прием только после временнОй паузы определенной величины.
- сделали паузу в течение которой линию связи в определенном состоянии удерживает драйвер RS485 мастера.
- идет передача пакета.
- передача пакета завершена. Если тут же отпустить линию (выключить передатчик мастера), то приемники слейвов имеют шанс словить ошибочный символ. И весь пакет уйдет в помойку. Но мастер у нас не дурак и держит линию (своим включенным на передачу драйвером) в течение времени, определяемым требованиями RTU-ной протокольной "паузы".
- пауза закончилась. Мастер отключил трансмиттер. Все свободны.
- ждем ответа от слейва, отбиваясь от помех в линии.

Вот примерно такой расклад.

Кстати, исходя из этой же концепции слейв тоже должен делать паузу после приема пакета запроса перед отправкой ответа. Для уменьшения вероятности коллизии из-за разбежки формирования временнЫх пауз у него и у мастера. Хотя, эта пауза и необязательна. Коллизия в линии RS485 не так уж и страшна. А для протокольной совместимости слейв тоже сделает задержку перед передачей после включения трансмиттера. Главное чтобы мастер успел отключиться к тому времени.

[AHTOXA]

Дык выше она у меня под №1 шла. А против которой вы возражаете - №2.

А, ту, что под номером один я целиком и полностью одобряю

- передача пакета завершена. Если тут же отпустить линию (выключить передатчик мастера), то приемники слейвов имеют шанс словить ошибочный символ. И весь пакет уйдет в помойку.

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

Остальное-то всё понятно, с остальным я собственно и не спорил

[rezident]

Это почему? Пакет-то уже принят, целиком, корректный и без ошибок. Слейв должен ответить...

Дык а слейв еще не не в курсе о том, что весь пакет уже принят. Он должен поймать "паузу тишины", которая и будет означать конец пакета для режима RTU.

Или в MODBUS (вы же про него, да?) положено выкидывать принятый валидный пакет, если после него пришёл лишний символ?

Естественно выкинуть! Откуда слейв знает какой символ лишний? Он обязан принимать все символы. А если какой-то принят с ошибкой, то аннулировать весь пакет. Точно также как если бы CRC правильно принятого пакета не сошлась. Достоверность данных это самое главное в любой системе связи.

Вы про семиуровневую модель взаимодействием открытых систем (OSI) что-нибудь слышали?

[AHTOXA]

Дык а слейв еще не не в курсе о том, что весь пакет уже принят. Он должен поймать "паузу тишины", которая и будет означать конец пакета для режима RTU.

Понятно. Но это особенность именно MODBUS-RTU, во многих других протоколах это не нужно. Взять хоть MODBUS-ASCII или Wake. Там начало и конец пакета определяются иначе.

Естественно выкинуть! Откуда слейв знает какой символ лишний? Он обязан принимать все символы. А если какой-то принят с ошибкой, то аннулировать весь пакет. Точно также как если бы CRC правильно принятого пакета не сошлась. Достоверность данных это самое главное в любой системе связи.

На самом деле это совсем не естественно За достоверность данных отвечает CRC. Другое дело, что у RTU нет поля длины пакета, потому нет иного способа определить его конец. Но RTU - это далеко не единственный протокол, потому на его примере не стоит делать обобщений.

Вы про семиуровневую модель взаимодействием открытых систем (OSI) что-нибудь слышали?

А с чего бы я так упорно делил физический и протокольный уровни?

Мне кажется, причина нашего с вами спора в том, что я говорю про 485 в общем, а вы - в приложении к RTU. Но теперь, вроде бы, всё прояснилось?

[rezident]

Понятно. Но это особенность именно MODBUS-RTU, во многих других протоколах это не нужно. Взять хоть MODBUS-ASCII или Wake. Там начало и конец пакета определяются иначе.

Не только Modbus, есть и другие протоколы, использующие формат RTU.

На самом деле это совсем не естественно За достоверность данных отвечает CRC.

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

Другое дело, что у RTU нет поля длины пакета, потому нет иного способа определить его конец. Но RTU - это далеко не единственный протокол, потому на его примере не стоит делать обобщений.

Почему это не стоит? Я же везде указываю что это для случаев, когда прибор поддерживает несколько протоколов и в т.ч. какой-то RTU-ный. Если протоколов RTU нет в поддержке прибора, тогда да, наверное можно и не задумываться об этом. Хотя, например, (еще один пример ) в (радио)модемах, работающих в "прозрачном" режиме настраиваемые задержки тоже акутальны. Ведь модем, работающий в таком режиме, вообще ничего о протоколе не "знает". Как пример радиомодема , имеющего подобные возможности по настройке параметров (проводной) связи, могу привести "Спектр-433". Разработчики этого радиомодема весьма умные и грамотные специалисты потому, что осознали проблему, задумались и реализовали соответствующие настройки связи. У нас такие радиомодемы кое-где используются. Установлены обычно вблизи антенны, которая может находится довольно далеко (и в недоступном для обслуживания месте) от ближайшей точки/узла/сетевого устройства. На расстоянии до сотни метров. Поэтому используется интерфейс связи именно RS485, а не RS232. Питание радомодему в таком случае подается по свободным проводам того же кабеля связи. Уверяю вас, что возможность настройки задержек и пауз в такой конфигурации связи отнюдь не лишняя.

А с чего бы я так упорно делил физический и протокольный уровни?

Т.е. знакомы? И программировали наверняка такие устройства? Тогда неясно, откуда недопонимаение? RS485 работает совмсетно с UART МК. UART работает по прерываниям. На прерываниях UART "сидит" линейный (типа FIFO) или кольцевой буфер, который знать не знает о протоколе. Его задача получить байт, при возможности определить его валидность и поместить в буфер. Разбор содержимого буфера на более высоком уровне осуществляется. Можно конечно кое-что совмещать, а некоторые уровни OSI вообще исключать. Но OSI ведь общую (типовую) структуру связи описывает. Частная реализация может как-то отличаться от типовой.

Мне кажется, причина нашего с вами спора в том, что я говорю про 485 в общем, а вы - в приложении к RTU.

Я говорю, исходя из общего применения, а вы упираетесь в частности. Частное это часть общего, не так ли?

Но теперь, вроде бы, всё прояснилось?

Надеюсь

[AHTOXA]

Не только Modbus, есть и другие протоколы, использующие формат RTU.

Вот именно что протоколы. И это - их задержки. А речь изначально шла про обычный 485й.

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

Да ладно Всё же фрейм отвечает в первую очередь за определение границ пакета. И нужен именно для этого. Остальное вторично, всё равно CRC выявит ошибку.

Почему это не стоит? Я же везде указываю что это для случаев, когда прибор поддерживает несколько протоколов и в т.ч. какой-то RTU-ный. Если протоколов RTU нет в поддержке прибора, тогда да, наверное можно и не задумываться об этом.

Ну про RTU в исходном посте (после которого я встрял) точно не было

..."Спектр-433"...

Мы их тоже используем ИМХО, задержка там связана с радиоканалом, чтобы заново не раскочегаривать передатчик на каждый символ.

Т.е. знакомы? И программировали наверняка такие устройства?

Знаком, программировал. Это было нечто по мотивам X.25, не RTU. И не на микроконтроллерах И OSI там было поOSIстей)) А на микроконтроллерах использовал голый 485, либо Wake.

Тогда неясно, откуда недопонимание?

Я-то как раз уверен, что понимаю всё предельно ясно
Передача:

• Канальный уровень(MODBUS Serial Line Protocol): получение пакета с уровня приложения, занятие линии, выдержка интервала 3.5 байта*, отправка пакета на физический уровень, ожидание флага окончания передачи от физического уровня, выдержка интервала 3.5 байта (или поменьше), отпускание линии.
• Физический уровень (EIA/TIA-485): передача байтов из буфера, флаг немедленно по окончании передачи последнего байта.

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

Приём:

• Физический уровень принимает байты и отправляет их на канальный.
• Канальный уровень их проверяет, складирует в пакет и засекает тайм-ауты.

Как видите, всё замечательно делится по уровням OSI. И я продолжаю утверждать, что на физическом уровне задержка по окончании передачи - не нужна. Ибо при наличии сверху протокола типа RTU будет мешать ему выдерживать свои, протокольные паузы, а при отсутствии оного - увеличивать вероятность коллизий при слишком быстром начале ответной передачи.

Я говорю, исходя из общего применения, а вы упираетесь в частности. Частное это часть общего, не так ли?

То есть, по-вашему, RTU over RS-485 - это общее, а RS-485 - частности?

[shasik]

2 AHTOXA & rezident
Помните как все начиналось:

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