RS 485 и полудуплекс

[GlukSoft]

Разрабатываемые нами платы работают по RS 485 в режиме полудуплекса (два провода 1 TX- и 2 TX+), до этого работали с платой Advantech PCI-1602B и никаких проблем небыло, данные нормльно уходили и приходили, плата сама определяла направление передачи. Сейчас понадобилась плата для ноутбука, купили Advantech COMpad-85B2 в документации написано, что по двум проводам работает, воткнули не пошло. Стали копать, нашли в FAQе на сайте производителя, что надо соединить TX- c RX- и RX+ с TX+ ,управлять RTSом и игнорировать эхо во время посылки данных.
Ладно сделали: контакты соединили, перед посылкой устанавливаю RTS сразу опосля очищаю, данные уходят (плата реагирует на команды как надо), эхо приходит, а вот вместо данных, которые должна выдавать плата, приходит черт знает что, то есть длинна совпадает, а вот данные нет.
Что с этим делать и в каком направлении копать?

[RXL]

GlukSoft, режим fullduplex или halfdupulex должен быть одинаковым с обеих концов. Железо так же должно поддерживать нужный режим.
Если не ошибаюсь, half - RS-422, full - RS-485. Давно было - не помню.

Или я не понимаю в чем вопрос? Тогда поясни, пожалуйста, понятнее.

[xelos]

я с Advantechовскими модулями ADAM работал (к сетке RS485 подключался через ADAM 5060, вроде, который интерфейс USB/RS485) - никаких проблем замечено не было ни на портабельном, ни на десктопе. из программы с модулями работал как с обычным COM портом - никаких заморочек. попоробнее про то, что надо сделать напиши.

[GlukSoft]

RXL, поллудуплекс реализуется и на 485, для того чтобы на одну линию вешать несколько устройств, я так понял, что нормальный полудуплекс на PCMCIA карточке не реализован, поэтому они просят соединить вход с выходом, а приемом-передачей управлять RTS-ом, собственно из-за замкнутых входа и выхода и приходит эхо во время посылки, вопрос в том, почему данные из устройства приходят правильные по длинне, но не правильные по содержанию.
Помучили еще плату, стали увеличивать задержку на отсылку данных нашим устройством, получилось оригинально: при увеличенной задержке первые два байта - бред, остальные нормальные, если еще увеличить задержку, то первый байт бред, остальные нормальные. Вроде надо было бы еще увеличить задержку, но если повторять команду подряд пять раз, то в первом случае все пять ответов примерно одинаковые (два - бред с вариациями, остальные нормальные), а во втором случае три одинаковых ответа (по идиотизму), а последние два вообще фигня (зацикленные последние три байта).
xelos, так дело в том, что у тебя один и тотже ADAMчик, а у нас две разные платы PCIная и PCMCIAная. С портом я действительно работаю как с обычным COM портом, проблема из-за того, что в PCMCIAном варианте не реализован полудуплекс, и они предлагают подобный изврат. Соответственно вопрос, как с этим бороться?

[Alf]

А в полном дуплексе проверял? Если изолировать прием и передачу, сообщения приходят нормально?

[Серж]

GluckSoft! Есть еще такой нюанс. RTS нужно переключать после ухода из порта последнего бита и не раньше, а это событие определяется очисткой двух битов
в регистре состояния линии по адресу BaseAddr+5 (регистр должен перейти из
$60 в 0). Как правило, стандартный драйвер Com-порта либо не отслеживает это событие, либо делает это криво.

[GlukSoft]

Alf, в полном дуплексе все нормуль, но он нам на ... не нужен.
Серж, посмотрю внимательнее, но насколько я помню, отсылку последнего байта я отслеживаю.

[Alf]

Я просто на предмет удостовериться, все ли там в приемнике нормально.

Если по-хорошему не получается, то не спасет ли диффсистема отцов русской демократии? Вроде не такая уж дорогая вещь, и процесс управляемым станет.

[Серж]

GluckSoft! Не последнего байта, а именно последнего бита последнего байта.
Аппаратное  прерывание выдается как раз в начале ухода последнего байта.

[GlukSoft]

Серж, ладно, гляну. В ник букву c необязательно вставлять

[Серж]

GlukSoft, больше не буду. А еще возможен вариант, что переключение RTS происходит слишком поздно, т.е. железяка слишком быстро отвечает на твой запрос и происходит сдвиг данных

[RXL]

GlukSoft, не пробовал осцилографом проверить? Если подобрать периодичность посылка-пауза, то картина может стать видимой. Мне кажется, что тут дело в искажении сигнала - похоже на влияние реактивной нагрузки.

Alf, а разве RS485 и так не работает с дифференциальной линией? Или ты о чем?

[Alf]

Alf, а разве RS485 и так не работает с дифференциальной линией? Или ты о чем?

Нет, я немного о другом. Имею в виду дифференциальную систему, при помощи которой связисты превращают 4-проводные линии в 2-проводные и наоборот. Этакий 6-полюсник, у которого есть вход, выход и линия.

То, что подается на вход диффсистемы, уходит в линию. То, что приходит с линии, подается на выход диффсистемы. При этом развязка между входом и выходом довольно хорошая. Таким образом, кстати, в телефонии давят локальное эхо, чтобы сигнал с микрофона не глушил говорящего, а заодно и с самовозбуждением борются, ведь акустическая связь микрофона и телефона обычно неслабая.

Такая штука позволит полностью развязать вход и выход интерфейса и разобраться с ними по отдельности. Иначе не поймешь, кто портит сигнал (и портит ли), когда все включено параллельно. А так можно и осциллографом стать на вход, поглядеть, что там творится. А еще лучше - сварганить преобразователь в RS-232 и подключить параллельно заведомо исправный комп в режиме эмуляции терминала, поглядеть, что там передается/принимается. А то вслепую гадать долго придется.

[xelos]

кстати, насчет эмулятора - если прога работает с карточкой как с обычным ком портом, есть полезная утилитка - PortMon называется, от SystemInternals, она позволяет проанализировать все операции с портом (до битового уровня не доходит, но показывает как и когда конфигурируется порт и что отправляется и принимается). Меня много раз уже выручала.

[GlukSoft]

Спасибо всем. С ручным переключением RTS я зае..., но получил результаты получше, т.е. довел процент развала посылок до 6. Потом вспомнил рекомендации типа RTFM, и откопал, если поставить dcb.fRtsControl = RTS_CONTROL_TOGGLE, то после ухода последнего бита RTS переключается на прием, и все пошло .

[RXL]

Таки, физически, в чем была причина, осталось не известно*

[GlukSoft]

RXL, угу, лень было брать цифровой осцил, читать к нему инструкцию, MSDN всетаки роднее

[Серж]

Очевидно, что причина в том, что не вовремя переключался RTS, либо слишком рано, либо слишком поздно. Кстати, автоматическое переключение RTS, которое в конце концов помогло, помогает не всегда, особенно для плат, которые отвечают слишком быстро. Я использовал стандартный дравер Com-порта в Win2000 с автоматическим переключением RTS для платы, которая отвечала в течение одной миллисекунды после команды, и это не помогало, работал только ручной способ.