Сеть из AVR Опции

[antosh]

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

[Клим]

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

[Xenia]

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

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

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

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

[zhevak]

Параллельно соединять RS-232 нельзя!

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

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

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

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

[Клим]

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

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

[zhevak]

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

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

[=AK=]

Если нет требования уйти от мощных помех, я бы не парился с 485-ым, а развел бы все ТТЛ-овским уровнями.

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

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

[zhevak]

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

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

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

[=AK=]

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

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

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

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

[zltigo]

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

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

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

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

[=AK=]

Дальше, помянутый Вами в качестве "грамотного" протокола Modbus RTU - образец древнего протокола с уродливо и кое-как спроектированным канальным уровнем.

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

[zltigo]

Протокол, используемый поверх RS-485, или обеспечивает помехоустойчивость, или не обеспечивает ее.

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

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

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

Он может быть сколь угодно красив или уродлив на канальном уровне, это не имеет никакого отношения к помехоустойчивости.

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

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

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

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

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

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

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

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

[=AK=]

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

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

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

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

""родоначальники промышленного интерфейса" таки родили и протокол Modbus ASCII вполне соответствующий асинхронной природе используемого физического канала, но ценой чрезмерно избыточного кодирования.

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

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

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

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

[zltigo]

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

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

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

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

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

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

В приведенном мною выше двух примерах помехоустойчивость отличается примерно в 100-200 раз:

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

Modbus ASCII предназначен для интерфейсов "точка-точка" (RS-232, RS-422, и т.п), о чем прямо написано в стандарте.

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

Он непригоден для RS-485, поскольку в этом случае обеспечивает крайне низкую помехоустойчивость.

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

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

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

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

[=AK=]

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

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

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

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

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

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

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

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

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

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