|
|
|
Работа с СОМ портом, Win2000 |
|
|
|
Feb 4 2005, 11:38
|
Гуру
Группа: Свой
Сообщений: 3 439
Регистрация: 29-12-04
Пользователь №: 1 741
|
Цитата(Shedon @ Feb 4 2005, 13:20) [khach], естественно из прикладной программы с портами ни кто работать не собирается, всё делается через WriteFile/ReadFile Offtopic on: Задавший вопрос как раз и работал. Цитата port[$3fc]:=$03; {настроить преобразователь RS232/485 на передачу} ... port[$3fc]:=$02;{настроить преобразователь RS232/485 на прием} Надеюсь что под ДОСом только. И ломка психологии программера при переходе под мультизадачную событийную операционку- процесс болезненный, по себе знаю. Offtopic off: Вопрос- есть жизненно необходимая прога, управляющая устройством по КОМ порту (универсальный программатор). Написана под ДОС ( прямая работа с портами, перехват прерывания). Под виндой естественно не работает. Исходников нет. Прога отдизамленна в попытке реверс-инжиниринга алгоритма управления. Найдены куски кода, отвечающие за работу с КОМом и понята их логика. Возникла идея похакать прогу с целью вызова winAPI. Кто нибудь сталкивался с примерами вызова 32-битного winAPI из 16-битных ДОС программ, желательно на ассемблере?
|
|
|
|
|
Feb 4 2005, 13:47
|
Гуру
Группа: Свой
Сообщений: 3 439
Регистрация: 29-12-04
Пользователь №: 1 741
|
Цитата(andk @ Feb 4 2005, 14:36) Скорее всего проблема именно в прерываниях - винда дает прямой доступ к сом порту. Под виндой нормально работают досовые проги с сом портами. Скрестить 16 битный код с winAPI врядли получится. Если найдены куски и понята их логика мож осталось только написать нормальную виндовую программу? Драйвер для работы с сом портом не нужен. А что за программатор? 98-дает, Миллениум - плохо, но дает, 2000, XP- нет. Если прога работает через int14- работает, если через порты в режиме пуллинга - так-сяк, если прога ставит свой обработчик IRQ3/IRQ4 ( как в моем случае)-не работает. Программатор- польский ACS MAX http://www.acs.ats.pl/. Поэтому переписать прогу трудно - библиотека почти в 1000 устройств, в том числе таких, для которых алгоритм не открыт. Под 98 еще кое-как работает при пониженной скорости порта. А если большую флешку шить - теряет коммуникацию гарантированно. Приходится содержать к нему ДОС машину.
|
|
|
|
|
Feb 4 2005, 21:09
|
Группа: Новичок
Сообщений: 7
Регистрация: 3-02-05
Пользователь №: 2 395
|
пожалуй, DPL прав! скорее всего так и происходит... Цитата Может, в Вашем примере для Win преобразователь RS232/485 все время на передачу работает я об этом подумал... но позже чем следовало, одной доки мне не дослали(прикрепил в аттаче) вторая часть документации на контроллер от разработчиков... блин, не могли в один файл запихнуть... попаду на работу, попробую поковырять...
|
|
|
|
|
Feb 5 2005, 04:40
|
Частый гость
Группа: Свой
Сообщений: 199
Регистрация: 17-12-04
Из: Миасс
Пользователь №: 1 519
|
Цитата(khach @ Feb 4 2005, 19:47) Цитата(andk @ Feb 4 2005, 14:36) Скорее всего проблема именно в прерываниях - винда дает прямой доступ к сом порту. Под виндой нормально работают досовые проги с сом портами. Скрестить 16 битный код с winAPI врядли получится. Если найдены куски и понята их логика мож осталось только написать нормальную виндовую программу? Драйвер для работы с сом портом не нужен. А что за программатор? 98-дает, Миллениум - плохо, но дает, 2000, XP- нет. Если прога работает через int14- работает, если через порты в режиме пуллинга - так-сяк, если прога ставит свой обработчик IRQ3/IRQ4 ( как в моем случае)-не работает. Программатор- польский ACS MAX http://www.acs.ats.pl/. Поэтому переписать прогу трудно - библиотека почти в 1000 устройств, в том числе таких, для которых алгоритм не открыт. Под 98 еще кое-как работает при пониженной скорости порта. А если большую флешку шить - теряет коммуникацию гарантированно. Приходится содержать к нему ДОС машину. Ну то есть я прав - проблема в прерываниях... Потому что Новосибирский Sterh до сих пор DOS-вый и работает нормально под всеми виндами. Видимо не пользуется прерываниями или пользуется грамотно Естес-но, если досовая прога пытается установить свой обработчик, то винда ее просто игнорирует. Печально, но похоже у вас нет вариантов - нужно держать на машине DOS.. Я так понимаю, что поляки прекратили поддержку этой модели. Может вежливо попросить разработчиков отдать исходники?
|
|
|
|
|
Feb 7 2005, 12:49
|
Частый гость
Группа: Свой
Сообщений: 146
Регистрация: 4-11-04
Из: Московская область
Пользователь №: 1 040
|
Цитата(khach @ Feb 4 2005, 16:47) 98-дает, Миллениум - плохо, но дает, 2000, XP- нет. Если прога работает через int14- работает, если через порты в режиме пуллинга - так-сяк, если прога ставит свой обработчик IRQ3/IRQ4 ( как в моем случае)-не работает. Сам проверял - в NT и в XP DOS программа работает с COM - портами по прерываниям. Почему так получается - не знаю, но это факт. Возможно у Вас прога "кривая". Везде то ей "плохо". Что касается DOS-машины, можно ДОС грузить с CD-ROMа. Только вот 32 FAT она не увидит. Надо FAT 16.
--------------------
- ЗАМЕНЯТЬ ДЕТАЛИ НА ХОДУ ВОСПРЕЩАЕТСЯ !!! -
|
|
|
|
|
Feb 9 2005, 07:22
|
Местный
Группа: Свой
Сообщений: 278
Регистрация: 18-01-05
Из: Санкт-Петербург
Пользователь №: 2 031
|
Цитата При установке DTR_CONTROL_DISABLE данные на контроллер не приходят вообще... Хе, а осциллографа у меня нет и наврядли когда-то появится... Это можно и без осцилографа определить. Закорачиваешь 2 и 3 ножки на COM порте. Запускаешь свою программу если она будет принимать тоже самое, что передаёт значит с программой всё ок. По поводу настройки DCB я не увидел у вас инициализации mydcb.fBinary = 1 DTR_CONTROL_ENABLE не включал и работало во всех виндовсах. Ваше устройство не поддерживает сигналы dtr,rts и т.д. зачем же включать аппаратное управление этими сигналами, тем более если вам надо использовать один из этих сигналов для переключения rx/tx. По поводу rs232-rs485. Раньше для переключения rx/tx я использовал EscapeCommFunction всё работало отлично во всех виндовсах на скорости 115200 без всяких драйверов(dtr, dsr и т.п. dataflowcontrol были отключены) Недавно натолкнулся на очень удачное схемное решение, используя которое нет необходимости переключать rx/tx со стороны PC!
Прикрепленные файлы
ppisch.zip ( 208.07 килобайт )
Кол-во скачиваний: 652
|
|
|
|
|
Feb 9 2005, 11:58
|
Местный
Группа: Модераторы
Сообщений: 392
Регистрация: 23-06-04
Из: Харьков
Пользователь №: 151
|
Здравствуйте. Есть не плохая книга: П. Агуров "Последовательные интерфейсы ПК. Практика программирования". С ней вместе идет CD, на котором, кроме прочего, есть занятная вещица - Драйвер GiveIoEx для прямого обращения к портам из Windows NT/2000/XP и пример его использования (приложение к разделу 9.3 главы "Переход в Windows"). Сделан этот драйвер как раз для таких случаев - работало в ДОС-е а вот понадобилось под NT... Приложение в виде zip архива (файл Glava9-3.ZIP, ~ 500kB) прикрепляю к этому сообщению. Попробуйте, может Вам и поможет. Успехов!
|
|
|
|
|
Feb 9 2005, 13:57
|
Местный
Группа: Модераторы
Сообщений: 392
Регистрация: 23-06-04
Из: Харьков
Пользователь №: 151
|
Цитата(andk @ Feb 9 2005, 16:18) Прикол всех этих псевдо драйверов в том, что они просто открываю доступ к порту для всех программ. То есть практически убирают защиту доступа а ресурсам. Соответственно, возникает ситуация, когда несколько приложений могут пытаться использовать одни и те же ресурсы. Вывод - для попробовать пойдет, для серьезной работы - нет. Все верно. Но в данном случае попробовать все-таки стоит.
|
|
|
|
|
Feb 15 2005, 08:33
|
Местный
Группа: Свой
Сообщений: 405
Регистрация: 4-10-04
Пользователь №: 777
|
Мужики, вы, похоже так и не поняли. Дело не в умении программировать хост компьютер для обмена по последовательному порту. Поэтому что толку предлагать разные либы и пакеты. Дело в том, что, видимо, порт контроллера полудуплексный. Т.е. он может в один момент времени либо передавать, либо принимать. Так вот он изначально стоит на приём. Для переключения его на передачу (как я думаю) ему, видимо, надо послать нужную команду, в ответ на которую контроллер что-то выдаст. Просто так он сам, похоже только принимает данные, поэтому передавая ему просто всякую ересь (для тестирования обмена), ответа от него не дождётесь. Надо поддержать протокол, т.е. читать инфу по контроллеру. Даже если у контроллера полный дуплекс, то не факт, что он просто так должен что-то выдавать пока его не попросишь.
|
|
|
|
|
Feb 15 2005, 08:58
|
Местный
Группа: Модераторы
Сообщений: 392
Регистрация: 23-06-04
Из: Харьков
Пользователь №: 151
|
Цитата(Dimonira @ Feb 15 2005, 11:33) Мужики, вы, похоже так и не поняли. Дело не в умении программировать хост компьютер для обмена по последовательному порту. Поэтому что толку предлагать разные либы и пакеты. Дело в том, что, видимо, порт контроллера полудуплексный. Т.е. он может в один момент времени либо передавать, либо принимать. Так вот он изначально стоит на приём. Для переключения его на передачу (как я думаю) ему, видимо, надо послать нужную команду, в ответ на которую контроллер что-то выдаст. Просто так он сам, похоже только принимает данные, поэтому передавая ему просто всякую ересь (для тестирования обмена), ответа от него не дождётесь. Надо поддержать протокол, т.е. читать инфу по контроллеру. Даже если у контроллера полный дуплекс, то не факт, что он просто так должен что-то выдавать пока его не попросишь. Да, но речь-то идет о ПРОГРАММАТОРЕ! И, насколько я понимаю, инициатором обмена информацией с программируемым устройством должен быть в данном случае именно программатор. А он этого не делает. Кроме того, автор темы пишет, что под ДОС и Win9x он у него работает (или работал и уже не работает? - если уже не работает, тогда действительно, надо разбираться с железякой). А проблемы возникли под NT, что закономерно, т.к. NT не позволяет (без драйверов, нормальных, которых нет, или "псевдо") работать напрямую с портами. Точнее, не с самими COM портами, а с их управляющими регистрами. А именно так и работает (судя по написанному в теме) программка для этого программатора. Лучше, пожалуй, действительно не морочить себе голову, а работать с ней так, как и работали - из-под ДОС-а.
|
|
|
|
|
|
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0
|
|
|