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

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



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



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



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

Конечно, А как же без этого если реализованы поддержки различных протоколов на одном физическом уровне? Кроме того, задержки в любом случае нужно учитывать, т.к. линия связи RS485 может быть удлинена репитерами. А каждый репитер вносит задержку.
В руках дурака и рогатка - самострел
Не передергивайте! Я писал про доработку устройств, которые должны были быть подключены к уже имеющейся сети из различных приборов.
Исходя из вероятности возникновения коллизий, чем меньше время удержания, тем меньше вероятность коллизии. С этой точки зрения нет, не нужно. Но для поддержания протокольной части и увеличения надежности связи - весьма полезно. "Растяжку" линии тоже ведь широко используют для этой же цели (увеличение надежности связи), а ее ведь в стандарте EIA/TIA-475-A нет и в обязательном порядке для функционирования RS485 она не нужна.
Пугать? Да ни в коем разе. Всего лишь обмен опытом. Как говорится Sapenti sat.

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



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



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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Знаком, программировал. Это было нечто по мотивам 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 - частности?

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

Если выражаться математически, то протокол + физический уровень это общее от множества связи, а физический уровень это всего лишь подмножество, входящее в множество
В вашем описании, управлением передатчика физического уровня почему-то занимается непосредственно канальный уровень. В моих реализациях физический уровень сам управляет направлением передачи драйвера, в соответствии с заранее установленными параметрами (паузами и задержками). Эти параметры может задавать пользователь или наладчик оборудования, одновременно со сменой типа протокола связи.

Ну дык сказали же уже. Либо нужно отсчитывать задержку как минимум в один символ от прерывания передатчика (или от установки флага TXIFGx), либо опрашивать TXEPT и отсчитывать от момента установки его задержку не менее одного битового интервала для выбранной скорости передачи. Насчет лишних байт, ИМХО у человека всего лишь некорректная реализация буфера передатчика.

Можно сделать следующий финт ушами:
На время передачи подключить UTXD к URXD (бит LISTEN). После того, как последний передаваемый байт помещается в сдвиговый регистр, бит LISTEN убираем.
А уже в прерывании по приему проверяем, если бит LISTEN выставлен, то это принято эхо - ничего не делаем, если сброшен и направление передачи было на "Передачу", то переключить направление передачи на "Прием".

Ещё пара страниц, и мы бы вплотную к этому подобрались



Шикарно
Теперь я понял, зачем ранее была упомянута опторазвязка - для ещё большего увеличения общности



Я не знаю, как бы я это реализовал, если бы стал делать, вполне возможно так же, как вы. Но с точки зрения OSI отмерять задержки должен канальный уровень, потому я так написал. А на приём тайм-ауты у вас тоже физический уровень ловит?



Отлично. Замечу только, что есть более универсальное решение: не отключать приём у драйвера 485. Далее - аналогично.

Кто-нибудь так делал? Это работает?
А то у меня тоже скоро будет аналогичная проблема (для решения на основе таймера нужно еще иметь свободный таймер, отсюда и интерес к этому "финту ушами").