[khach 33]

[khach], естественно из прикладной программы с портами ни кто работать не собирается, всё делается через WriteFile/ReadFile

<{POST_SNAPBACK}>

Offtopic on:

Задавший вопрос как раз и работал.

port[$3fc]:=$03; {настроить преобразователь RS232/485 на передачу}

...

port[$3fc]:=$02;{настроить преобразователь RS232/485 на прием}

Надеюсь что под ДОСом только. И ломка психологии программера при переходе под мультизадачную событийную операционку- процесс болезненный, по себе знаю.

Offtopic off:

 

Вопрос- есть жизненно необходимая прога, управляющая устройством по КОМ порту (универсальный программатор). Написана под ДОС ( прямая работа с портами, перехват прерывания).

Под виндой естественно не работает. Исходников нет. Прога отдизамленна в попытке реверс-инжиниринга алгоритма управления. Найдены куски кода, отвечающие за работу с КОМом и понята их логика. Возникла идея похакать прогу с целью вызова winAPI. Кто нибудь сталкивался с примерами вызова 32-битного winAPI из 16-битных ДОС программ, желательно на ассемблере?

[andk 0]

>Вопрос- есть жизненно необходимая прога, управляющая устройством

>по КОМ порту (универсальный программатор). Написана под ДОС (

>прямая работа с портами, перехват прерывания).

Скорее всего проблема именно в прерываниях - винда дает прямой доступ к сом порту.

 

>Под виндой естественно не работает. Исходников нет. Прога

>отдизамленна в попытке реверс-инжиниринга алгоритма управления.

>Найдены куски кода, отвечающие за работу с КОМом и понята их

>логика. Возникла идея похакать прогу с целью вызова winAPI. Кто

>нибудь сталкивался с примерами вызова 32-битного winAPI из

>16-битных ДОС программ, желательно на ассемблере?

Под виндой нормально работают досовые проги с сом портами.

Скрестить 16 битный код с winAPI врядли получится.

Если найдены куски и понята их логика мож осталось только написать нормальную виндовую программу? Драйвер для работы с сом портом не нужен.

А что за программатор?

[khach 33]

Скорее всего проблема именно в прерываниях - винда дает прямой доступ к сом порту.

 

Под виндой нормально работают досовые проги с сом портами.

Скрестить 16 битный код с winAPI врядли получится.

Если найдены куски и понята их логика мож осталось только написать нормальную виндовую программу? Драйвер для работы с сом портом не нужен.

А что за программатор?

<{POST_SNAPBACK}>

98-дает, Миллениум - плохо, но дает, 2000, XP- нет. Если прога работает через int14- работает, если через порты в режиме пуллинга - так-сяк, если прога ставит свой обработчик IRQ3/IRQ4 ( как в моем случае)-не работает.

 

Программатор- польский

ACS MAX http://www.acs.ats.pl/. Поэтому переписать прогу трудно - библиотека почти в 1000 устройств, в том числе таких, для которых алгоритм не открыт. Под 98 еще кое-как работает при пониженной скорости порта. А если большую флешку шить - теряет коммуникацию гарантированно. Приходится содержать к нему ДОС машину.

[uvw 0]

пожалуй, DPL прав! скорее всего так и происходит...

Может, в Вашем примере для Win преобразователь RS232/485 все время на передачу работает

я об этом подумал... но позже чем следовало, одной доки мне не дослали(прикрепил в аттаче)

вторая часть документации на контроллер от разработчиков... блин, не могли в один файл запихнуть...

попаду на работу, попробую поковырять...

RS232_485.pdf

[andk 0]

Скорее всего проблема именно в прерываниях - винда дает прямой доступ к сом порту.

 

Под виндой нормально работают досовые проги с сом портами.

Скрестить 16 битный код с winAPI врядли получится.

Если найдены куски и понята их логика мож осталось только написать нормальную виндовую программу? Драйвер для работы с сом портом не нужен.

А что за программатор?

<{POST_SNAPBACK}>

98-дает, Миллениум - плохо, но дает, 2000, XP- нет. Если прога работает через int14- работает, если через порты в режиме пуллинга - так-сяк, если прога ставит свой обработчик IRQ3/IRQ4 ( как в моем случае)-не работает.

 

Программатор- польский

ACS MAX http://www.acs.ats.pl/. Поэтому переписать прогу трудно - библиотека почти в 1000 устройств, в том числе таких, для которых алгоритм не открыт. Под 98 еще кое-как работает при пониженной скорости порта. А если большую флешку шить - теряет коммуникацию гарантированно. Приходится содержать к нему ДОС машину.

<{POST_SNAPBACK}>

 

Ну то есть я прав - проблема в прерываниях...

Потому что Новосибирский Sterh до сих пор DOS-вый и работает нормально под всеми виндами. Видимо не пользуется прерываниями или пользуется грамотно :)

Естес-но, если досовая прога пытается установить свой обработчик, то винда ее просто игнорирует.

 

Печально, но похоже у вас нет вариантов - нужно держать на машине DOS..

Я так понимаю, что поляки прекратили поддержку этой модели. Может вежливо попросить разработчиков отдать исходники?

[-Tумблер- 0]

98-дает, Миллениум - плохо, но дает, 2000, XP- нет.  Если прога работает через int14- работает, если через порты в режиме пуллинга - так-сяк, если прога ставит свой обработчик IRQ3/IRQ4 ( как в моем случае)-не работает.

 

<{POST_SNAPBACK}>

 

Сам проверял - в NT и в XP DOS программа работает с COM - портами

по прерываниям. Почему так получается - не знаю, но это факт.

Возможно у Вас прога "кривая". Везде то ей "плохо".

 

Что касается DOS-машины, можно ДОС грузить с CD-ROMа.

Только вот 32 FAT она не увидит. Надо FAT 16.

:(

[one_man_show 0]

Попробуйте скачать отсюда Torry компонент для Дельфи или Билдера. Этим компонентом пользуюсь давно, работает устойчиво. Самое главно - очень хорошо сделан сам компонент и документирован. Можно, посмотрев исходники, многое понять, особенно, как работать с API и портами. На сайте автора есть более свежая версия, но что-то сайт не откликается, попробуйте позднее Dejan Crnila

[Dimonira 0]

Как я понял из всего сказанного, у человека порт контроллера полудуплексный и его надо переключать на приём/передачу на стороне хоста самому по одной из линий порта (RTS/CTS). А этого он и не может (пока) сделать.

[_Sam_ 0]

При установке 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 были отключены) :excl:

 

Недавно натолкнулся на очень удачное схемное решение, используя которое нет необходимости переключать rx/tx со стороны PC!

ppisch.zip

[SergM 0]

Здравствуйте.

 

Есть не плохая книга: П. Агуров "Последовательные интерфейсы ПК.

Практика программирования".

 

С ней вместе идет CD, на котором, кроме прочего, есть занятная вещица - Драйвер GiveIoEx для прямого обращения к портам из Windows NT/2000/XP и пример его использования (приложение к разделу 9.3 главы "Переход в Windows"). Сделан этот драйвер как раз для таких случаев - работало в ДОС-е а вот понадобилось под NT...

 

Приложение в виде zip архива (файл Glava9-3.ZIP, ~ 500kB) прикрепляю к этому сообщению. Попробуйте, может Вам и поможет.

 

Успехов!

Glava9_3.ZIP

[makc 192]

GiveIo с некоторыми программами ведет себя очень странно. У меня доходило до того, что переставал работать InstalShield, т.е. ничего нельзя было ни добавить, ни удалить. Поэтому рекомендую другую библиотеку, которая совмещена с драйвером для низкоуровнего доступа к портам ввода-вывода под W2K, WXP.

IO_Ports.rar

[andk 0]

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

[SergM 0]

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

<{POST_SNAPBACK}>

 

Все верно. Но в данном случае попробовать все-таки стоит.

[Dimonira 0]

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

Дело в том, что, видимо, порт контроллера полудуплексный. Т.е. он может в один момент времени либо передавать, либо принимать. Так вот он изначально стоит на приём. Для переключения его на передачу (как я думаю) ему, видимо, надо послать нужную команду, в ответ на которую контроллер что-то выдаст. Просто так он сам, похоже только принимает данные, поэтому передавая ему просто всякую ересь (для тестирования обмена), ответа от него не дождётесь. Надо поддержать протокол, т.е. читать инфу по контроллеру.

Даже если у контроллера полный дуплекс, то не факт, что он просто так должен что-то выдавать пока его не попросишь.

[SergM 0]

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

Дело в том, что, видимо, порт контроллера полудуплексный. Т.е. он может в один момент времени либо передавать, либо принимать. Так вот он изначально стоит на приём. Для переключения его на передачу (как я думаю) ему, видимо, надо послать нужную команду, в ответ на которую контроллер что-то выдаст. Просто так он сам, похоже только принимает данные, поэтому передавая ему просто всякую ересь (для тестирования обмена), ответа от него не дождётесь. Надо поддержать протокол, т.е. читать инфу по контроллеру.

Даже если у контроллера полный дуплекс, то не факт, что он просто так должен что-то выдавать пока его не попросишь.

<{POST_SNAPBACK}>

 

Да, но речь-то идет о ПРОГРАММАТОРЕ! И, насколько я понимаю, инициатором обмена информацией с программируемым устройством должен быть в данном случае именно программатор. А он этого не делает. Кроме того, автор темы пишет, что под ДОС и Win9x он у него работает (или работал и уже не работает? - если уже не работает, тогда действительно, надо разбираться с железякой). А проблемы возникли под NT, что закономерно, т.к. NT не позволяет (без драйверов, нормальных, которых нет, или "псевдо") работать напрямую с портами. Точнее, не с самими COM портами, а с их управляющими регистрами. А именно так и работает (судя по написанному в теме) программка для этого программатора.

 

Лучше, пожалуй, действительно не морочить себе голову, а работать с ней так, как и работали - из-под ДОС-а.