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

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

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

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

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

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

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

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

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

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

Щас. 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-го? Вопрос спорный.