перевожу на русский:
RS-485 имеет неопределенное состояние в случае, когда никто не передает. То есть состояние линии может быть любое и меняться с любой скоростью.
=AK= использует протоколы, которые чувствительны к этому, то есть они не имеют эффективной защиты от этого "горя".
Некоторые (условно назовем их "остальные") использует протоколы, которым все равно что происходит на линии в то время, когда данные по ней не передаются. Как результат- эти некоторые (и разработанные ими устройства) не видят разницу между "линией, в которой есть неопределенность при отсутствии передачи" и "линией состояние которой между передачами детерменировано"
Еще более некоторые (назовем их "гурманы"), предпочитают, чтобы их драйвер RS-485 не выдавал ложных переходов в микроконтроллер если линия в неопределенном состоянии. Они действуют двумя способами:
1) применяют драйверы RS-485, которые при неподключенной линии выдают неактивный уровень в RX, например SN75LBC184
2) применяют резисторы, "растягивающие" линию из неопределенного состояния в определенное.
3) применяют (1) + (2) вместе.

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

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

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


Выше я в общих чертах описал два существующих подхода к построению правильного протокола для RS-485. Других нет, так что "остальные" со своими растопыренными пальцами могут покурить в сторонке.


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

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


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

Upd: Хм. перечитал себя. При некотором извращизме (ну, как минимум один так уже прочитал) действительно можно подумать, что я ратую заменить соответствующий среде передачи протокол на подтяжки. Никогда! Для меня наличие нормального протокола настолько очевидно, что я как-то и не подумал, что могут найтись люди, которые этого не понимают.
Пора начинать писать "комментарии" к себе, уж больно витиевато я выражаюсь.

- а что не так с 485? -
- Объяснил первый раз
- И че делать? CAN?
- Ответил
- Изначально я спрашивал, что если не RS-485? - соврал; возможно это тролль?
- Обьяснил второй раз.
- какая связь между "резисторами подтяжки, помехоустойчивостью" и правильным протоколом? В чем разница между RS-485 и RS-422? На физическом уровне. Почему для RS-485 подтяжки надо, а для RS-422 Не надо?
- Обьяснил третий раз.
- Понятно. Спасибо. То бишь RS-422 самый стойкий к помехам? А CAN bus? - вроде бы дошло, но не совсем
- Ответил
- И при чем тут "правильный протокол"? - опять двадцать пять; oбщее поведение соответствует поведению тролля.
- Обьяснил еще раз, однако отметил нарочитую тупость.
- Не хамить воспитание не позволяет? - ну точно, тролль, вишь как обрадовался кормежке
- совок он и есть совок, хоть куда переедь, из души не вытравить. - однозначно тролль, жирный и нахрапистый


Это не является достаточным условием для помехоустойчивого протокола. Вполне обеспечивается, например, хорошим CRC. Однако никакой гарантии от глюкавости в условиях сильных помех не дает. Сообщение просто никогда не дойдет до адресата. Так что все-таки "остальные" пусть постоят тихонечко где-то в сторонке, они, действительно, даже до "гурманов" не дотягивают.

Хотел бы уточнить насчёт CAN. Да, физический уровень не фонтан (не Push-Pull, но как-то же надо разрешать коллизии), на большие расстояния не годится. Но вот на счёт плохого протокола поясните пожалуйста. Разве у CAN не жёстко задан протокол приёма с тишиной до и после пакета, подтверждением приёма, CRC, бит-стаффингом? Мне кажется стоило бы разделять тёплое и мягкое, т.е. аппаратные и программные меры, а сравнение может быть только в конкретной ситуации.

Но может всё-таки не понимает?


Если Вы нашли какое-то противоречие в словах, то лучше его указать. Вон как =АК= успешно отбивается, он несомненно объяснит.
А так получилась общая фраза. Разумеется Вы правы, в случае с CAN меньше места для творчества, но "всегда есть место подвигу".
Например, при распределении идентификаторов использовать нули там, где есть избыток битов. По идее это повысит надежность связи.

Так и указал. Более слабая физика RS485 (из-за отключения передачика) + хороший протокол вкупе дают хороший результат сравнимый с RS422, а вот CAN с ещё более слабой физикой но с на порядок более надёжным протоколом (уже готовым, причём) почему то сравнили с аутсайдером обсуждения - RS485 + плохой протокол, без вариантов.

Я говорил, что CAN, в силу своего слабоватого физического уровня, по помехоустойчивости не может тягаться с RS-485 c качественным протоколом. Его помехоустойчивость сравнима с помехоустойчивостью интерфейса на базе RS-485, где есть резисторы растяжки, но используется плохой протокол. "Жесткость" протокола, использование CRC и т.п. отнюдь не делают протокол автоматически "хорошим", а плохой физический уровень погубит любой протокол, как бы он ни был хорош.

Когда-то давным-давно я лично наблюдал за мытарствами неких изобретателей самопальных протоколов, которые свято верили в силу резисторов растяжки на RS-485. Программист незнамо зачем (сам он не мог объяснить своих мотивов) переводил трансивер в 3-е состояние после каждого переданного байта, то есть, делал нечто напоминающее физический уровень CAN. На объекте система дико и регулярно глючила, надолго теряя связь, что по условиям задачи было недопустимо. Туда в командировку несколько раз посылали электронщика. Его действия сводились к уменьшению сопротивления резисторов растяжки и замене кабелей на все более дорогие экранированные витые пары. Частота глюков немного снижалась, однако оставалась заметной, система работала ненадежно.

В случае CAN тишина до и после пакета позволяет уменьшить количество коллизий, однако никак не спасает от помех.

Господа! Воздержитесь от наездов! Не хватает терпения объяснять спокойно - никто не принуждает участвовать. Тему частично почистил.


Один вопрос дилетанта: как приёмники знают, что данные сейчас не передаются?

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

Буржуи в курсе, поэтому ничего "жизненно-критического" на него не возлагают и за панацею не держат. Для fly-by-wire используют более надежный MIL-SDT-1553 и иже с ним. Для drive-by-wire предназначены flex-ray и TTP, и т.п. Для таких ответственных применений CAN не прокатывает. Вот домашнюю автоматику на нем собрать - самое оно, для этого почти чего угодно сойдет.

Это смотря в каких попугаях считать надежность. Если в попугаях достоверности контрольной суммы - да, CAN более надежен, чем какой-нибудь самопал на RS485.
Если в вероятности безошибочной доставки сообщения одинаковой длины в одинаковых условиях помех - тут уж извините, я согласен с =AK=.

а какже самый надежный RS-422?

CAN - сетевой интерфейс. Надо рассматривать его надежность, дальнобойность и скорострельность в контексте сети.
Насколько жизнеспособна сеть с CAN, насколько CAN загружает узлы, как быстро сеть восстанавливается после нарушения физической целостности.
RS485 оcтается где-то жить только из-за MODBUS. Но cам MODBUS морально устаревший протокол. Нигде в нем каких-то особых средств поддержания жизнеспособности сети нет.

В условиях тяжелейших помех, отказа узлов , наличии приоритетных критических задач и сообщений CAN явный лидер.
Имею опыт применения CAN и на военных полигонах протяженностью в километры и в управлении локальными устройствами и в лифтах.
С успехом конкурировал и вытеснял решения предлагавшие RS485.
"Хороший" протокол на RS485 это такой "неуловимый Джо". А в реале съедает все силы разработчиков.

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