Приветствую всех! Медленно и нежно думаю мысль о мультимастерной сети, физически реализованной на стандарте RS-485. Как в такой сети решается вопрос, когда два устройства одновременно хотят что то начать передавать? Один драйвер начинает передавать в линию 1, второй - 0... И что при этом происходит? Кто сильнее, тот и мастер? Драйвер не сгорит? Как управляющий контроллер поймет, что не он один тут мастер?
Рекомендую не тратить время понапрасну, а использовать CAN! Иначе придется на софтовом уровне то же самое делать - и зачем?
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Для начала разберись с терминами "аппаратный интерфейс" и "протокол обмена". Судя по вопросу, понимания у ТС в этом деле нет. Eddy_Em прав. Хотя, для справки, первые реализации CAN использовали на аппаратном уровне именно EIA-485. Встречал реализации безмастерных сетей на 485-ом, но сейчас не вижу в этом смысла из-за наличия CAN.
roman.com, не ровняй других по себе.... И если бредовые мысли посещают - закусывать надо (ц) Иван Васильевич...
Eddy_Em, сейчас я использую однопроводную шину с распределенной подтяжкой к питанию и прижатие её к земле. И различное время прижатия для стартового, единичого и нулевого битов. Мне хватает. И идея решения коллизий - как у КАН.
Я не задавал вопроса, какую шину использовать. Но тем не менее, кто то мне парит свою идеальную схему ЛАН на АВР, вы предлагаете КАН...
Вопрос был - не поплохеет ли передатчикам RS485, если оба одновременно начнут каждый в свою дудку дудеть? И под-вопрос - как такое могут отследить управляющие передатчиками контроллеры? (Отследить не после передачи, когда КС не совпала и команда не дошла, а в процессе, что бы передатчики не насиловать.)
tonyk, у ТС-а понимание есть. Вопрос именно про физическую шину RS485
Ну говорят же тебе: самый простой способ избежать коллизий - использовать CAN! Фактически CAN — и есть некий более высокоуровневый протокол поверх RS-485 (но можно и поверх ethernet)! Ethernet — очень "дорогая" штука, поэтому для МК не катит. Зато полным-полно недорогих МК с аппаратным CAN. Я вот до подорожания STM32F072 собирал переходник CAN-USB с себестоисостью триста рублей! И оно работает вполне даже на мегабодах, не мешая всему остальному. Софтовым протоколом ты таких скоростей добьешься лишь на дорогих МК. Ну и зачем?
Ну, или набирать Orange Pi Zero (правда, они подорожали в 2 раза, и уже не 600-750 рублей стоят, а полтора куска и выше!). И на этих полноценных компах уже реализовать связь. Я их использую для всяких фиговин вроде ethernet-розеток и прочих железяк, где нужен доступ через сеть + веб-морда. На дешевых МК такого не сделать, самый дешевый вариант выходит.
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
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 - просветите ищущего знаний?
ТС, мало того, что ты путаешь интерфейс с протоколом, так ещё не различаешь коллизии и арбитраж. Тяжёлый случай. Или из тебя ещё новогодний антифриз не выветрился?
tonyk, а ты такой умный, готов только критиковать? Просвети человека... Я говорю про физическую реализацию шины на уровне физических сигналов. с протоколами я как то разберусь... Иди звиздеть - не мешки ворочать? Сказануть готов, а рассказать - нет?
GoldenAndy, ну почитай ты о нижнем уровне CAN. И подумай: нужно ли тебе мучиться, реализуя это все софтово, когда в недорогих МК оно есть аппаратно?
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Я давно знаю про нижний уровень CAN - он хороший, красивый и правильный, когда он именно CAN в виде диф. пары, как в авто, либо любого другого несимметричного (доминанта/рециссив) формата физической шины. У меня к CAN претензий нет. Ни к формату шины, ни к интерфейсу (шинному формирователю, драйверу), ни к протоколу обмена.
У меня вопрос был исключительно к нижнему уровню 485й шины. Насколько ей бывает плохо при коллизии и как эту коллизию ловить. На уровне интерфейса. О протоколах обмена по обеим шинам сейчас речь не идёт. Но такое ощущение, что кроме меня, никому это не интересно. Один рекламирует свой суперезернет на авр, вы кан предлагаете, третий только умничает (наверное, антифриз так действует?) Вопрос был чисто теоретический. Но по факту - интернет говорит, что в случае 485 либо смириться с коллизиями, либо принимать меры на уровне протоколов обмена (всякие интервальные методы, маркеры, обмен по кольцу и прочее).
К вам конкретно есть еще один вопрос - вы работали с протоколом CAN поверх RS485? (Вы писали, что это один из вариантов реализации, см. несколькими сообщениями выше).
Заголовок сообщения: Re: RS-485 - коллизии на физическом уровне
Добавлено: Вс янв 02, 2022 23:00:13
Модератор
Карма: 90
Рейтинг сообщений: 1443
Зарегистрирован: Чт мар 18, 2010 23:09:57 Сообщений: 4610 Откуда: Планета Земля
Рейтинг сообщения:3 Медали: 1
GoldenAndy, Неужели проще, тут на форуме, напечатать кучу буковок, вместо того, чтобы открыть доку на любой драйвер RS-485 и посмотреть, как устроены выходные каскады ? Вроде не зелёный во всём этом, а вопросы задаёшь детские...
PS: А софтово разруливать арбитраж просто запаришься. Как уже выше сказали, для этого есть CAN. Там весь арбитраж реализован на аппаратном уровне.
GoldenAndy, весь стандартный CAN (в т.ч. автомобильный) и использует в качестве нижнего уровня дифпару от 485! Если рассматривать тупой UART поверх 485, то для детектирования коллизий придется передавать по одному байту, каждый раз слушая линию и проверяя: то же самое получили, что отправили, или нет. А остальные мастера в шине слушают с таймаутом. Как только после последнего нуля прошел таймаут, можно отправлять данные. При возникновении коллизии основная проблема - выдумать, что делать со слушателем. Понятно, что коллизии чаще всего будут возникать в нулевом байте (т.к. иначе другой мастер будет ждать окончания чужой передачи). Придумать, кого "заткнуть" можно как в CAN: у кого первым будет бит 1 при 0 у другого. Однако, здесь уже байт отослан (в отличие от CAN), т.е. слушателю придется отправить некий MAGICK, говорящий, что данные повреждены и байт отправляется еще раз. При большом количестве мастеров на шине такое может привести к очень "задумчивому" поведению. Либо поступать как абдуринщик, генерируя биты ногодрыгом и проверяя каждый раз состояние линии: как только вместо моей единицы кто-то отправил нуль, я затыкаюсь и смиренно жду. Зато такой метод позволит детектировать коллизии уже чуть ли не на уровне стартового бита (вряд ли два мастера будут передавать данные настолько одновременно, что у них "ноздря в ноздрю" биты будут идти).
Еще лучший подход - совместить ногодрыг и нормальную отправку. Тогда можно сначала отправить ногодрыгом пару-тройку стартовых битов. Для надежности их длительность, как и длительность пауз между ними, должна быть рандомной. В этом случае повысится вероятность того, что даже если кто-то начнет передачу одновременно, то в течение этих 2-3 стартовых бит лишний мастер отвалится, увидев на линии 0, когда там должна быть 1. Ну, а дальше просто посредством DMA передаем всю нужную последовательность данных. Все остальные мастера будут ждать таймаут шины и не вмешаются в передачу. P.S. При этом все равно придется слушать линию и сравнивать принятое с переданным: мало ли какая зараза внезапно "проснется" и надумает передавать, поломав нашу передачу своими стартовыми битами или данными?
_________________ Linux rules! Windows must die. Здравомыслящий человек добровольно будет пользоваться мастдаем лишь в двух случаях: под дулом автомата или под влиянием анального зонда. Я на гитхабе, в ЖЖ
Eddy_Em, Ага, я понял, что вы имели ввиду под "CAN — и есть некий более высокоуровневый протокол поверх RS-485". Что физическая витуха взята от 485.
Аlex, Eddy_Em, Ну вроде не зеленый... Просто не сталкивался с 485 раньше... А тут - "дело было вечером, делать было нечего".... Возникла мысль - а не почитать ли интернет про 485 шину. Почитал. Возник вопрос. Решил спросить на форуме, надеясь, что есть форумчане, которые реально работали с данной шиной и могут что то подсказать по-быстрому. Параллельно читал в сети методы решения... Но увы, кроме ведра антифриза и холодильника пива, дельное я услышал только от Эдди.
Засим, что бы не отвлекать страждущих от их любимого времяпровождения, я говорю спасибо всем, кто попытался помочь, и удаляюсь в закат. Тему прошу считать решенной и закрытой. Всем бобра!
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения