Этот волшебный "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 можно пробовать восстанавливать битую информацию. Вот такой вот странный протокол с "крайне низкой помехоустойчивостью". Нет, наверное все-таки не протокол странный, а "эксперт" очень странный .

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


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

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

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



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

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


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

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

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

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

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

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

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

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




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

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

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

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


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



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

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

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

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

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

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

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

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

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

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

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

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

Нажмите для просмотра прикрепленного файла

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

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

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

Нажмите для просмотра прикрепленного файла


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

Линия 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 раз большую помехоустойчивость, чем типичный самопал.


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


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

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

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


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

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

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

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




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

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

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

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


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

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


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

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

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

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

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

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

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

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

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


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

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


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

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

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


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

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



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


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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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