Сеть из 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.