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

[antosh]

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

[GetSmart]

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

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

Сообщение отредактировал GetSmart - Jul 10 2011, 15:16

[=AK=]

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

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

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

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

Если же вы считаете иначе - будьте любезны, приведите пример "в разы более помехоустойчивого" с необходимым обоснованием .

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

Даже в этом гипотетическом варианте помеха способна изгадить ответ от слейва. В результате этого обмена таки не будет: в типичном случае мастер еще несколько раз пошлет запрос слейву, а затем зачислит его в категорию неисправных, или типа того.

Так что зря тужитесь.

[Dog Pawlowa]

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

Что касается стартовой последовательности бит... Как использовать это с помощью стандартного UARTа во всем диапазоне параметров передачи?

[zltigo]

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

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

Что касается стартовой последовательности бит... Как использовать это с помощью стандартного UARTа во всем диапазоне параметров передачи?

Не понял. Ecли о 10 битах Modbus ASCII, это start-7bit_data_parity_stop. Естественно, они штатно обрабатываются UART.

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

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

В любом вменяемом базирующимся на ассинхронной передачи байтов протоколе это "долгое время" менее ОДНОГО байта. Один байт, который будучи принятым с ошибкой (paryty или frame) и/или НЕ будет соответствовать комбинации начала фрейма будет отброшен. Опасное, так сказать время (почему всю "помехоустойчивось" Вы сводите только к нему оставим на Вашей совести) за время которого помеха способна вызвать потерю всего фрейма это время менее передачи одного символа. В дебильнейшем даже с этой точки оценки Modbus RTU помеха в 1+1,5 символьном интервале перед началом фрейма вызывает облом со всем фреймом. Вот такой он оказывается "обеспечивающий максимально возможную для RS-485 помехоустойчивость" протокол. Абыдно, да....

Так что зря тужитесь.

Наверное зря - трудно разгововаривать с Вами, который собственно и Modbus толком не знает (приписывание требования включения передатчика на slient inteval, приписывание требования использования Modbus ASCII только для дуплекс и point to point, обвинение ASCII в пресловутой непомехоустойчивости, приписывание почему-то только Modbus исключительной возможности подержать передатчик включенным перед началом фрейма). Так-что расслабьтесь - лично для Вашей персоны никто не тужится. Просто пресекаем дезинформацию.