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.

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

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

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