Сеть из 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, дождь. Зима говорят у нас в Сиднее.

[=AK=]

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

Я уже говорил, что обмен не сводится к поведению одного только мастера. Ну, а самое главное: может держать, а может и не держать, как уж заблагорассудится программисту. Однако среди программистов, как мы выяснили на ваших с подельником примерах, полно тех, кто не понимает, что незначительные (с их точки зрения) нюансы реализации могут изменить помехоустойчивость в сотни раз.

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

АБСОЛЮТНО также могут поступать реализаторы в любого подобного протокола в том числе и Pbus.

В описании Pbus сказано, что слэйв должен игнорировать принятые символы, если зазор между ними превышает 200 мкс. Но при этом обмен идет на скорости 2400, т.е. битовый интервал равен 416 мкс. Так что этому невменяемому бреду, который вы защищаете, место в топке.

Самое жуткое для борца с помехами состоит в том, что в нормальных протоколах (а это не Modbus RTU ) началом/концом фрейма является не одиночный (один, совсем один) стартовый бит а определенная последовательность битов. Причем к нормальным протоколам относится и тот самый Modbus ASCII (последовательность из 10 bit), который как Вы экспертно оценили, цитирую "Он непригоден для RS-485, поскольку в этом случае обеспечивает крайне низкую помехоустойчивость".

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

[zltigo]

Я уже говорил, что обмен не сводится к поведению одного только мастера. Ну, а самое главное: может держать, а может и не держать, как уж заблагорассудится программисту. Однако среди программистов, как мы выяснили на ваших с подельником примерах, полно тех, кто не понимает, что незначительные (с их точки зрения) нюансы реализации могут изменить помехоустойчивость в сотни раз.

Я рад, что Вы тем не менее поняли, что "потрясающая помехоустойчивость" протокола Modbus RTU совершенно не является его особенностью. И в никаком "стандарте" соответственно как особенность Modbus RTU этот банальный трюк (про в 200 раз повышающий оставим на Вашей совести) не описан и более того применим к началу фрейма абсолютно любого протокола использующего асинхронный физический уровень.

В описании Pbus сказано, что слэйв должен игнорировать принятые символы, если зазор между ними превышает 200 мкс. Но при этом обмен идет на скорости 2400, т.е. битовый интервал равен 416 мкс. Так что этому невменяемому бреду, который вы защищаете, место в топке.

Мне наплевать,что там Вам там не травится в Pbus - я с ним не знаком и не собираюсь знакомится, не разу его не защищал. По той простой причине, что утверждал и утверждаю - любой протокол включая Modbus RTU, который на физическом уровне использует асинхронные приемопередатчики, а на канальном уровне для выделения таймауты есть дерьмо изначально. Борьба, победы,поражения реализаторов Modbus RTU с изначально заложенном в нем дерьмом меня в принципе не интересуют. Дерьмо остается дерьмом. Я понимаю,что это Ваше любимое (точнее единственно знакомое ) дерьмо и что предела дерьмовости почти нет, и что Вы видели дерьмо по сравнеию с которым дерьмо Modbus RTU благоухает розами. Только это не изменит того факта, что канальный уровень Modbus RTU изначально дерьмов.

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

Для тех, кто мозгов вообще не имел изначально, повторять очевидно бесполезно . Да будет, да, так у меня и написано. Но время этого "опасного" интервала указано. И для дерьмового протокола Modbus RTU это время указано. И сравнение двух этих времен сделано. Повторю, еще раз - хреновато у Modbus RTU даже супротив Modbus ASCII, даже при сравнении по этому одному из многих ИСКУССТВЕННО взятому Вами для сравнения критерию оценки "помехоустойчивости".

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

Таки да . Modbus в неполноте описания среди распространенных протоколов рекордсмен . Это в общем-то и понятно - этот изначально не продуманный протокол на официальную стандартизацию никак не тянул. Слепили как умели, описали как могли, реализовали, как получилось и каждый сам. На самом деле проблемы Modbus RTU канальном уровне. Дальше проблемы в ПОЛНОМ отсутствии верхних уровней с 3 по 6. Собственно сейчас в разумных разработках только Application уровень Modbus и используется. Все остальные уже используются от ЛЮБЫХ чужих стеков. Само описание железно разделено на два документа, осталось только документ описывающий канальный уровень объявить устаревшим и все . Да вообще-то и не надо, ведь это даже по названию не описание протокола, а некий Implementation Guide - какой спрос .

[Dog Pawlowa]

Дальше проблемы в ПОЛНОМ отсутствии верхних уровней с 3 по 6.

Ну, для простых последовательных протоколов объединение уровней - обычное решение, в результате получаем контроль доставки на уровне приложения. Сам такие протоколы "клёпал"
Хотелось бы напомнить, что в мире существуют стандарты, имеющие прямое отношение к передаче инфрмации.
Например, DIN 66348, в результате имеем обмен типа такого (с экрана симулятора в режиме подмены управляющих кодов).

Код

ENQ          STX 3D11011012021202030300040400050500060600 ETB 60          STX 3D11070070080080099009000000000000000000 ETX 7D          EOT              
      DLE  0                                                       DLE  1                                                       DLE  0