Что бы еще такого сделать?... Предлагайте! Обсудим все!!!
Ответить

RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 14:29:55

Приветствую всех!
Медленно и нежно думаю мысль о мультимастерной сети, физически реализованной на стандарте RS-485.
Как в такой сети решается вопрос, когда два устройства одновременно хотят что то начать передавать?
Один драйвер начинает передавать в линию 1, второй - 0...
И что при этом происходит? Кто сильнее, тот и мастер?
Драйвер не сгорит?
Как управляющий контроллер поймет, что не он один тут мастер?

Re: RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 15:44:37

Рекомендую не тратить время понапрасну, а использовать CAN! Иначе придется на софтовом уровне то же самое делать - и зачем?

Re: RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 16:23:56

GoldenAndy шо ? шампанское всё выпили ? )) v водка кончилась ? )) полезли бредовые мысли в голову... ? ))

RS... CAN...
И это в то время когда всё прогрессивное человечество давно отказалось от этих устаревших протоколов... :facepalm:

А я тут сделал аналог LAN на AVR ))
PING_100кбит.jpg
(125.68 KiB) Скачиваний: 119

Вот такая бредовая мысль посетила меня)) :idea: :)))

А зато нет никаких коллизий...
:tea:

Блин... у нас же ещё пиво осталось в холодильнике...
))).jpg
(33.16 KiB) Скачиваний: 83

Как же я мог про него забыть... :)))

Всех в Новым Годом !!!
:beer:

Re: RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 16:28:56

Для начала разберись с терминами "аппаратный интерфейс" и "протокол обмена". Судя по вопросу, понимания у ТС в этом деле нет.
Eddy_Em прав. Хотя, для справки, первые реализации CAN использовали на аппаратном уровне именно EIA-485.
Встречал реализации безмастерных сетей на 485-ом, но сейчас не вижу в этом смысла из-за наличия CAN.

Re: RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 16:40:20

roman.com, не ровняй других по себе.... И если бредовые мысли посещают - закусывать надо (ц) Иван Васильевич...

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

Я не задавал вопроса, какую шину использовать. Но тем не менее, кто то мне парит свою идеальную схему ЛАН на АВР, вы предлагаете КАН...

Вопрос был - не поплохеет ли передатчикам RS485, если оба одновременно начнут каждый в свою дудку дудеть?
И под-вопрос - как такое могут отследить управляющие передатчиками контроллеры? (Отследить не после передачи, когда КС не совпала и команда не дошла, а в процессе, что бы передатчики не насиловать.)

tonyk, у ТС-а понимание есть. Вопрос именно про физическую шину RS485

Re: RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 16:48:27

....Вопрос именно про физическую шину RS485


да никак коллизий не избежать.
аналог - см. ethernet
ну и кол-во таких мастеров и длина кабелюки будет влиять на один сегмент.

(круглый)

Re: RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 16:57:38

kolobok0, ну то понятно, что не избежать.
Вопрос, как максимально быстро отследить и не поплохеет ли передатчикам?

Re: RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 17:06:33

Ясно... Полное отсутствие чувства юмора...
Ошибся сайтом ))
Извините))
:)))

Re: RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 17:09:08

В частном случае коллизий можно избежать, наверное, вообще. Или рассматриваете универсальный вариант, на все случаи?

Re: RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 17:19:42

Ну говорят же тебе: самый простой способ избежать коллизий - использовать CAN! Фактически CAN — и есть некий более высокоуровневый протокол поверх RS-485 (но можно и поверх ethernet)!
Ethernet — очень "дорогая" штука, поэтому для МК не катит. Зато полным-полно недорогих МК с аппаратным CAN. Я вот до подорожания STM32F072 собирал переходник CAN-USB с себестоисостью триста рублей! И оно работает вполне даже на мегабодах, не мешая всему остальному. Софтовым протоколом ты таких скоростей добьешься лишь на дорогих МК. Ну и зачем?

Ну, или набирать Orange Pi Zero (правда, они подорожали в 2 раза, и уже не 600-750 рублей стоят, а полтора куска и выше!). И на этих полноценных компах уже реализовать связь. Я их использую для всяких фиговин вроде ethernet-розеток и прочих железяк, где нужен доступ через сеть + веб-морда. На дешевых МК такого не сделать, самый дешевый вариант выходит.

Re: RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 18:19:34

Серьёзными щщами оперирует автор. Ответивших на место ставит. А даташит на драйвер шины почитать не осилил. Кто кого перетянет и сгорит-не сгорит.

Re: RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 18:42:22

Eddy_Em, Отсутствие коллизий в CAN обусловлено идеей, что сигналы в шине несимметричны - один из битов может быть задавлен другим. Т.е. передача, условно, говоря, нуля имеет преимущество над передачей 1. И соответственно, тот, у кого в идентификаторе больше нулей - при передаче задавит другого.
Я выше уже написал - у меня домашняя сетка построена по тому же принципу, но с одним проводом. Он подтянут к +5 вольтам и все устройства давят его к земле транзисторами. Т.е. такое себе распределенное логическое "И". И оно работает в пределах квартиры идеально и менять это я не собираюсь. У меня там скорости не высокие, порядка 2 килобит/с.

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

kollaider, да, вы правы, я еще не читал ДШ на передатчики, ибо не было задачи работать с 485 шиной... Я даже навскидку не знаю, какой драйвер лучше. Если подскажете - скажу спасибо.

Но ведь это не отменяет принципа физической работы шины - когда при передаче лог.1 драйвер тянет линию А к нулю, линию Б - к питанию, при передаче лог.0 - наоборот, А к питанию, Б к нулю.

И при одновременной передаче 1 и 0 будет перетягивание каната.

Добавлено after 3 minutes 46 seconds:
Eddy_Em писал(а):Фактически CAN — и есть некий более высокоуровневый протокол поверх RS-485

Вот кстати, да. Как CAN решает коллизии при работе по 485 шине? Вы, как спец по CAN - просветите ищущего знаний?

Re: RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 20:14:44

ТС, мало того, что ты путаешь интерфейс с протоколом, так ещё не различаешь коллизии и арбитраж. Тяжёлый случай. Или из тебя ещё новогодний антифриз не выветрился? :)

Re: RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 21:49:21

tonyk, а ты такой умный, готов только критиковать?
Просвети человека... Я говорю про физическую реализацию шины на уровне физических сигналов. с протоколами я как то разберусь...
Иди звиздеть - не мешки ворочать? Сказануть готов, а рассказать - нет?

Re: RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 21:52:05

GoldenAndy, ну почитай ты о нижнем уровне CAN. И подумай: нужно ли тебе мучиться, реализуя это все софтово, когда в недорогих МК оно есть аппаратно?

Re: RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 22:45:09

Eddy_Em, стоп.
Неужели я так непонятно пишу?

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

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

К вам конкретно есть еще один вопрос - вы работали с протоколом CAN поверх RS485? (Вы писали, что это один из вариантов реализации, см. несколькими сообщениями выше).

Re: RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 23:00:13

GoldenAndy, Неужели проще, тут на форуме, напечатать кучу буковок, вместо того, чтобы открыть доку на любой драйвер RS-485 и посмотреть, как устроены выходные каскады ?
Вроде не зелёный во всём этом, а вопросы задаёшь детские...

PS: А софтово разруливать арбитраж просто запаришься. Как уже выше сказали, для этого есть CAN. Там весь арбитраж реализован на аппаратном уровне.

Re: RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 23:00:23

GoldenAndy, весь стандартный CAN (в т.ч. автомобильный) и использует в качестве нижнего уровня дифпару от 485!
Если рассматривать тупой UART поверх 485, то для детектирования коллизий придется передавать по одному байту, каждый раз слушая линию и проверяя: то же самое получили, что отправили, или нет. А остальные мастера в шине слушают с таймаутом. Как только после последнего нуля прошел таймаут, можно отправлять данные. При возникновении коллизии основная проблема - выдумать, что делать со слушателем. Понятно, что коллизии чаще всего будут возникать в нулевом байте (т.к. иначе другой мастер будет ждать окончания чужой передачи). Придумать, кого "заткнуть" можно как в CAN: у кого первым будет бит 1 при 0 у другого. Однако, здесь уже байт отослан (в отличие от CAN), т.е. слушателю придется отправить некий MAGICK, говорящий, что данные повреждены и байт отправляется еще раз. При большом количестве мастеров на шине такое может привести к очень "задумчивому" поведению.
Либо поступать как абдуринщик, генерируя биты ногодрыгом и проверяя каждый раз состояние линии: как только вместо моей единицы кто-то отправил нуль, я затыкаюсь и смиренно жду. Зато такой метод позволит детектировать коллизии уже чуть ли не на уровне стартового бита (вряд ли два мастера будут передавать данные настолько одновременно, что у них "ноздря в ноздрю" биты будут идти).

Еще лучший подход - совместить ногодрыг и нормальную отправку. Тогда можно сначала отправить ногодрыгом пару-тройку стартовых битов. Для надежности их длительность, как и длительность пауз между ними, должна быть рандомной. В этом случае повысится вероятность того, что даже если кто-то начнет передачу одновременно, то в течение этих 2-3 стартовых бит лишний мастер отвалится, увидев на линии 0, когда там должна быть 1. Ну, а дальше просто посредством DMA передаем всю нужную последовательность данных. Все остальные мастера будут ждать таймаут шины и не вмешаются в передачу.
P.S. При этом все равно придется слушать линию и сравнивать принятое с переданным: мало ли какая зараза внезапно "проснется" и надумает передавать, поломав нашу передачу своими стартовыми битами или данными?

Re: RS-485 - коллизии на физическом уровне

Вс янв 02, 2022 23:32:33

Eddy_Em, Ага, я понял, что вы имели ввиду под "CAN — и есть некий более высокоуровневый протокол поверх RS-485". Что физическая витуха взята от 485.

Аlex, Eddy_Em, Ну вроде не зеленый... Просто не сталкивался с 485 раньше... А тут - "дело было вечером, делать было нечего".... Возникла мысль - а не почитать ли интернет про 485 шину. Почитал. Возник вопрос. Решил спросить на форуме, надеясь, что есть форумчане, которые реально работали с данной шиной и могут что то подсказать по-быстрому. Параллельно читал в сети методы решения...
Но увы, кроме ведра антифриза и холодильника пива, дельное я услышал только от Эдди.

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