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

Не понял: откуда берётся лишний байт?
Прерывание есть по опустошению передающего буфера, от него можно отсчитать таймером длину байта и переключать. Вполне нормальное решение.

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

Непонятно. Даже на скорости 115200 длительность битового интервала около 10мкс, (несколько десятков тактов). Задержку можно взять с запасом.

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

TXBUF пустой, срабатывает прерывание, что готов к передаче следующего, а сдвигающий регистр еще молотит и UART еще продолжает передавать (TXEMP еще не выставлен). Поэтому если отсчитать интервал в длину байта с момента опустошения TXBUF, то можно потерять "кусочек" байта. Может в этом затык?
Если не угадал, то приведите свой код, а то не все умеють гадать по звездам.

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

В UxTCTL вродеж есть TXEPT. По крайней мере я его пользовал. Посмотрите мои дровишки - там есть функция USART0_Shift_Reg_Control() я ее когда нужно полю для переключения. Недостаток моей реализации - отсутсвие задержки >=1млс после опустошения сдвигового регистра - забил тогда.

TXEPT тоже не подходит. Он устанавливается одновременно с выдвижением из сдвигового регистра на вывод TXD последнего бита. Нужно после установки TXEPT делать паузу как минимум на один битовый интервал.

Ну, отчего же?..
Я просто предположил, что аффтор путает момент возникновения прерывания передатчика с реальным моментом окончания передачи, отсюда и нестыковки во времени. А TXEPT может помочь в расчете момента, когда можно переключать направление. Прерывание передатчика тоже может помочь, главное не путать их местами.
Другое дело в ту ли сторону мы копаем. Пусть аффтор, уточнит.

Ясно что не понимает. Причем не столько в таймингах, сколько в организации буферов. Как может "отправляться лишний байт", если буфер выделенный для передачи пуст? Откуда он вообще попал в буфер передатчика это "лишний" байт? UART ведь сам по себе ничего не передает. Может в очередной раз нужен пример организации линейных или циклических буферов?

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

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

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

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

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



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

Чтобы реализовать протокольную часть связи, нужно иметь возможность реализации на физическом уровне, не так ли?
Закон Мерфи гласит, что если вероятность неприятного события отлична от нуля, то оно обязательно произойдет, причем в самый неподходящий момент Заложить дополнительную возможность это как соломки себе подстелить. Неоднократно встречались ситуации, когда производитель оборудования был вынужден модифицировать аппартно-программную часть, для реализации возможности подключения его оборудования в уже существующую сеть приборов. Причем доработки были связаны именно с введением дополнительных задержек, реализации поддержки протокола и, например, введения гальванической развязки 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. Далее - аналогично.

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

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