Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Опять serial порт... [D5, WinXP]


Страницы:   1 2

bg8 ©   (2005-12-09 20:47:00) 

Доброго времени суток, Мастера!

Извиняюсь сразу, вопрос собственно не то чтобы о Delphi, а философский...

Проблема в следующем. Есть некий девайс, который умеет общаться с компьютером при помощи интерфейса RS485. Есть WinXP, и переходник USBRS485. При подключении переходника в системе просто появляется еще один COM порт. Пусть будет COM3. Т.о. казалось бы, очень просто общаться с девайсом. НО. Девайс принимает команду в следующем формате:

1й байт - адрес устройства в сети RS485 (в данном случае пусть будет 1)

2й байт - кол-во байтов в пакете, исключая первый и второй

3й байт - код команды (команда - это один символ/байт)

У команды может быть некоторое кол-во параметров - от 2-х до 4-х байт

Последний байт - контрольная сумма.

Ну так вот, девайс реагирует только на команду, адресованную ему, если он знает этй команду и если контрольная сумма правильная. В противном случае он просто молчит. Если команда им распознана, то он отвечает на нее в таком же формате,  единственное что меняется - это значение и кол-во параметров.

Теперь к делу (извините за объемность текста, но все по делу помоему). под винду девайс реагирует только на две самых простых команды  - команды эти без параметров, и никаких параметров в ответ на эти команды девайсу возвращать не надо (это "ПУСК" и "СТОП"). Т.е. в ответ на эти команды он просто возвращает те же 4 байта, которые ему посылаешь, и включается (выключается). Ни на какие другие команды, которые требуют выхода за 4-х байтную границу, прибор не реагирует. (Я не утверждаю, что дело в числе 4, но сие есть экспериментальный факт.)

Есть тестовая программулька под ДОС, она требует чтоб был преобразователь COM в RS485 и висел он на COM2. Если загрузиться в ДОСе, то девайс на все команды отвечает адекватно, все работает зашибись. Думал, что дело в USB-конвертере, но нет, под винду повесил этот же конвертер COM в RS485, который работал в ДОСе, в винде все то же самое, что и с USB.

В описании этой программульки есть фраза, что "управление направлением передачи данных порта осуществляется с помощью сигнала RTS". Преобразователь интерфейса, что один, что другой, умеют аппаратно управлять направлением передачи данных. А в исходниках тестовой программульки есть такой кусочек: (программка на C, извините, на паскале нету:) )

(я по памяти пишу, поскольку все осталось на работе, попозже могу поточнее написать)

void outchar(int out){
outportb(COM+4,2);
outportb(COM,out);
while(!(inportb(COM+5)&64)) outportb(COM+4,0);
outportb(COM+4,2);
}


а переменная COM определена как 0х2F8 (ну в общем, адрес 2-го ком порта - тоже точно не помню).

В общем, я отчаялся добиться работы девайса под винду,

ай нид хелп!!

Заранее спасибо!


GEN++   (2005-12-13 23:53:00) [1]

>Ты забыл, что тут RS485?

  Нет не забыл - соединяя 2 Comm через RS232 отсекаем преобразователи.
Протокол до сих пор не вскрыт. Алгоритм рассчета КС так же.
Почему не отвечает прибор?
1 в пакете не его адрес
2 контроллер не понимает формат запроса
3 не совпадает КС
4 "разбег скорстей" между PC и контроллером который начинает
   сказываться после 4-го байта.
мое IMHO - собака зарыта скорее всего в 2 и 3

Так что протокол обмен и алгоритм рассчета КС - в студию.

>rs485 - два провода, дифференциальный сигнал -> нету никакого
>управляющего сигнала.

Верно, сигнала нет, но есть время после последнего переданного байта
 от PC. Если оно >  времени передачи 3.5 байт на текущей скорости
 то преобразователь переключается с передачи на прием. Обратное
 переключение поисходит при попытке передать байт(ы)  данных от PC.

>а вот про лишний байт мне тоже очень интересно... может это
>виндузовый   драйвер чевойто шлет по своему разумению?

Где обнаружен этот байт? До преобразователя USB<=>RS485 или после?


Германн   (2005-12-13 02:56:00) [2]


> GEN++ ©   (12.12.05 21:09) [27]
>
> >bg8 ©
> 1. Я Вам предлагал на Email перейти: обсуждение явно выходит
> за "рамки"
> темы форума => ветку могут в любой момент "прибить"

Ну это перебор! Имхо, выход за рамки конференции "Начинающим", тут не предвидится.


> Вопрос: "как считается КС" (весьма вероятно что это CRC8
> или дополнение
>  до 1). Пока не будет ответа на этот вопрос => дальнейшие
> эксперименты
>  будут скорее всего уводить в сторону от решения.

По утверждению автора:
"Теперь к делу (извините за объемность текста, но все по делу помоему). под винду девайс реагирует только на две самых простых команды  - команды эти без параметров, и никаких параметров в ответ на эти команды девайсу возвращать не надо (это "ПУСК" и "СТОП"). Т.е. в ответ на эти команды он просто возвращает те же 4 байта, которые ему посылаешь, и включается (выключается)."

КС считается правильно, имхо, иначе прибор бы и не отвечал и (главное) не реагировал бы на "простую команду".


> Я бы сделал так: соединил 2 Comm порта (RS232) нульмодемным
> кабелем
>  и запустил DOS программу на одном, а к на ругом бы "Hyper
> Terminal" или
>  еще лучше свою программу. Поскольку мастером на канале
> идет PC
>  то на приемном конце будут получены запросы которые подлежат
> расшифровке.
>

Ты забыл, что тут RS485?


GEN++   (2005-12-12 21:09:00) [3]

>bg8 ©
1. Я Вам предлагал на Email перейти: обсуждение явно выходит за "рамки"
темы форума => ветку могут в любой момент "прибить"
2. Что имеем в активе: обмен ведется пакетами
   в которых известно содержимое 1-го, 2-го байтов и которые обязательно
  терминируются однобайтной контрольной суммой
 Вопрос: "как считается КС" (весьма вероятно что это CRC8 или дополнение
 до 1). Пока не будет ответа на этот вопрос => дальнейшие эксперименты
 будут скорее всего уводить в сторону от решения.
 Я бы сделал так: соединил 2 Comm порта (RS232) нульмодемным кабелем
 и запустил DOS программу на одном, а к на ругом бы "Hyper Terminal" или
 еще лучше свою программу. Поскольку мастером на канале идет PC
 то на приемном конце будут получены запросы которые подлежат расшифровке.


Германн   (2005-12-12 16:38:00) [4]


> переходник USB<->RS485. нечем управлять. нету никаких сигналов
> о направлении передачи, кроме наличия данных в буфере. ИМХО
> конечно.
Ошибаешься.
>
> а вот про лишний байт мне тоже очень интересно... может
> это виндузовый драйвер чевойто шлет по своему разумению?
>

У драйверов своего разумения нет.


bg8   (2005-12-12 16:32:00) [5]

переходник USB<->RS485. нечем управлять. нету никаких сигналов о направлении передачи, кроме наличия данных в буфере. ИМХО конечно.

а вот про лишний байт мне тоже очень интересно... может это виндузовый драйвер чевойто шлет по своему разумению?


Германн   (2005-12-12 16:24:00) [6]


> rs485 - два провода, дифференциальный сигнал -> нету никакого
> управляющего сигнала.

Имхо, это управляющий сигнал для той микросхемы, которая в переходнике сидит.


> т.е. я шлю в порт 4 ьайта, а из порта в линию уходит какой-
> то загадочный байт, а потом мои 4
???


bg8   (2005-12-12 15:58:00) [7]

т.е. я шлю в порт 4 ьайта, а из порта в линию уходит какой-то загадочный байт, а потом мои 4


bg8   (2005-12-12 15:57:00) [8]

Ну а че, я опять фигню сказал? ))

rs485 - два провода, дифференциальный сигнал -> нету никакого управляющего сигнала.

а про байты - посылка на выходе состоит из 5-ти байт, из которых первый - не знаю чего такое, а остальные 4 - это мои 4 байта.


Германн   (2005-12-12 15:49:00) [9]


> ИМХО, в RS485 вообще нету такого понятия, как управление
> направлением передачи... Поэтому "как мертвому припарка"
> не потому, что винда не знает, что такое rs485,  а потому,
>  что rs485 наплевать на RTS.



> пятый байт, он на самом деле первый. Т.е. при изменении
> команды меняется на осциллографе все, кроме первых 8-ми
> битов


Как прикажешь тебя понимать, Саид? © "Белое солнце пустыни"


bg8   (2005-12-12 15:36:00) [10]

пятый байт, он на самом деле первый. Т.е. при изменении команды меняется на осциллографе все, кроме первых 8-ми битов


bg8   (2005-12-12 15:34:00) [11]

ИМХО, в RS485 вообще нету такого понятия, как управление направлением передачи... Поэтому "как мертвому припарка" не потому, что винда не знает, что такое rs485,  а потому, что rs485 наплевать на RTS.

Подключил линию к осциллографу. На две команды (те самые, кот. описаны в начале) девайс отвечает, на все другие - нет. Т.е. я не теряю ответ (а была такая мысль), его просто нету физически. Но осциллограф дал пищу для размышления... Я посылаю 4 байта в порт, а на выходе почему-то 5... Откуда берется пятый байт, я пока не понял.


Германн   (2005-12-12 15:12:00) [12]

2 bg8 ©   (12.12.05 11:13) [17]
Аппаратное управление потоком тут как мертвому припарка. Винда же не знает, что такое RS485.


> 2) Пробовал сам  программно ставить/снимать RTS после приема/перед
> передачей (т.е. наоборот :) ) Результат - см. пункт 1.

Скорее всего не успеваешь сменить сигнал RTS перед приемом и теряешь ответ. В винде это не просто сделать, имхо.


bg8   (2005-12-12 11:13:00) [13]

Привет всем! Спасибо за ответы! Теперь постараюсь ответить на все вопросы.

1) Аппаратное управление потоком - первое, что я попробовал сделать. Результат, сами понимаете, нулевой.

2) Пробовал сам  программно ставить/снимать RTS после приема/перед передачей (т.е. наоборот :) ) Результат - см. пункт 1.

Приведу карткий кусочек описания протокола:
"Интерфейс RS485 предназначен для связи с персональным компьютером, скорость передачи - 9600 бод. .................... Любая команда и ответ на нее представляет собой последовательность байтов. Младший (нулевой) байт - номер устройства (1). Следующий - число байт в посылке без нулевого и первого. Второй байт - код команды (ответа)  - ASCII символ от A до Z. Далее могут идти до 5-ти байт параметров. Завершает посылку контрольная сумма."

Все, что известно про требования к аппаратной части - 9600 бод...


Германн   (2005-12-12 01:51:00) [14]


> Теперь к делу (извините за объемность текста, но все по
> делу помоему). под винду девайс реагирует только на две
> самых простых команды  - команды эти без параметров, и никаких
> параметров в ответ на эти команды девайсу возвращать не
> надо (это "ПУСК" и "СТОП"). Т.е. в ответ на эти команды
> он просто возвращает те же 4 байта, которые ему посылаешь,
>  и включается (выключается). Ни на какие другие команды,
>  которые требуют выхода за 4-х байтную границу, прибор не
> реагирует. (Я не утверждаю, что дело в числе 4, но сие есть
> экспериментальный факт.)


2 GanibalLector ©   (10.12.05 12:39) [9]
2 tesseract ©   (11.12.05 20:31) [15]

Вам этого мало, чтобы понять , что вы не правы?

Если бы дело было в том, что "непереключена чётность", то "прибор" бы не выполнил бы никакую команду!
А ведь суть сабжа в том, что автор не получает ответ!


tesseract   (2005-12-11 20:31:00) [15]


>>Поставь PortMon и смотри за передачей/приемом.

Два компа соединяешь  Cross COM читаешь порт и смотришь что происходит.
Вариент GannibalLector с чётностью очень похож на реальность.

Ещё в догонку распайки всех упомянутых стандартов, может пригодится :

http://qnx.org.ru/index.php?option=com_minibb&action=vthread&forum=5&topic=76&page=1.html


Германн   (2005-12-11 02:23:00) [16]

2 YurikGL ©   (11.12.05 01:30) [13]
> А кто сказал, что в RS-232 нет RTS CTS ??? Если включить аппаратное управление потоком, эти сигналы сами должны выставляться. Их суть в том,...

Имхо, к сабжу это не относится.


YurikGL   (2005-12-11 01:30:00) [17]

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


Германн   (2005-12-11 00:28:00) [18]

2 bg8 ©   (09.12.05 20:47)
Сразу смущает нестыковки в объяснении сабжа:

> В описании этой программульки есть фраза, что "управление
> направлением передачи данных порта осуществляется с помощью
> сигнала RTS". Преобразователь интерфейса, что один, что
> другой, умеют аппаратно управлять направлением передачи
> данных. А в исходниках тестовой программульки есть такой
> кусочек: (программка на C, извините, на паскале нету:) )
>
> (я по памяти пишу, поскольку все осталось на работе, попозже
> могу поточнее написать)
>
> void outchar(int out){
> outportb(COM+4,2);
> outportb(COM,out);
> while(!(inportb(COM+5)&64)) outportb(COM+4,0);
> outportb(COM+4,2);
> }


Но, если я стелепировал правильно, то ты зря полагаешься на "Преобразователь интерфейса, что один, что
> другой, умеют аппаратно управлять направлением передачи
> данных." Фрагмент программы ясно показывает, перед передачей данных программаустанавливает RTS, а при приеме опять же именно программаRTS снимает. Чего ИМХО ты в своей Win-программе не делаешь!


GEN++   (2005-12-10 17:17:00) [19]

>bg8 ©
Поставь в свойствах Comm порта в разделе
"Управление потоком" значение "Аппаратное" или "HardWare"
и будет тебе счастье. Если же оного не случится
то скинь мне всю инфу, какая есть, по этому вопросу на мое мыло =>
попробую помочь (с RS-485 я денно и нощно занимаюсь).


Набережных С.   (2005-12-10 17:04:00) [20]


> bg8 ©

Раз некоторые команды выполняются, то проблема, имхо, в протоколе обмена. Я бы подключил к линии логический анализатор( при наличии оного:)) и посмотрел, как досовская программа обменивается. А если анализатора нет, то подходящий для данного случая несложно из компьютера сделать. Ну или FileMon, как уже посоветовали, если получится.


Страницы:   1 2

Наверх

Титульная страница Поиск, карта сайта Написать письмо