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

Тут кто то кого то путает, "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.
Можете не отвечать. И простите, что на Вас наехал, просто на уровень эксперта Вы совсем не тянете, а от Вашей фразы:

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