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 не так уж и страшна. А для протокольной совместимости слейв тоже сделает задержку перед передачей после включения трансмиттера. Главное чтобы мастер успел отключиться к тому времени.