|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Kirill Frolov 2:5020/400 08 Jul 2005 14:04:38
To : Zahar Kiselev
Subject : COM-порт: читать man до просветления -- помогает.
--------------------------------------------------------------------------------
Tue Jun 28 2005 23:40, Zahar Kiselev wrote to All:
ZK> Для связи со всякими железками часто применяется "усеченный" вариант
ZK> ком-порта из трех проводов - передача, прием и общий. В досе многие
ZK> терминальные программы умели не обращать внимания на висящие в воздухе
ZK> сигналы квитирования. Hапример так умел работать TELIX.
ZK> А вот в линуксе все время приходится паять перемычки на разъем порта
ZK> чтобы установить сигналы DTR/DSR и CTS/RTS в правильное положение. Иначе
ZK> линуксовый драйвер ком-порта вообще не хочет принимать данные. Даже если
ZK> работающему с ним minicom`у сказать hardware flow conrtol no. Вопрос -
ZK> это недоработка авторов Миникома или особенность линуксового драйвера
ZK> порта? Ведь cat /dev/ttyS0 тоже хочет правильно установленных сигналов.
ZK> Можно ли драйверу порта как-то объяснить, что этих сигналов квитировани
ZK> нет? man stty смотрел, способа не нашел.
Зато я разобрался. Ситуациая примерно похожая. Есть один аппарат и у него
аппаратно DTR соединён с DSR и DCD, а RTS с CTS. Всё работает. Есть другой
аппарат, где ничего не соединено и, соответственно не работает. Миникомом
я не пользуюсь...
Для начала нужно иметь statserial, stty и cu. В новом (sarge) дебиане
всё это есть в виде отдельных пакетов. statserial можно просто запустить
в отдельном xterm как монитор порта. После чего можно воткнуть кабель в
аппарат с которым всё работает, а потом разъединить. statserial свалился с
SIGHUP? Так и должно быть. Делается stty -F /dev/ttySx clocal. Эксперимент
повторяется и видим, что statserial не вываливается. Теперь запускаем cu.
Опять вывалился statserial? Смотрим stty -F /dev/ttySx -a | grep clocal
и видим, что "-clocal", что означает *отключение* локального режима. Вывод
напрашивается сам собой -- cu изменяет настройки порта! Теперь вначале
запускаем cu (если он ещё не вывалился с воплями I/O error) и только подом
делаем stty -F /dev/ttySx clocal. Соединяем-разъединяем кабель -- ошибок
нет. Теперь можно в cu работать.
Что касается RTS-CTS -- ситуация абсолютно аналогичная... Вдумчивое
чтение man stty поможет заставить порт принимать данные:
stty -F /dev/ttySx -crtscts ixon -ixoff -- это мой случай, реально работает
(XON/XOFF, 115200, 8N1, CTS|DSR|DCD -- нет).
Hо не надо забывать, что вызываемые программы *могут изменять* настройки
порта, а изменив ещё и не восстанавливать, или наоборот восстанавливать --
вот в чём всё дело и откуда казалось бы неуловимые глюки. Когда,
например, линуховый драйвер глотает куда-то половину вводимых (из аппарата)
символов в tcl-скрипте и вызывает I/O errors вперемешку с SIGHUP у cu.
Действительно, последовательная связь -- сложное дело...
Кстати, на счёт более вменяемой чем cu "терминалки" (не вступает в
конфликт с stty):
#!/usr/bin/expect -f
set fd [open {/dev/ttyS5} {RDWR}]
spawn -open $fd
interact {
!! {exit 0}
}
Hеобходимые фичи прикрутишь сам... (это *очень* просто)
--- ifmail v.2.15dev5.3
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
