|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 12 Oct 2005 16:43:36
To : Alexey Wasilyev
Subject : ноутбучный экран
--------------------------------------------------------------------------------
Oct 12 12:33 05, Alexey Wasilyev wrote to Zahar Kiselev:
ZK>> случаев. Так что _сегодня_ с появлением PL2303 и его поддержки в ядре
ZK>> проблема компортов уже не особенно актуальна.
AW> Я тоже так думал.
AW> Есть некое количество пром.писюков на pc/104, которые рулятся своей
AW> хитрой терминалкой (tvterm) через ком-порт. Через com1/com2 все ок.
А чем, собственно, хитрая эта терминалка?
AW> Через пяток разных поделок на pl2303 и аналогичных - хрен. То часть
AW> символов теряется, то строчки съезжают, то еще какие траблы. В общем
AW> нормально не работает.
Был бы я поближе к тебе(а ты где кстати, что не в Питере - я понял:) -
я бы попытался помочь тебе решить проблему.
У меня для этого есть специальный аппаратный инструмент - машина (первый пень) с
гарантированной не кривыми двумя ком-портами и голым досом на ней.
Также специальный кабель и программа под дос более чем десятилетней давности.
Выполняет эта конструкция функцию логического анализатора. Включается _между_
управляемым устройством и тем компом с которого управляют. В данном случае
придется включить между pl2303 и твоими pc104. Экзотический досовый софт
заниматеся тем, что слушает все сигналы на портах и транслирует их с одного на
другой. И одновременно - показывает происходящее на экране и пишет лог.
В твоем случае скорее всего(даже я в этом почти уверен) имеет место
неработоспособность управления потоком между pl2303 и промышленной железкой.
В первую очередь надо проверить прохождение всех сигналов от ног микросхемы до
промышленной железки. Убедиться что они все есть и не перепутаны. Кабель-то
может оказаться и прямой и перекрестный("нульмодемный"). Причем для модемов
обычно применяется "прямая" разводка управляющих сигналов, а для соединения
компов - "перекрестная". Что окажется в промышленной железке - хрен ее знает!
TXD/RXD понятно что не перепутают, а вот как подключены cts/rts и dtr/dsr -
только изготовителям ведомо. Кроме того - сама микросхема pl2303 использует
_инверсную_ логику сигналов на своих ногах, причем уровни напряжения не
совпадают со стандартным rs232. Следовательно если на промышленной железке
стандартный порт(а не то что на мобильниках), то в кабеле кроме собственно
pl2303 должен быть еще какой-нибудь из аналогов ADM232 - преобразователь
уровней. Поэтому простая "прозвонка" кабеля от ног pl2303 до разъема компорта
невозможна. Рекомендуется осциллограф, хотя при некоторой сноровке можно и
цифровым тестером обойтись.
Далее, убедившись в работоспособности _физического_ уровня переходим к
_логическому_. Читая документацию, убеждаемся что оборудование может быть "DTE"
или "DCE", а на практике еще встречаются разные гибриды:). Отличия - в логике
включения/выключения сигналов управления потоком. Обычно наличие сигналов
dtr/dsr означает сам факт включенного состояния устройства и его желания
общаться через ком-порт. А cts/rts используются в качестве "регулятора
интенсивности" общения когда оно уже происходит. У компа есть сигнал RTS - его
временный переход в ноль означает
команду устройству "подожди, я не успеваю". Включение/выключение этого сигнала
во-первых должно выполняться терминальной программой, а во-вторых сам сигнал от
"виртуального" порта /dev/ttyUSB0 должен дойти сначала в виде команды по
интерфейсу usb до pl2303, а потом от соответствующей ноги микросхемы до входа
cts на промышленной железке. И железка должна быть настроена заранее так, чтобы
не игнорировать изменения этого сигнала, а действительно приостанавливать
передачу. Аналогичные рассуждения справедливы и для выходного сигнала
устройства, которым оно может просить комп "немного подождать" пока переваривает
очередную порцию данных. Как выяснилось в процессе моих экспериментов с кабелем
для мобильника - в штатном для Дебиана ядре 2.4.27
драйвер pl2303 еще и не умеет передавать микросхеме команды включить/выключить
сигналы управления потоком. Патч для задействования этих команд я помещал сюда
на прошлой неделе. В линуксе есть средство для просмотра состояния сигналов
последовательного порта - называется statserial. Вот чего в нем не хватает - так
это возможности принудительно устанавливать или обнулять любой управляющий
сигнал. Для проверки кабелей было бы очень удобно. Ткнул щуп тестера между
"землей" и сигналом на разъеме, пощелкал битом порта, посмотрел меняется ли
сигнал. Для стандартных портов и доса - у меня такое средство есть, а вот для
"виртуальных" портов и Линукса - я такого не знаю.
AW> Хотя справедливости ради стоит отметить, что через большинство из
AW> опробованных адаптеров тривиальный модем до провайдера дозванивается
AW> ок.
Да, процедура настройки преобразователя usb-com - заметно сложнее и требует
большей квалификации чем настройка стандартного ком-порта. у так а что ты хотел?
Техника более сложная, вот и капризничает....
о я свой кабель для мобильника победил.
Zahar
--- Msged/LNX 6.1.1
* Origin: mobile point - Compaq Armada 1750 + Siemens ME45 (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
