Yurasvs (25.04.2024 16:55, просмотров: 140) ответил Adept на ХитрО. Получается, что 1 принимается, а "0" как бы нет (драйвер его и
режиме передачи формирует на выходе). Но такое ежебитное
переключение чревато пропусками на высоких скоростях. Не, конечно,
если какие-нить жалкие 9600 (и даже может 115200, может и
проканает, но на мегабитных я б так делать не рискнул. Буду в
скорости копаться с новыми мегами, посмотрю логику работы ноги XDIR
(не повторяет ли оно вышеописанное?)-
- потому что любой RC - инерционен по своей природе "реактивности".
при интенсивном диалоговом датаобмене с переключением направлений,
да ещё пакетами разной длины... Ну его нахрен такое решение. к тому
же время переключения у драйвера тоже ненулевое. Если при пакетном
обменен всё детерминировано, то при побитовом переключении всё
становится на порядок-два нестабильнее, особенно на высоких
скоростях... А если, как заметили выше, - несогласованная линия,
переотражения?? - Adept(25.04.2024 17:28)
- Какое побитовое переключение? Первый же передаваемый старт бит
включает передатчик, и он остается включенным до конца передачи
всего пакета из любого количества байт. Как только последний байт
передан, RC цепочка удерживает состояние передачи еще небольшое
время ( это время нужно для того, чтобы исключить ложное выключение
передатчика, если какой-то из передаваемых байт вдруг будет
состоять из одних единиц.). Как только защитный таймаут прошел,
передатчик освобождает линию Yurasvs(23 знак., 25.04.2024 19:06)
- первый бит априори имеет сильно бОбльшие шансы быть потерянным
(даже при несимметричной тау, с диодом) Последний наоборот -
тормозит переключение, когда его по факту уже можно делать (если
пакет передан, нужен страховочный временной интервал) Всё это ещё
температурозависимое. Работать конечно будет, и в некоторых случаях
весьма неплохо, но честно, - не люблю такие решения. Мне как-то
ближе "железобетонные" включил-выключил, когда тебе надо, а не
когда RC решит. Adept(745 знак., 25.04.2024 19:49)
- Такое не предназначено для сетей с большим количеством устройств.
Но неплохо подходит, если надо вынести далеко от основного
устройства умную панель управления, а на процессоре свободных ног
или каналов гальванразвязки для сигнала DE не хватает. Тогда ставим
RC цепочку с диодом на стороне устройства, а панель программируем
так, чтобы она начинала отвечать не сразу, как примет пакет, а с
задержкой на пару байт, чтобы передатчик основного устройства успел
освободить линию Yurasvs(116 знак., 25.04.2024 20:25)
- понятно. Классические костыли. Ну его нахрен. - Adept(25.04.2024 20:40)
- Такое не предназначено для сетей с большим количеством устройств.
Но неплохо подходит, если надо вынести далеко от основного
устройства умную панель управления, а на процессоре свободных ног
или каналов гальванразвязки для сигнала DE не хватает. Тогда ставим
RC цепочку с диодом на стороне устройства, а панель программируем
так, чтобы она начинала отвечать не сразу, как примет пакет, а с
задержкой на пару байт, чтобы передатчик основного устройства успел
освободить линию Yurasvs(116 знак., 25.04.2024 20:25)
- первый бит априори имеет сильно бОбльшие шансы быть потерянным
(даже при несимметричной тау, с диодом) Последний наоборот -
тормозит переключение, когда его по факту уже можно делать (если
пакет передан, нужен страховочный временной интервал) Всё это ещё
температурозависимое. Работать конечно будет, и в некоторых случаях
весьма неплохо, но честно, - не люблю такие решения. Мне как-то
ближе "железобетонные" включил-выключил, когда тебе надо, а не
когда RC решит. Adept(745 знак., 25.04.2024 19:49)
- Какое побитовое переключение? Первый же передаваемый старт бит
включает передатчик, и он остается включенным до конца передачи
всего пакета из любого количества байт. Как только последний байт
передан, RC цепочка удерживает состояние передачи еще небольшое
время ( это время нужно для того, чтобы исключить ложное выключение
передатчика, если какой-то из передаваемых байт вдруг будет
состоять из одних единиц.). Как только защитный таймаут прошел,
передатчик освобождает линию Yurasvs(23 знак., 25.04.2024 19:06)
- потому что любой RC - инерционен по своей природе "реактивности".
при интенсивном диалоговом датаобмене с переключением направлений,
да ещё пакетами разной длины... Ну его нахрен такое решение. к тому
же время переключения у драйвера тоже ненулевое. Если при пакетном
обменен всё детерминировано, то при побитовом переключении всё
становится на порядок-два нестабильнее, особенно на высоких
скоростях... А если, как заметили выше, - несогласованная линия,
переотражения?? - Adept(25.04.2024 17:28)