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

[antosh]

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

[zltigo]

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

Этот волшебный "200 кратного уменьшения влияния помех" механизм де факто реализуется во всех примитивных протоколах типа Master/Slave запрос/ответ, ибо по другому еще надо постараться сделать. Master вообще может держать свой передатчик сколь угодно долго. Даже страшно подумать во во сколько возрастет "помехащищенность" . При этом вот это Ваше утверждение:

Согласно протоколу, передающий узел обязан включить свой передатчик заранее и...

не есть требование протокола. Требование протокола распространяется только на наличие silent interval. Что там должно быть с физикой и как это обеспечивавается это дело десятое. Вы его можете включать заранее, Вы его можете вообще не выключать, и АБСОЛЮТНО также могут поступать реализаторы в любого подобного протокола в том числе и Pbus.
Самое жуткое для борца с помехами состоит в том, что в нормальных протоколах (а это не Modbus RTU ) началом/концом фрейма является не одиночный (один, совсем один) стартовый бит а определенная последовательность битов. Причем к нормальным протоколам относится и тот самый Modbus ASCII (последовательность из 10 bit), который как Вы экспертно оценили, цитирую "Он непригоден для RS-485, поскольку в этом случае обеспечивает крайне низкую помехоустойчивость". Фраза "Modbus ASCII предназначен для интерфейсов "точка-точка" (RS-232, RS-422, и т.п), о чем прямо написано в стандарте" тоже хороша, если, конечно, не знать что а в спецификации (а не стандарте, которого нет) Modbus over Serial такой глупости, естественно не написано. К этому можно добавить, что за счет избыточности в том-же Modbus ASCII можно пробовать восстанавливать битую информацию. Вот такой вот странный протокол с "крайне низкой помехоустойчивостью". Нет, наверное все-таки не протокол странный, а "эксперт" очень странный .

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

Главное, что им не жаль .

Официально лето с 1 июня до 31 августа. Читайте первоисточники. Вы же любите/уважаете стандарт

Не знаю, что Вы называете первоисточником, я ориентируюсь по РЕАЛЬНОМУ первоисточнику - Солнцу. Возражения по поводу его прав считаться первоисточником есть?
Ну а чего-уж там кто что думает... Я вот знаю дюжину человек, так они вообще, чудаки, все, как один думают, что у них сейчас совсем даже не лето - +10, дождь. Зима говорят у нас в Сиднее.

[GetSmart]

Не знаю, что Вы называете первоисточником, я ориентируюсь по РЕАЛЬНОМУ первоисточнику - Солнцу.

Первоисточник - календарь. Документ, между прочим.
А когда по Солнцу Новый год? Тоже отмечаете по Солнцу

[ViKo]

Первоисточник - календарь. Документ, между прочим.
А когда по Солнцу Новый год? Тоже отмечаете по Солнцу

Извиняюсь, по теме сказать мне нечего. Прочитал с интересом, но не нашел конкретной информации "как сделать хорошо".
А по поводу лета и календаря - предлагаю GetSmart'у "исполнить" zltigo смарт-вопросом "А когда, по-вашему, начало и конец лета?" Думаю, ответ впечатлит и самого отвечающего.

[=AK=]

не нашел конкретной информации "как сделать хорошо"

"Как сделать хорошо" описано в посте №65 (с уточнением в посте №67).

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

Вам полезно будет узнать, что в радиоканалах как правило требуется сигнал, сбалансированный по DC, в силу чего символ, состоящий из одного только старт-бита не годится. Кроме того, в радиоканалах часто встречаются жесткие ограничения на длину подряд передаваемых нулей и единиц. Поэтому, при использовании в радиоканале UART, для байт-синхронизации в наибольшей степени подходит символ 0xF0, о котором я говорил ранее.

При этом, вопреки вашему глупому заявлению, будто бы "посылка ложного стартового фрейма в качестве space символа есть наихудший из всех возможных вариантов", именно этот символ - 0xF0 - лучше всего сделать стартовым символом, обозначающим начало фрейма. Таким образом, передав два раза старт-символ 0xF0 можно одновременно обеспечить синхронизацию UART (т.е. байт-синхронизацию) и синхронизацию фрейма. Это упрощает процедуру передачи, а негативных эффектов в этом решении нет. Впрочем, допускаю, что лично вы пишете софт настолько криво и бездарно, что двойная передача старт-символа приводит в ваших поделках к каким-то негативным последствиям, поэтому вызывает возражения с вашей стороны.

В случае RS-485, где требований к балансу по DC нет, в качестве стартового символа фрейма подходит любой из символов, двукратная передача которых обеспечивает байт-синхронизацию UARTa, а именно: 0xFF, 0xFE, 0xFC, 0xF8, 0xF0, 0xE0, 0xC0, 0x80, 0x00. При достаточном быстродействии процессора никакой разницы между ними нет, любой из этих символов при приеме придется обрабатывать одинаково. И только в том случае, когда в приемнике стоит дико тормознутый процессор или же софт написан до предела криво, тогда предпочтение следует отдать символу 0xFF.

[zltigo]

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

Вам бесполезно будет узнать, что Вам не следует продолжать выдумывать "правила".

Поэтому, при использовании в радиоканале UART, для байт-синхронизации в наибольшей степени подходит символ 0xF0, о котором я говорил ранее. Таким образом, передав два раза старт-символ 0xF0 можно одновременно обеспечить синхронизацию UART (т.е. байт-синхронизацию) и синхронизацию фрейма.
....

Разумеется нет. Захотите понять, или жизнь заставит, поймете. Хотя для Вас это маловероятно . Для заполнения Вашего мозга до отказа оказалось достаточным одной единственной "идеи" с предварительной активизацией передатчика RS485. Ну да ладно. Хотя, как я тут смотрю уже который пост подряд Вы таки допустили мысль о признаке начала фрейма не по паузе, как это сделано у дебильного Modbus RTU. Это положительная тенденция.

Я не понимаю, что за достоинства при наличии доминантного состояния, не подскажете?

Гарантированное состояние при коллизиях в линии. Соответственно появляется возможность достоверно контролировать собственную
передачу и использовать в протоколе механизмы разруливания коллизий.

[=AK=]

422 а еще лучше CAN приемопередатчики, даже если без CAN контроллера.

Это очередная глупость.

Передатчик RS422 имеет меньшую нагрузочную способность, поэтому он обеспечит примерно вдвое меньшую помехоустойчивость связи, чем передатчик RS485. Интерфейс RS422 следует рекомендовать начинающим и дилетантам, поскольку в нем передатчик все время включен, а посему автоматический обеспечивается хороший уровень помехоустойчивости при любом протоколе обмена, хоть самом простом. В сущности RS422 представляет собой улучшенный (быстрый, более помехоустойчивый и пригодный для больших расстояний) старый добрый RS232.

Проводной CAN передатчик (такой как SN65HVD251 и т.п.) представляет собой разновидность "открытого коллекторного выхода". В рецессивном состоянии он подвержен помехам почти настолько же, насколько подвержена помехам свободная линия RS485 с растяжками. Соответственно, помехоустойчивость CAN примерно на порядок хуже, чем RS485 и RS422.

Гарантированное состояние при коллизиях в линии. Соответственно появляется возможность достоверно контролировать собственную
передачу и использовать в протоколе механизмы разруливания коллизий.

К помехоустойчивости это отношения не имеет.