[haker_fox 60]

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

[GetSmart 0]

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

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

[ViKo 1]

Первоисточник - календарь. Документ, между прочим.

А когда по Солнцу Новый год? Тоже отмечаете по Солнцу

Извиняюсь, по теме сказать мне нечего. Прочитал с интересом, но не нашел конкретной информации "как сделать хорошо". :bb-offtopic:

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

[zltigo 1]

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

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

[GetSmart 0]

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

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

 

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

--------

 

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

Не знаю, куда/к кому обращаться :)

Изменено 14 июля, 2011 пользователем GetSmart

[zltigo 1]

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

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

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

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

 

[GetSmart 0]

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

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

[DogPawlowa 0]

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

Витиевато ;)

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

[zltigo 1]

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

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

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

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

 

[=AK= 12]

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

 

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

 

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

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

 

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

 

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

[DogPawlowa 0]

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

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

[zltigo 1]

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

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

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

....

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

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

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

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

[=AK= 12]

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

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

 

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

 

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

 

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

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

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

[MrYuran 18]

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

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

[ViKo 1]

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

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