Нужен совет. Хочу создать сеть из нескольких AVR по USART. Кто нибудь сделал такое. На рисунке нарисовал примерную схему. Все будет управляться от компа, скажем хочу включить какую то ножку на AVR2, как должен выставлять адреса. С одним AVR-ом практика есть, а вот с несколькими... увы не могу разобраться. Заранее спасибо.
Нажмите для просмотра прикрепленного файла

RS-485

Это будет суперкомпьютер на AVR!

Вообще-то, если задача сводится ТОЛЬКО к передаче управляющей команды от PC к AVRкам, а обратную информацию от AVRок в PC принимать не планируется, то допустимо все входы RX UART AVRок присоединить к одному и тому выходу TX UART PC, предварительно сделав этот сигнал более мощным. Тогда все они окажутся как бы повешенными на одну шину, с которой будут читать команды от PC (понятно, что линии передачи TX AVRок соединять между собой нельзя). Остальное дело программирования - сделать так, чтобы каждая AVRка знала свой номер и выполняла тольку ту команду, которая адресована ней, а на чужие внимания не обращала.

Можно пойти и по альтернативному пути, хотя он более юмористический - соединить AVRка поездом, как вагончики. При этом TX UART PC поступает на RX UART 1-ой AVRки, ее TX соединяется с RX UART 2-ой AVRки, и т.д. Тогда алгоритм будет такой - если команда не тебе, то передай ее дальше.

В последнем случае можно замкнуть КОЛЬЦО - выход последней AVRки в поезде присоединить к RX UART PC. В такой системе PC сможет получать и ответы от AVRок. При этом каждая AVRка, желающая ответить на поступившую команду (например, подтвердить ее выполнение), пускает по кольцу одностороннего движения информационную посылку, имеющую формат команды, только адресованную 0-му номеру, т.е. PC. Здесь PC может также легко проверить целостность состава, если пошлет по кругу команду ... самой себе, т.е. адресованную нулевому номеру или слишком большому номеру, которого к составе нет - тогда команда должна будет вернуться назад, как эхо, не найдя адресата. В системе, когда каждая AVRка, выполнившая команду, дает по кругу подтвержение о выполнении, целостность кольца подтверждается автоматически.

Почитайте про про алгоритмическую структуру интерфейсов I2C, CAN, ETHERHET, как организуют запросы. Или используте подход MASTER SLAVE и передачу пакетов.

Что в нем особо юмористического? для тестов поезд уже применял на шине RS485
Поезд был логический, конец передачи модуля был командой для старта следующего.

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

другие варианты в данной задаче не рассматриваю.

Действительно, ничего юмористического. Вот есть у нас блочки, живущие на RS-485 кучкой или на RS-232 по одному. Соответственно все пакеты уже под сеть заточены, с адресацией, ответами и т.п.

В один прекрасный момент приходит заказчик с чемоданчиком сами понимаете чего и говорит "хочу такие же N-штук, но у меня только RS-232". Ну ладно, цепляем "паровозиком", в прерывание приёма байта по UART добавляем команду отправки его же по UART и всё. Все блочки, включая и управляющее устройство, пакеты адресованные не ему откидывают по умолчанию.

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

чуть сложнее, сделаю это на уровне пакетов а не байт. пакет не мой транслируем на передачу. прямая трансляция не позволит использовать автонумерацию, и не только ее.
а по надежности, - все блоки внутри одного ящика. это внутренний интерфейс.

TXы AVRов надо соединять через диоды.
а по-хорошему, как уже сказали - шина 485, совсем хоршо если с физическим уровнем от CAN чтобы направлением передачи не греть голову.

Вагончики... паровозики... кольцо... -- а если я скажу "Token Ring", то камни в кого полетят: в меня или в Ксению?
Идея, конечно забавная. Так сказать кольцо без маркера доступа. Работать, разумеется, будет, но как мне кажется, это не самый лучший вариант решения. Там же куча потенциальных проблем. К стати, а где топик-стартер? Или ему все равно?

Мне надо настроить блоки, и получать с них данные по мере поступления.
блоки,- низкоскоростные АЦП 1...10SPS.
Возможно что то типа маркера сделаю, пока не вся железная часть готова.
Пакет опроса, "маркер-контейнер", в хвост которому каждый блок дописывает свои новые данные, или ставит метку пусто.
При работе без маркера, у блока, должна быть очередь сообщений.
С программной стороны для такой работы уже все в наличии.
С пакетом - контейнером, блок должен принять и передать достаточно большой пакет данных.
Дальше для экономии памяти, в длинной цепочке, напрашивается вариант контейнера с диапазоном адресов.
Во всех случаях рассчитываем на худший вариант, у всех есть данные.
С такой задачей опрашивать каждый блок отдельно, неинтересно.

PS. и где проблемы, особенно куча? за камнями обращаться в личку.
Девушкам цветы дарят.

А в чем проблема использовать RS-232, параллельно соединив все ведомые девайсы ?
Тем более, у мегаАВР есть такая штука как Multi-processor Communication Mode. По порядку опрашиваем какждый адрес, необходимый контроллер при ответе включает USART TX и отдает данные, потом выключает TX.

Параллельно соединять RS-232 нельзя! На выходе этого интерфейса (линия TX) может быть или +10 или -10 вольт (вольтаж приблизительный), но отсутствует возможность отключится от линии. Поэтому если один из паралельно подключенных RS-232 начнет что-то передавать, а параллельно ему подключеный останется молчать, то будет коза - напряжения разной полярности на выходе попадут на одну и ту же линию.

Свой USART микропроцессор еще может отключить (т.е. перевести соотвествующие порты в высокоимпендансное состояние), но с RS-232 этот фокус не пройдет.

Хотя... Автор топика не говорил, что у него RS-232, а только USART, а это значит, что идея Клима может быть использована.

вот поэтому их и надо параллелить через диоды.

Да чё нельзя-то сразу? -- Можно! Пусть соединяет (подмигиваю Ксю левым глазом).
Сказано жеж "и где проблемы, особенно куча?"

Только я правда не совсем догоняю, топикстатртер -- это antosh? Или antosh и e-serg -- это одно и то же лицо?


Э-э! Не-не! У топикстартера на рисунке указано -- RS232.

А растояния какие между AVR

Ну-у... Диод + емкость линии = "детекторный приемник" или не менее хреновый одно-полупериодный источник питания. Заваленные фронты и т.д. Короче веселуха. Хотя... если запускать на 2400 и ниже, то вполне, вполне...

Эх-х! Чего только не придумают люди, что бы не использовать RS485.


А-а! Ну так вообще проблем нет!

С компа получаем полноценный RS232 (+/-12В), устанавливаем какую-нибудь хрень типа MAX232/202, и параллельно раздаем на все AVR-ки. Поскольку передача адресная, то отреагирует только одна. Все выходы Tx со всех AVR-ок заводим на 74HC30 (8 И-НЕ), ставим еще один инвертор (НЕ, хоть на транзисторе!) и отдаем на MAX232, а с него на комп.

А с диодами -- не-е, лучше не надо! Это проходили еще в 80-х... на Спектрумах. Ну тогда понятно -- экономили на спичках, пытались выиграть корпус (объем, микросхему), питание, да и некоторые микросхемы было вообще не достать. Приходилось выкручиваться. А сейчас-то! Эх-х, благодать-то какая!

Ну рисунок не очень информативный)
Лично я подразумевал, что с компа выходит RS-232 в TTL уровнях, например PL2303 или FT232 какой-нибудь (Хоть это это уже и не RS-232 по стандарту).
Если так, то проблем вообще никаких. Кроме длины проводов ))
Если подразумевается на каждый контроллер заводить полноценный RS-232 - та надо ставить на каждый драйвер согласования. а если драйвер все таки надо ставить - то тогда прямая дорога к RS-485.

абсолютно с Вами согласен! А поскольку "все находится внутри одного ящика", то городить огород с кучей 485-х драйверов (на каждый модуль, плату или что там предполагается) мне кажется не очень разумно. Если нет требования уйти от мощных помех, я бы не парился с 485-ым, а развел бы все ТТЛ-овским уровнями. Только на входе от компа в ящик поставил бы преобразователь уровней.

я не топик стартер, в одном ли там ящике понятия не имею.
Привёл решение своей, немного схожей, задачи.
RS485 и управление ногами уарта мне не подходит, у меня там ADUM1201 (гальваническая развязка).
ставить дополнительные корпуса, дороже и бессмысленно.
Диодная развязка корява, по терминам монтажное "И".
"И" на дискретной логике не нравится лишними проводами, корпусами, заранее ограниченным числом подключений.
Сейчас два блока АЦП работают по схеме UART <-> UART, точка - точка.
на основном блоке у микропроцессора(STM32F103RE) осталось два свободных UART.
драйвер RS485 в наличии, общение с компьютером по USB(CDC).
Работой прибора заказчик доволен.
В новом сделаю гирлянду, паровозик, вагончик, кольцо, нужное подчеркнуть.
Планируется возможность увеличения числа измерительных каналов.

Посмотрите интерфейс LIN...

платы уже есть рабочие, бюджет пока небольшой.
как LIN, без дополнительных компонентов, взгромоздить на ADUM1201.
Сам виновник обсуждения не появляется.
PS. c LIN знаком, делал устройства.

Нет интерфейса лучше, чем SPI! (С) Холивар

Есть! 1-Wire!
На один провод меньше и питание можно по тому же проводу гнать.

На 3 провода меньше если уж на то пошло. GND и там и там, в SPI еще есть CS.
Но и то и другое - гуано для соединения множества устройств в одну сеть. SPI это точка-точка в чистом виде, 1-wire - геморрой с времянками.

Плясать от простой общей шины надо (485, i2c, CAN), а всякие паровозики да колечки - от лукавого.

Интересно, что побудило при выборе полудуплекса, использовать 1201 а не 1301 ?

Это ж как он должен достать своей помехоустойчивостью, чтобы такое написать!

И чтобы аппаратная поддержка на борту была. А если уж совсем обнаглеть, то и аппаратное декодирование адреса, подсчет CRC...

Вообще такая же задача передо мной стоит. Пока склоняюсь к RS-485. На объекте есть прокинутая витая пара (одна) + возможно еще несколько проводков.

Не подскажет кто-нибудь, можно ли элегантно на оптронах построить развязку для дифференциального сигнала? Просто рядом лежат оптопары с триггером шмитта. А покупать опторазвязку от MAXIM - дорого.

с гальванической развязкой
adm2582e

дешевле - рассыпуха. питание генератор или самому качать через трансик. либо если ИБП - заводить с него.

удачи вам
(круглый)

PC817 на переключение рием/передача
H11L1 на все остальное.

Я бы не заморачивался с развязкой дифф сигнала дабы не портить характеристики сети. Куда проще развязать TTL сигнал между МК и драйвером. Еще проще - развязать питание устройства от общей линии питания и исключить землю с RS485 разъема. В __худшем__ случае (например монтажник перепутал 220В с 485-м)если нет супрессоров по входу 485-го сгорает только драйвер - проверено временем.

Драйверы пользую самые дешевые типа ADM485AR. Их ремонто-пригодность восхищает - при замыкании входов A/B на 220 горят очень аккуратно - плату не портят - просто образуется маленькая дырочка сверху на корпусе МС ) Сдул, надел новую и всё.

Спасибо, друзья! Учту все советы и пожелания!

Тут кто то кого то путает, "haker_fox" топик стартер?
ADUM1201 выбрал для дуплекса , модули уже хорошо работают в одной задаче, и выбор был между 1201 и оптронами.
решил что с ADUM возможных проблем меньше, сейчас эти же модули для другой задачи приспособил.

Никакой путаницы haker_fox присоединился позже к беседе, больно уж она интересная оказалась) Внимательно читайте топик

+1


Если есть желание или необходимость использовать именно ADUM1201, то у maxim-а есть транссиверы с автоматическим переключением: приемник/передатчик, - например MAX13413

Вот, для размышления, да и просто для "пополнения коллекции".

...и вот еще...

Существует расхожее мнение, будто бы использование RS-485 автоматически обеспечивает помехоустойчивость. Это мнение глубоко ошибочное. Помехоустойчивость самодельного интерфейса на базе RS-485, сляпанного малограмотными людьми, окажется ниже, чем интерфейса RS-232 или даже LIN.

Для получения высокой помехоустойчивости RS-485 необходимо использовать грамотный протокол. Например, Modbus RTU и т.п.

Абсолютно согласен.

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

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

В качестве конкретного примера можно привести самопальный интерфейс Pbus, на который "для размышления" давали ссылку на этой странице. Этот самопал не будет помехоустойчивым при использовании RS-485.

Для того, чтобы я мог что-то конкретное сказать о протоколах, которые используете лично вы, будьте любезны, приведите их описание. Тогда и будет видно, невежда ли вы, или же инженер, знающий толк в интерфейсах.

Пафосно. Даже очень
А после этого:

Становится грустно и смешно . Для начала показали, что не отличаете физический уровень интерфейса от логических.
Дальше, помянутый Вами в качестве "грамотного" протокола Modbus RTU - образец древнего протокола с уродливо и кое-как спроектированным канальным уровнем. Да он издревле получил широкое распространение в тупо-консервативном мирке релейно-промышленно-автоматчиков. Но и за пределами это мира есть жизнь, поверьте . Единственны его огромный и единственный плюс, то, что он был сделан ОТКРЫТЫМ. То, что он живет, конечно объяснимо - сроки жизни оборудования велики и совместимость обеспечивать надо. Кроме того, после инкапсулирования фреймов Modbus в другие протоколы уродство его нижних уровней становится не принципиальным. Он живет. Но его нижние уровни натуральный образец уродства. То, чтоб прикладной уровень его стандартизирован, для самодельной сети на AVR совершенно ненужная фича. Вот и получается, что поминание Modbus RTU особенно в контексте данной просто вредно. Вообще все базовые идеи построения канального и сетевого уровня были опубликованы, реализованы и даже стандартизированы в 70x, т.е. еще до того, как промавтоматчики родили как могли Modbius RTU.

Увы, в деле обеспечения помехоустойчивости это не играет никакой роли. Протокол, используемый поверх RS-485, или обеспечивает помехоустойчивость, или не обеспечивает ее. Он может быть сколь угодно красив или уродлив на канальном уровне, эстетика не имеет никакого отношения к помехоустойчивости. Соответственно, те, кто в курсе, никогда не будут кидаться какашками в Modbus RTU, поскольку он был одним из первых протоколов, который обеспечивал помехоустойчивость. А невежды, которые даже не понимают, о чем идет речь, конечно, могут стебаться над почтенным родоначальником промышленных интерфейсов и из кожи вон лезть, пытаясь объяснить его долгожительство.

Летнее обострение

Вы-бы сначала огласили свою трактовку термина "помехоустойчивость" а то право чистый бред:

И это Вы написали про увеличение "помехоустойчивости" физического уровня за счет логической организации передаваемой информации?

Только как тогда прикажете понимать Ваши слова:


Я в непонимании.

"Невежды", к Вашему сожалению знают и написали об этом, что "родоначальники промышленного интерфейса" сделали работу через жопу и даже не потрудились ознакомится с тем, как уже до них строились протоколы. "Невежды" как-бы так по жизни связаны с системами передачи информации и немалое количество протоколов всех уровней реализовывали своими руками. Как стандартных, так и расширений/подмножеств стандартных, так и достаточно самодельных. Но по любому даже при самодельных весь предыдущий опыт использовался. При этом Modbus RTU это практически единственный стандартизированный протокол который может служить примером того, как никогда не надо делать нижние уровни. "Невежды" на днях в очередной раз начнут пропихивать Modbus RTU в асинхронный канал и думать, это каким-же "чудаком" надо быть, что-бы свалить в кучу асинхронную передачу и выделение фреймов по временным интервалам. Предшественники этих "родоначальников" к этому времени уже поняли и застандартизировали
использование в для асинхронной передачи байтстаффинга а для синхронной битстаффинга. ""родоначальники промышленного интерфейса" таки родили и протокол Modbus ASCII вполне соответствующий асинхронной природе используемого физического канала, но ценой чрезмерно избыточного кодирования.

Проснитесь! На дворе лето к концу идет. Так-что "обострение" просто вызвано необходимостью, как уже писал выше, реализовывать в очередной раз канал передачи для такого дерьма, как Modbus RTU на фоне экспертных рассуждений =AK=. Да можете считать, что попал под горячую руку. Но этот факт никак не умаляет уродства канального уровня Modbus RTU.

Да, именно это я и написал. Помехоустойчивость интерфейса на базе RS-485 зависит от протокола обмена, т.е., если вам угодно, от "логической организации передаваемой информации". Я об этом уже который пост подряд пишу, а вы все своим глазам поверить не можете, очевидно, вследствие своего обширного багажа знаний.

До предела простым языком, для совсем тупых. В приведенных мною выше двух примерах помехоустойчивость отличается примерно в 100-200 раз:
- в интерфейсе Pbus помехоустойчивость минимальна
- в интерфейсе Modbus RTU она максимальна

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



Modbus ASCII предназначен для интерфейсов "точка-точка" (RS-232, RS-422, и т.п), о чем прямо написано в стандарте. Он непригоден для RS-485, поскольку в этом случае обеспечивает крайне низкую помехоустойчивость.

На столе в лаборатории, когда помех нет, работать будет. Для ламеров такого рода эксперименты, очевидно, могут послужить достаточным основанием, чтобы провозгласить "ненужность" Modbus RTU


В моей трактовке она пропорциональна мощности наведенной помехи, при которой обмен становится невозможен.

Я я Вам уже второй раз пишу, что это бред и то, что Вы не можете для себя разделить физический и последующие уровни протокола. Для некоторых физических интерфейсов,
например имеющих доминантное состояние передаваемая информация теоретически влияет на помехоустойчивость - типа передавайте больше нулей . Но это уже схоластика.

Я также просил сформулировать что Вы подразумевете под термином "помехоустойчивость интерфейса 485". Ответа не получил. Так-же хотелось-бы получить разъяснения по поводу Ваших термина "помехоустойчивость интерфейса Modbus RTU" и почему помехоустойчивость интерфейса 485 у Вас как-то странно перетекает в "помехоустойчивость интерфейса Modbus RTU"?




Ну-ну. Имеем два фрейма. Один Modbus RTU, второй некий Pbus. Возможно они несколько отличаются размером, но надеюсь не в 200 раз? Оба фрейма передаются через 485 интерфейс. Имеем некую помеху, некой мощности, которая неведая (надеюсь не будете возражать, что не ведая? ) искажает один бит фрейма Modbus RTU и один бит Pbus.
Строго говоря эта одиночная ошибка при хоть наличии хоть какого-то контроля приведет к тому, что фрейм и в том и другом случае будет отборошен.
Почему-же Вы тогда утверждаете, что:

??? Можно узреть методу оценки? Желательно изложить в стиле не для совсем тупых, а то боюсь не понять

Ой! Можно помолчу, а то....

Ой! два раза......

P.S.
Можете не отвечать. И простите, что на Вас наехал, просто на уровень эксперта Вы совсем не тянете, а от Вашей фразы:

так понтами повеяло, что не сдержался

Разве? У нас ещё середины не наступало. Вы с какой планеты?
Я не про Вас, кстати. У Вас всё стабильно постоянно, без обострений


Хорошая заява. То есть физический уровень - одинаковый, RS485. Более верхний - Modbus (RTU), который не умеет вообще исправлять ошибки, возникающие на уровне RS485. И при этом гений от электроники говорит о в сотнях раз большей помехоустойчивости, которая в его интерпретации означает продолжение нормального обмена данными между устройствами при в сотню(и) раз больших уровнях помех. Гений не знает, что если в пакете Modbus возникнет хоть одна битовая ошибка, то весь пакет улетит в мусорку

Обострение серьёзней, чем предполагалось.

Планета земля. Северное полушарие. Середина лета была 22 июня. Дело к осени, длительность дня сокращается.

Вы ведь знаете правильный ответ, но пытаетесь обмануть. 22 июня была максимальная длительность дня. Не лета, и не среднемесячной/недельной/... температуры. Времена года, в том числе и лето, сдвинуты относительно максимума дня ПО ТЕХНИЧЕСКИМ ПРИЧИНАМ Официально лето с 1 июня до 31 августа. Читайте первоисточники. Вы же любите/уважаете стандарт

Имеем некую помеху, мощность которой мы постепенно увеличиваем.

Еще до того, как помеха исказит сам фрейм, она успеет исказить состояние линии в промежутке между фреймами. В этом промежутке ни один из передатчиков не включен, а состояние линии задается резисторами растяжки RS-485 (если они есть). Доводим помеху до уровня, когда она начинает пересиливать резисторы растяжки, и смотрим поведение того или иного протокола.

Modbus RTU относится к наличию этой помехи индиферентно. Согласно протоколу, передающий узел обязан включить свой передатчик заранее и удерживать RS-485 в пассивном состоянии, ничего не передавая, в течении 3.5 (если память не изменяет) байт-интервалов (это называется "преамбула"). А приемники обязаны игнорировать текущий фрейм и очистить свои буфера обмена в случае, если промежуток между соседними байтами во фрейме превышает 1.5 (опять же, по памяти) байт-интервалов. Таким образом, наведенная в промежутке между фреймами помеха вполне может вызвать начало ложного приема для всех приемников, они могут начать принимать помеху как новый фрейм. Однако в течении преамбулы все приемники Modbus RTU неизбежно обнаружат, что пауза превысила допустимую длину, очистят свои буфера и будут готовы к приему настоящего фрейма.

В случае Pbus, а также огромного количества самопальных протоколов, помеха, пересилившая резисторы растяжки, вызывает начало приема ложного фрейма, который протокол долгое время не в состоянии отличить от истинного фрейма. Истинный фрейм будет "приклеен" к хвосту ложного фрейма, начатого помехой. В лучшем случае ошибка приема будет обнаружена по несовпадению CRC. Однако к этому времени "поезд ушел", фрейм оказался испорчен и не может быть восстановлен. Даже если источник заново передаст фрейм (скажем, из-за отсутствия Ack-а от приемника), гарантий доставки у него никаких нет - помеха достаточного уровня может испортить и этот фрейм, и следующие.

Чтобы испортить фрейм Modbus RTU, помеха должна пересилить не резисторы подтяжки, а выход работающего передатчика RS-485. Для этого она должна иметь мощность в 100-200 раз больше, чем для того, чтобы пересилить резисторы растяжки.


Таким образом доказано, что в области помехоустойчивых интерфейсов лично вы невежда (кстати, ваш подпевала в топике - GetSmart - тоже). Мне искренне жаль тех заказчиков, для которых вы "протоколов всех уровней реализовывали своими руками".

А уж сколько было от вас понтов и гонора в отношении Modbus RTU... Жесткие интервалы, которые вас, как программиста, так раздражают, как раз и обеспечивают его помехоустойчивость. Теперь будете знать.

Вообще-то любой не совсем уже бездарный протокол обмена, приняв байт и видя, что за ним не идут далее байты (в течении сколько-то символов) должен или обработать принятый "пакет" или его отбросить и подготовиться к приёму нового пакета. Поэтому возникает сразу предположение, относительно чего сравнивать. Если относительно дерьма, то теоретически Modbus+485 будет значительно помехоустойчивей. Но если относительно любого не дерьма, то как раз наоборот, в разы менее помехоустойчивей.

Чаще всего, на шине RS485 присутствует 1 мастер и много слейвов. И мастер всегда шину держит занятой, кроме времени когда ждёт ответа от слейва. Таким образом, помехи, которые способны исказить только свободно "болтающуюся" шину, уже не способны это делать. При этом анализировать настолько мелкие помехи, способные только болтающуюся линию болтать, это как обращать внимание на все микробы на пальцах, которыми держишь ложку во время еды. Только совсем уже больным, совсем без иммунитета, необходимо.