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

[antosh]

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

[smalcom]

RS-485

[Xenia]

Это будет суперкомпьютер на AVR!

Вообще-то, если задача сводится ТОЛЬКО к передаче управляющей команды от PC к AVRкам, а обратную информацию от AVRок в PC принимать не планируется, то допустимо все входы RX UART AVRок присоединить к одному и тому выходу TX UART PC, предварительно сделав этот сигнал более мощным. Тогда все они окажутся как бы повешенными на одну шину, с которой будут читать команды от PC (понятно, что линии передачи TX AVRок соединять между собой нельзя). Остальное дело программирования - сделать так, чтобы каждая AVRка знала свой номер и выполняла тольку ту команду, которая адресована ней, а на чужие внимания не обращала.

Можно пойти и по альтернативному пути, хотя он более юмористический - соединить AVRка поездом, как вагончики. При этом TX UART PC поступает на RX UART 1-ой AVRки, ее TX соединяется с RX UART 2-ой AVRки, и т.д. Тогда алгоритм будет такой - если команда не тебе, то передай ее дальше.

В последнем случае можно замкнуть КОЛЬЦО - выход последней AVRки в поезде присоединить к RX UART PC. В такой системе PC сможет получать и ответы от AVRок. При этом каждая AVRка, желающая ответить на поступившую команду (например, подтвердить ее выполнение), пускает по кольцу одностороннего движения информационную посылку, имеющую формат команды, только адресованную 0-му номеру, т.е. PC. Здесь PC может также легко проверить целостность состава, если пошлет по кругу команду ... самой себе, т.е. адресованную нулевому номеру или слишком большому номеру, которого к составе нет - тогда команда должна будет вернуться назад, как эхо, не найдя адресата. В системе, когда каждая AVRка, выполнившая команду, дает по кругу подтвержение о выполнении, целостность кольца подтверждается автоматически.

[MaslovVG]

Почитайте про про алгоритмическую структуру интерфейсов I2C, CAN, ETHERHET, как организуют запросы. Или используте подход MASTER SLAVE и передачу пакетов.

[e-serg]

Это будет суперкомпьютер на AVR!
=======
Можно пойти и по альтернативному пути, хотя он более юмористический - соединить AVRка поездом, как вагончики.
=======

Что в нем особо юмористического? для тестов поезд уже применял на шине RS485
Поезд был логический, конец передачи модуля был командой для старта следующего.

Сейчас как вариант рассматриваю именно поезд.
Имею, измерительные блоки гальванически развязаны через ADUM1201.
Варианты:
1) входа блоков вместе, выхода через логику "И".
2) паровоз, достоинства паровоза, достижима большая плотность данных при той же скорости.
блоки могут самостоятельно начинать передачу.
Нумерация блоков не проблема, на нее отдельная команда блок читает номер увеличивает и передает следующему.
основной блок в итоге знает длину цепи.
еще одно достоинство, не придется переразводить существующие платы.

другие варианты в данной задаче не рассматриваю.

[VladislavS]

Действительно, ничего юмористического. Вот есть у нас блочки, живущие на RS-485 кучкой или на RS-232 по одному. Соответственно все пакеты уже под сеть заточены, с адресацией, ответами и т.п.

В один прекрасный момент приходит заказчик с чемоданчиком сами понимаете чего и говорит "хочу такие же N-штук, но у меня только RS-232". Ну ладно, цепляем "паровозиком", в прерывание приёма байта по UART добавляем команду отправки его же по UART и всё. Все блочки, включая и управляющее устройство, пакеты адресованные не ему откидывают по умолчанию.

Надёжность такого решения чисто теоретически ниже, но на практике устройства, блокирующие правильную шину встречались, а порванный паровозик ещё нет. Хотя и применяли его считанные разы.

[e-serg]

===
В один прекрасный момент приходит заказчик с чемоданчиком сами понимаете чего и говорит "хочу такие же N-штук, но у меня только RS-232". Ну ладно, цепляем "паровозиком", в прерывание приёма байта по UART добавляем команду отправки его же по UART и всё.
===

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

[_pv]

... Тогда все они окажутся как бы повешенными на одну шину, с которой будут читать команды от PC (понятно, что линии передачи TX AVRок соединять между собой нельзя).

TXы AVRов надо соединять через диоды.
а по-хорошему, как уже сказали - шина 485, совсем хоршо если с физическим уровнем от CAN чтобы направлением передачи не греть голову.

[zhevak]

Вагончики... паровозики... кольцо... -- а если я скажу "Token Ring", то камни в кого полетят: в меня или в Ксению?
Идея, конечно забавная. Так сказать кольцо без маркера доступа. Работать, разумеется, будет, но как мне кажется, это не самый лучший вариант решения. Там же куча потенциальных проблем. К стати, а где топик-стартер? Или ему все равно?

[e-serg]

Там же куча потенциальных проблем. К стати, а где топик-стартер? Или ему все равно?

Мне надо настроить блоки, и получать с них данные по мере поступления.
блоки,- низкоскоростные АЦП 1...10SPS.
Возможно что то типа маркера сделаю, пока не вся железная часть готова.
Пакет опроса, "маркер-контейнер", в хвост которому каждый блок дописывает свои новые данные, или ставит метку пусто.
При работе без маркера, у блока, должна быть очередь сообщений.
С программной стороны для такой работы уже все в наличии.
С пакетом - контейнером, блок должен принять и передать достаточно большой пакет данных.
Дальше для экономии памяти, в длинной цепочке, напрашивается вариант контейнера с диапазоном адресов.
Во всех случаях рассчитываем на худший вариант, у всех есть данные.
С такой задачей опрашивать каждый блок отдельно, неинтересно.

PS. и где проблемы, особенно куча? за камнями обращаться в личку.
Девушкам цветы дарят.

[Клим]

А в чем проблема использовать 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, а это значит, что идея Клима может быть использована.

[_pv]

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

вот поэтому их и надо параллелить через диоды.

[zhevak]

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

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

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

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

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

[ILYAUL]

А растояния какие между AVR

[zhevak]

вот поэтому их и надо параллелить через диоды.

Ну-у... Диод + емкость линии = "детекторный приемник" или не менее хреновый одно-полупериодный источник питания. Заваленные фронты и т.д. Короче веселуха. Хотя... если запускать на 2400 и ниже, то вполне, вполне...

Эх-х! Чего только не придумают люди, что бы не использовать RS485.

а по надежности, - все блоки внутри одного ящика. это внутренний интерфейс.

А-а! Ну так вообще проблем нет!

С компа получаем полноценный RS232 (+/-12В), устанавливаем какую-нибудь хрень типа MAX232/202, и параллельно раздаем на все AVR-ки. Поскольку передача адресная, то отреагирует только одна. Все выходы Tx со всех AVR-ок заводим на 74HC30 (8 И-НЕ), ставим еще один инвертор (НЕ, хоть на транзисторе!) и отдаем на MAX232, а с него на комп.

А с диодами -- не-е, лучше не надо! Это проходили еще в 80-х... на Спектрумах. Ну тогда понятно -- экономили на спичках, пытались выиграть корпус (объем, микросхему), питание, да и некоторые микросхемы было вообще не достать. Приходилось выкручиваться. А сейчас-то! Эх-х, благодать-то какая!

[Клим]

Э-э! Не-не! У топикстартера на рисунке указано -- 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-ым, а развел бы все ТТЛ-овским уровнями. Только на входе от компа в ящик поставил бы преобразователь уровней.

[e-serg]

абсолютно с Вами согласен! А поскольку "все находится внутри одного ящика",

я не топик стартер, в одном ли там ящике понятия не имею.
Привёл решение своей, немного схожей, задачи.
RS485 и управление ногами уарта мне не подходит, у меня там ADUM1201 (гальваническая развязка).
ставить дополнительные корпуса, дороже и бессмысленно.
Диодная развязка корява, по терминам монтажное "И".
"И" на дискретной логике не нравится лишними проводами, корпусами, заранее ограниченным числом подключений.
Сейчас два блока АЦП работают по схеме UART <-> UART, точка - точка.
на основном блоке у микропроцессора(STM32F103RE) осталось два свободных UART.
драйвер RS485 в наличии, общение с компьютером по USB(CDC).
Работой прибора заказчик доволен.
В новом сделаю гирлянду, паровозик, вагончик, кольцо, нужное подчеркнуть.
Планируется возможность увеличения числа измерительных каналов.

Сообщение отредактировал e-serg - May 11 2011, 08:59

[iosifk]

В новом сделаю гирлянду, паровозик, вагончик, кольцо, нужное подчеркнуть.
Планируется возможность увеличения числа измерительных каналов.

Посмотрите интерфейс LIN...

[e-serg]

Посмотрите интерфейс LIN...

платы уже есть рабочие, бюджет пока небольшой.
как LIN, без дополнительных компонентов, взгромоздить на ADUM1201.
Сам виновник обсуждения не появляется.
PS. c LIN знаком, делал устройства.

[Xenia]

Нет интерфейса лучше, чем SPI! (С) Холивар

[MrYuran]

Нет интерфейса лучше, чем SPI! (С) Холивар

Есть! 1-Wire!
На один провод меньше и питание можно по тому же проводу гнать.

[defunct]

Есть! 1-Wire!
На один провод меньше и питание можно по тому же проводу гнать.

На 3 провода меньше если уж на то пошло. GND и там и там, в SPI еще есть CS.
Но и то и другое - гуано для соединения множества устройств в одну сеть. SPI это точка-точка в чистом виде, 1-wire - геморрой с времянками.

Плясать от простой общей шины надо (485, i2c, CAN), а всякие паровозики да колечки - от лукавого.

[_Pasha]

как LIN, без дополнительных компонентов, взгромоздить на ADUM1201.

Интересно, что побудило при выборе полудуплекса, использовать 1201 а не 1301 ?

[_Pasha]

Нет интерфейса лучше, чем SPI!

Это ж как он должен достать своей помехоустойчивостью, чтобы такое написать!

[haker_fox]

Плясать от простой общей шины надо (485, i2c, CAN), а всякие паровозики да колечки - от лукавого.

И чтобы аппаратная поддержка на борту была. А если уж совсем обнаглеть, то и аппаратное декодирование адреса, подсчет CRC...

Вообще такая же задача передо мной стоит. Пока склоняюсь к RS-485. На объекте есть прокинутая витая пара (одна) + возможно еще несколько проводков.

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

[kolobok0]

...можно ли элегантно на оптронах построить развязку...

с гальванической развязкой
adm2582e

дешевле - рассыпуха. питание генератор или самому качать через трансик. либо если ИБП - заводить с него.

удачи вам
(круглый)

[_Pasha]

PC817 на переключение рием/передача
H11L1 на все остальное.

[defunct]

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

Я бы не заморачивался с развязкой дифф сигнала дабы не портить характеристики сети. Куда проще развязать TTL сигнал между МК и драйвером. Еще проще - развязать питание устройства от общей линии питания и исключить землю с RS485 разъема. В __худшем__ случае (например монтажник перепутал 220В с 485-м)если нет супрессоров по входу 485-го сгорает только драйвер - проверено временем.

Драйверы пользую самые дешевые типа ADM485AR. Их ремонто-пригодность восхищает - при замыкании входов A/B на 220 горят очень аккуратно - плату не портят - просто образуется маленькая дырочка сверху на корпусе МС ) Сдул, надел новую и всё.

[haker_fox]

Спасибо, друзья! Учту все советы и пожелания!

[e-serg]

Интересно, что побудило при выборе полудуплекса, использовать 1201 а не 1301 ?

Тут кто то кого то путает, "haker_fox" топик стартер?
ADUM1201 выбрал для дуплекса , модули уже хорошо работают в одной задаче, и выбор был между 1201 и оптронами.
решил что с ADUM возможных проблем меньше, сейчас эти же модули для другой задачи приспособил.

[haker_fox]

Тут кто то кого то путает, "haker_fox" топик стартер?

Никакой путаницы haker_fox присоединился позже к беседе, больно уж она интересная оказалась) Внимательно читайте топик

[Sirko]

...а если драйвер все таки надо ставить - то тогда прямая дорога к RS-485.

+1

Интересно, что побудило при выборе полудуплекса, использовать 1201 а не 1301 ?

Если есть желание или необходимость использовать именно ADUM1201, то у maxim-а есть транссиверы с автоматическим переключением: приемник/передатчик, - например MAX13413

[Sirko]

Вот, для размышления, да и просто для "пополнения коллекции".

[гигипотамм]

...и вот еще...

[=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, поскольку он был одним из первых протоколов, который обеспечивал помехоустойчивость. А невежды, которые даже не понимают, о чем идет речь, конечно, могут стебаться над почтенным родоначальником промышленных интерфейсов и из кожи вон лезть, пытаясь объяснить его долгожительство.

[GetSmart]

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

[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.
Можете не отвечать. И простите, что на Вас наехал, просто на уровень эксперта Вы совсем не тянете, а от Вашей фразы:

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

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

[GetSmart]

Проснитесь! На дворе лето к концу идет.

Разве? У нас ещё середины не наступало. Вы с какой планеты?
Я не про Вас, кстати. У Вас всё стабильно постоянно, без обострений

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

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

Обострение серьёзней, чем предполагалось.

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

[zltigo]

Разве? У нас ещё середины не наступало. Вы с какой планеты?

Планета земля. Северное полушарие. Середина лета была 22 июня. Дело к осени, длительность дня сокращается.

[GetSmart]

Середина лета была 22 июня. Дело к осени, длительность дня сокращается.

Вы ведь знаете правильный ответ, но пытаетесь обмануть. 22 июня была максимальная длительность дня. Не лета, и не среднемесячной/недельной/... температуры. Времена года, в том числе и лето, сдвинуты относительно максимума дня ПО ТЕХНИЧЕСКИМ ПРИЧИНАМ Официально лето с 1 июня до 31 августа. Читайте первоисточники. Вы же любите/уважаете стандарт

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

[=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... Жесткие интервалы, которые вас, как программиста, так раздражают, как раз и обеспечивают его помехоустойчивость. Теперь будете знать.

[GetSmart]

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

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

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

[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]

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

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

[=AK=]

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

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

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

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

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

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

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

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

[Dog Pawlowa]

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

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

[sonycman]

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

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

[GetSmart]

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

Да да да. В представлении =AK= это может происходить только при взрыве атомной бомбы. Ну и соответственно определение помехоустойчивости в военное время будет совсем другим

[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 исключительной возможности подержать передатчик включенным перед началом фрейма). Так-что расслабьтесь - лично для Вашей персоны никто не тужится. Просто пресекаем дезинформацию.

[=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

[zltigo]

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

Однако, с резким падением пропускной способности канала в качестве "бонуса" за простоту . Кроме того, контроль доставки это не единственная работа отсутствующих 4x уровней. Естественно стека в котором были-бы реализованы а не только декларированы все 7 уровней я что-то на вскидку не припомню.

[=AK=]

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

Я приводил определение, что в данном контексте есть помехоустойчивость. Берем какой заблагорассудится помеховый сигнал (не белый шум, а самый что ни на есть гнусный, самый неприятный для исследуемого протокола) и наводим его на линию RS-485. В тот момент, когда связь пропадет, замеряем мощность наведенного помехового сигнала.

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

[aaarrr]

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

На специальной "гнусной" помехе, которая портит весь фрейм, ага. Можно еще провода вырвать - тогда помехоустойчивость в вашем понимании сравнится для всех протоколов. Не устали бредить?

[GetSmart]

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

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

[=AK=]

Требование протокола распространяется только на наличие silent interval.

Вот что написано про Modbus RTU в самом стандарте:



Промежуток между фреймами, действительно, разделен интервалами молчания длительностью 3.5T. Однако не о них речь, речь идет о самом фрейме, который состоит из стартовой паузы 3.5Т, Модбас сообщения и завершающей паузы 3.5Т.

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

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

про в 200 раз повышающий оставим на Вашей совести

Я объясню, откуда взялись цифры. Это будет полезно знать не только вам, но и другим начинающим.

Линия RS485 с двух сторон должна быть терминирована резисторами, равными волновому сопротивлению кабеля. Типично волновое сопротивление кабеля (витой пары) находится в диапазоне 100...150 Ом, наиболее часто встречается 120 Ом. Таким образом, два параллельно включенных терминирующих резистора имеют сопротивление 50...75 Ом.

Резисторы растяжки на линии RS485 обычно подвешиваются к земле и к питанию приемопередатчика RS485, т.е к +5В. Величина этих резисторов выбирается как компромисс между двумя противоречивыми требованиями. С одной стороны, чем меньше сопротивление резисторов растяжки, тем выше помехоустойчивость "висящей в воздухе" линии. Поскольку это именно тот уровень помехоустойчивости, который только и достижим с самопальными протоколами (а также в изделиях, где недотепы превратно понимают правильные протоколы), то, как правило, резисторы подтяжки стараются сделать как можно более низкоомными. С другой стороны, низкоомные резисторы подтяжки вносят неоднородность в линию, а также дополнительно нагружают передатчики, поэтому беспредельно их уменьшать нельзя. Чаще всего используют резисторы в диапазоне 470R...680R.

Замечу, что правильному протоколу для RS-485 вообще не нужны резисторы растяжки. Никакие. И это является хорошей проверкой "на вшивость" для протокола: убери резисторы растяжки или, еще лучше, загони через них в линию помеху от генератора - и тогда воочию увидишь, хорош ли протокол и правильно ли он реализован.

Итак, резисторы растяжки по 470R создадут на терминаторах 120R||120R смещение 300 мВ. Типичный RS485 приемник имеет входной гистерезис всего 50 мВ, а его дифф. порог срабатывания находится в диапазоне от +200мВ до -200мВ. Соответственно, не вдаваясь в ненужные мелочи, можно принять, что для получения ложного сигнала на входе приемника помехе достаточно преодолеть смещение в 300 мВ. Ток через резисторы растяжки равен 5 мА, напряжение 0.3В, а мощность помехи, которая их пересилит, соответственно, должна составить 1.5 мВт.

Когда в линии RS485 есть включенный передатчик, он обеспечивает на линии типично 2.5 В дифф напряжения. Выход драйвера обеспечивает ток не менее 60 мА. Таким образом, для преодоления включенного выхода помеха должна развить мощность 150 мВт. Учитывая, что ток короткого замыкания у драйвера существенно больше (порядка 150 мА), от помехи может потребоваться еще большая мощность.

Вот это и дает мне основания утверждать, что правильный (и правильно реализованный) протокол, такой как Modbus RTU, обеспечит в 100-200 раз большую помехоустойчивость, чем типичный самопал.

На специальной "гнусной" помехе, которая портит весь фрейм, ага.

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

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

Вы не понимаете. Никакая помеха, наведенная на свободную линию перед началом фрейма (т.е. до того, как будет включен передатчик) в Modbus RTU и не способна вызвать потерю фрейма. В течении стартового интервала фрейма, который длится 3.5Т, все помехи, наведенные ранее, будут отброшены приемниками. К началу прихода сообщения все UARTs будут готовы к приему, приемные буфера пусты. Фрейм будет принят без искажений.

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

Правда, Modbus ASCII можно легко улучшить, сделать помехоустойчивым. Для этого достаточно, например, чтобы в начале фрейма передатчик выдавал символ ":" не один раз, а дважды. Первый символ может быть испорчен помехой, однако второй - очистит буфера приемников и весь фрейм будет принят правильно. Такой улучшенный вариант Modbus ASCII дает пример помехоустойчивого интерфейса, которому не нужны тайм-ауты. Учитесь, GetSmart, авось и правда поумнеете.

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

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

Простое решение получается при помощи байт-стаффинга. Выделяем, например, два символа специального назначения. Один называем "START", второй - "ESC". Если во входном потоке встречается "START", то все приемники обязаны выбросить текущий фрейм и очистить буфера приема. Если в потоке встречается "ESC", то следующий за ним символ интерпретируется особым образом, как команда. Команды могут быть такие:
- добавить в приемный буфер символ, код которого соответствует символу "START"
- добавить в приемный буфер символ, код которого соответствует символу "ESC"
- завершить прием фрейма
Понятное дело, что в том случае, когда в передаваемом пакете есть много символов "START" или "ESC", то передаваемое сообщение будет раздуваться, достигая в пределе (в наихудшем случае) примерно удвоенной исходной длины.

Несколько более трудное в реализации решение получается если использовать, например, кодирование 6b8b, зато сообщение раздуется всего на четверть, а заодно обеспечивается проверка на четность для каждого байта.

[Dog Pawlowa]

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

"Некоторые вопросы реализации интерфейса служат почвой для холивара у эмбеддеров." http://eewiki.ru/wiki/RS-485

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

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

Остановитесь, дружище! В пылу полемики наговорите фигни, потом будет неловко. Если первый символ ':' (код 0x3A ) искажен, то ничто не помешает исказиться и второму символу, они же передаются со стандартным стопом.

[=AK=]

Остановитесь, дружище! В пылу полемики наговорите фигни, потом будет неловко. Если первый символ ':' (код 0x3A ) искажен, то ничто не помешает исказиться и второму символу, они же передаются со стандартным стопом.

Вы правы, совсем запамятовал. Когда в начале фрейма передаются два старт-байта, то для того, чтобы гарантировать, что второй стартовый символ не будет искажен, желательно, чтобы MSB биты символа "старт", которые передаются последними, были равны единице. В своих протоколах в качестве "старта" я использую символ 0xF0. Четырех бит-интервалов достаточно, чтобы успеть обработать искалеченный символ (если он искалечен) и приготовиться к приему нового.

Спросите, почему именно 0xF0, а не 0xFF? Потому что 0xF0 самый подходящий для этого из всех символов кодовой таблицы 6b8b

А для "улучшенного Modbus ASCII", конечно, лучше сначала передать 0xFF, а потом 0x3A.

"Некоторые вопросы реализации интерфейса служат почвой для холивара у эмбеддеров."

RS-485 в некотором смысле является "детской песочницей". Он сильно напоминает радиоканал, но гораздо проще в реализации.

[aaarrr]

Условие "худшего из возможных" воздействий - вполне правомерное для серьезных изделий.

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

А радиолюбительские поделки вообще испытывать не требуется, так что - расслабьтесь, очевидно, сказанное к вам не относится.

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

[zltigo]

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

В документе нет ни слова передатчик ни тем более фазы его включения. Все это отдано на реализацию протокола. И мне уже честно совсем надоело говорить, что включение передатчика может быть реализовано для любого пртокола. Это никак не заслуга Modbus.

А неправильный вариант, который отстаивают местные воинствующие невежды

Это кто? Я здесь не встретил пока ни одного кто-бы протестовал против пришпиливанию к протоколу Modbus такого костыля. Хуже не будет.

Я объясню, откуда взялись цифры. Это будет полезно знать не только вам, но и другим начинающим.

Это даже не от фонаря

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

Вы даже НЕ читаете или не хотите читать, что речь идет не о времени до включения столь полюбившегося Вам передатчика, а исключительно после. С задоооолго до нет пробоем ни у кого.

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

Совсем ума нет у человека. Вроде уже все повторил и про то, что передатчик можно включать на всех протоколах и то, что "опасные" интервалы у RTU больше. Не помогает. если вместо ума только одна мысль, что если включить передатчик мастера на время slient, то это из дерьма сделает конфетку. Ну нечего мне более сказать.

Правда, Modbus ASCII можно легко улучшить, сделать помехоустойчивым. Для этого достаточно, например, чтобы в начале фрейма передатчик выдавал символ ":" не один раз, а дважды. Первый символ может быть испорчен помехой, однако второй - очистит буфера приемников и весь фрейм будет принят правильно. Такой улучшенный вариант Modbus ASCII дает пример помехоустойчивого интерфейса, которому не нужны тайм-ауты. Учитесь, GetSmart, авось и правда поумнеете.

Ну точно одна извилина в голове . Хотите улучшать - "улучшайте" так-же как "улучшаете" RTU - включите Ваш любимый передатчик -за один символ до. Может не маяться с таймерами и передать каокой-нибудь space символ. Но передавать ложное начало фрейма верх идиотизма.

Пример "улучшенного Modbus ASCII" дает общую идею...

Наш "эксперт" познал идею SLIP протокола и теперь несет ее в массы. Ура!

Несколько более трудное в реализации решение получается если использовать, например, кодирование

Ура! А это рождено знакомством "эксперта" c UUE и подобными.


Главное оказалось, что есть и БЫЛИ УЖЕ ДО Modbus RTU вменяемые протоколы.

[GetSmart]

Кажется я всё понял. =AK= изобретатель.
До знакомства с Modbus он успел изобрести 100 дерьмовых протоколов и при знакомстве осознал, что это всё было такое дерьмо, которое Modbus-у и в подмётки не годится. Другого объяснения, с учётом последних изобретений в этой ветке, пока не видно.


А вообще, модбас тут совсем ни при чём. Паузу после захвата шины 485 не будет делать только дерьмовый протокол. Это к модбасу отношения не имеет. Это связано с самим 485-ым. Это же элементарно, Ватсон!

Кроме того, в модбасе, когда мастер отослал фрейм слейву, мастер переключается на приём и ждёт ответа. При этом линия 485 уходит в болтающееся состояние. Слейв может довольно долго думать (100 и более мс) перед тем, как захватит шину и начнёт передавать данные. Именно в это время любимые =AK= и слабые помехи могут создавать глюки на приёме у мастера. Modbus RTU никак не способен отличить глюки от начала фрейма от слейва. =AK= нервно курит в сторонке

Сообщение отредактировал GetSmart - Jul 12 2011, 13:32

[=AK=]

В дебильнейшем даже с этой точки оценки Modbus RTU помеха в 1+1,5 символьном интервале перед началом фрейма вызывает облом со всем фреймом.

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

В документе нет ни слова передатчик ни тем более фазы его включения. Все это отдано на реализацию протокола. И мне уже честно совсем надоело говорить, что включение передатчика может быть реализовано для любого пртокола. Это никак не заслуга Modbus.

Может быть реализовано, а может и не быть реализовано. На практике в самопальных протоколах часто не реализуется. Modbus RTU - известный популярный протокол, который эту правильную реализацию явственно требует, поэтому я на него сослался.

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

Может не маяться с таймерами и передать каокой-нибудь space символ.

"Какой-нибудь" не годится, мы это с ув. Dog Pawlowa обсудили, а до вас опять не дошло

Но передавать ложное начало фрейма верх идиотизма.

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

Кроме того, в модбасе, когда мастер отослал фрейм слейву, мастер переключается на приём и ждёт ответа. При этом линия 485 уходит в болтающееся состояние. Слейв может довольно долго думать (100 и более мс) перед тем, как захватит шину и начнёт передавать данные. Именно в это время любимые =AK= и слабые помехи могут создавать глюки на приёме у мастера. Modbus RTU никак не способен отличить глюки от начала фрейма от слейва.

Modbus RTU в этой части не делает отличий между мастером и слейвами. Все узлы передают фреймы одинаково, соответственно, помехоустойчивость одинакова при передаче в любом направлении. Независимо от того, кто является передатчком, он обязан выдержать стартовый интервал 3.5T в начале фрейма, в результате чего фрейм будет принят правильно.

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

[GetSmart]

Modbus RTU в этой части не делает отличий между мастером и слейвами. Все узлы передают фреймы одинаково, соответственно, помехоустойчивость одинакова при передаче в любом направлении. Независимо от того, кто является передатчком, он обязан выдержать стартовый интервал 3.5T в начале фрейма, в результате чего фрейм будет принят правильно.

Гы
Сказали уже, что управление и захват шины идёт на уровне 485, а не модбаса. Другое дело, что слейв может долго думать, от этого в модбасе никакой "защиты" нет.

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

У меня сотни приборов идеально работают и на 485 и на 232 и на 3.3 TTL через модбас. Ешьте чей-то ещё моск своими открытиями

[=AK=]

У меня сотни приборов идеально работают и на 485 и на 232 и на 3.3 TTL через модбас.

В сочетании с вашей фразой "Modbus RTU никак не способен отличить глюки от начала фрейма от слейва" звучит очень хорошо. "Это пять!" (с)

На столе в лаборатории - почему бы им не работать-то.

[zltigo]

"Какой-нибудь" не годится, вы это с ув. Dog Pawlowa обсудили, а до вас опять не дошло

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

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

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

[Dog Pawlowa]

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

А для "улучшенного Modbus ASCII", конечно, лучше сначала передать 0xFF...

Предлагаю остановиться.
Или есть возражения?

[haker_fox]

Гопода, не проще ли сделать адекватный физический уровень, и не исправлять его огрехи на более высоких уровнях?

[GetSmart]

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

[ViKo]

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

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

[zltigo]

Кроме того, что может сравняться с 485-ым по стоимость/скорость/надёжность?

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

[GetSmart]

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

И что 422 дешевле? надёжней?

А CAN, что, пробъёт километры?
--------

По поводу Солнца. У меня есть (давно уже было) предложение сделать 22 декабря началом года, то бишь новым годом. Тогда самый длинный день будет 1 июля, а лето слегка, на 8 дней сдвинется назад и разумеется останется с 1 июня по 31 августа по новому. При этом всё равно середина лета будет смещена на пол месяца относительно самого длинного дня, по техническим причинам, как и должно быть.
Не знаю, куда/к кому обращаться

Сообщение отредактировал GetSmart - Jul 14 2011, 18:17

[zltigo]

И что 422 дешевле? надёжней?

Дуплекс, значит 'быстрее'(производительнее) и 'надежнее'

А CAN, что, пробъёт километры?

Имеет варианты исполнения или переключение длительности фронтов. Доминантное состояние.

[GetSmart]

Дуплекс, значит 'быстрее'(производительнее) и 'надежнее'

Щас. 4 провода. Так можно два 485-ых сделать. Тоже дуплекс.

[Dog Pawlowa]

Так можно два 485-ых сделать. Тоже дуплекс.

Витиевато
Два 485 - это не дуплекс.

[zltigo]

Щас. 4 провода.

С тех пор, как Ethernet стал ширпотребом и 8 не особая проблема.

Так можно два 485-ых сделать. Тоже дуплекс.

Бестолку, из-за отсутствия доминантного состояния никакого толку использовать два 485 вместо 422 нет.

[=AK=]

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

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

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

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

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

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

[Dog Pawlowa]

из-за отсутствия доминантного состояния никакого толку

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

[zltigo]

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

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

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

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

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

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

[=AK=]

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

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

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

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

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

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

[MrYuran]

Дуплекс, значит 'быстрее'(производительнее) и 'надежнее'

Не говоря о том, что уровни 12В, то есть ещё надёжнее

[ViKo]

Не говоря о том, что уровни 12В, то есть ещё надёжнее

... чем дифференциальные сигналы RS485-го? Вопрос спорный.

[MrYuran]

... чем дифференциальные сигналы RS485-го?

Там тоже дифференциальные.

[ViKo]

Там тоже дифференциальные.

Да, я не знал. Извиняюсь.
Да это просто монстр какой-то!
Вот тут статью нашел, не пройдите мимо.
http://www.google.by/url?q=http://www.bb-e.../485appnote.pdf

[=AK=]

Не говоря о том, что уровни 12В, то есть ещё надёжнее

В RS422 такие же уровни сигналов, как в RS485. Разница в том, что приемники RS422 имеют меньшее входное сопротивление, а передатчики способны выдать меньше тока, поскольку им надо тянуть не два терминирующих резистора, а всего один. Приемники и передатчики RS485 с успехом работают в качестве улучшенных приемников и передатчиков RS422

А сигналы 12В - это в RS232. Который, несмотря на это, отнюдь не более надежен, чем RS422, а наоборот.

[MrYuran]

В RS422 такие же уровни сигналов, как в RS485.

Странно, а я почему-то думал, что побольше. Даже как-то был уверен...

[=AK=]

Странно, а я почему-то думал, что побольше. Даже как-то был уверен...

Вот классический RS-422 передатчик - 26LS31. Нетрудно убедиться, что он обеспечивает те же уровни сигналов, что RS-485 (что, собственно, следовало ждать, раз уж у него такое же напряжение питания, 5В) , но его выход слабее. Характеристики приемника RS-422 можете посмотреть на примере 26LS32.

[Maverick]

В сочетании с вашей фразой "Modbus RTU никак не способен отличить глюки от начала фрейма от слейва" звучит очень хорошо. "Это пять!" (с)

На столе в лаборатории - почему бы им не работать-то.

почитайте это

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

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

Пожалуйста приведите пример или более подробнее расскажите.

[zltigo]

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

Только для тех, кто даже не отличает дуплекс от симплекса.

Проводной CAN передатчик представляет собой разновидность "открытого коллекторного выхода".

Хорошо быть дураком - решил, что "открытого коллекторного выхода" и все опять стало простым и понятным.

Пожалуйста приведите пример или более подробнее расскажите.

Что подробнее? Как синхронизироваться из потока идущего, например от CC1000? Так все уже вроде расписал, Именно так и делается. Ну кроме того, что при необходимости после получения устойчивого битового потока (порядка 40 mark/space битов) могут выполняться дополнительные телодвижения, например для того-же CC1000 фиксация коэффициентов фильтрации, раз уж битовая синхронизация есть.

[=AK=]

Только для тех, кто даже не отличает дуплекс от симплекса.
Хорошо быть дураком - решил, что "открытого коллекторного выхода" и все опять стало простым и понятным.

Сильная аргументация. Явный признак глубоких знаний

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

[Maverick]

Только для тех, кто даже не отличает дуплекс от симплекса.

Хорошо быть дураком - решил, что "открытого коллекторного выхода" и все опять стало простым и понятным.

Что подробнее? Как синхронизироваться из потока идущего, например от CC1000? Так все уже вроде расписал, Именно так и делается. Ну кроме того, что при необходимости после получения устойчивого битового потока (порядка 40 mark/space битов) могут выполняться дополнительные телодвижения, например для того-же CC1000 фиксация коэффициентов фильтрации, раз уж битовая синхронизация есть.

пример протокола или картинку типа такой приведите для наглядности
Что такое CC1000?

Заранее спасибо!

[zltigo]

пример протокола или картинку типа такой приведите для наглядности

В данном случае речь идет только о преамбуле до маркера фрейма. То, что используется вместо "включили передатчик на 3,5 символа". Картинку для наглядности и раздумий можете нарисовать сами.

Что такое CC1000?

Пачка ссылок в Google начиная с первой http://focus.ti.com/docs/prod/folders/print/cc1000.html