Здравствуйте, уважаемые!
Если кто сталкивался, помогите плизз. Долбаюсь уже 2 недели, и ничего не получается. Ситуация следующая: Есть некий контроллер и общается он с компьютером через RS232, в Win98 все работает, а вот Операционка Win2000
блокирует прямое обращение к портам. Мне подсказали прогу WinDriver для обхода этой проблемы... но опять-же, для LPT порта там есть стандартная заготовка, которая прекрасно работает... а о СОМ порте ни слова. Сразу оговорюсь, я не являюсь системным программистом и с железом дел никогда не имел... а тут пришлось

Искренне надеюсь на Вашу помощь. Заранее спасибо.
З.Ы.
Я впервые на этом форуме, и вполне возможно что запостил тему не совсем в тот раздел куда следовало бы.
ЗЗ.ЫЫ
Работать с этой штукой через CreateFile/ReadFile/WriteFile тоже не получается,
в ReadFile постоянно нули возвращаются, хотя команда сформирована верно и контроллером принята...
IgorKossak
Feb 3 2005, 09:23
Попробуйте следуюшее в прикреплённом файле.
У меня под Win2000 получалось.
Спасибо, но эту статью я недавно читал (на сайте www.rs232.ru) но, дело в том, что я никак не могу получить вообще ничего от контроллера... Я пробовал событийную модель(с помощью Overlapped и WaitCommEvent) с различными масками. Как поется, "Крикну, а в ответ - тишна"...
Тут вопрос стоит в прямом обращении к порту, а это возможно только при наличии соответстующего драйвера(во всяком случае, в Win200/XP и им подобным) Для написания драйвера, посоветовали использовать WinDriver...
Если кто ее использовал при работе с СОМ портом, подскажите плизз!!!
IgorKossak
Feb 3 2005, 10:59
Зачем такие сложности с прямым доступом если и через API всё прекрасно работает?
Вы видимо не очень тщательно разобрались. Я делал всё как сказано в статье и всё получилось и под Win98 и под Win2000.
Могу привести исходник на паскале, присланный разработчиками железки, и свой, на С++ который пытаюсь переписать с паскалевской и перевести на WinAPI... Был бы благодарен, если укжете в чем ошибка...
а вы попробуйте RxD и TxD закоротить, и отправить в порт чтенить.
если ничего не приниматься не будет - проверьте настройку DCB структуры, у меня было что в настройках проверку DSR , CTS , RTS или DTR отключить надо. давно было не могу сказать что точно. но история таже - в 98 работало, а в 2к нет. потом все пучком стало
О!!! нашел
fDsrSensitivity = NULL
Задает чувствительсть коммуникационного драйвера к состоянию линии DSR. Если это поле равно TRUE, то все принимаемые данные игнорируются драйвером (коммуникационный драйвер расположен в операционной системе), за исключением тех, которые принимаются при установленом сигнале DSR.
его в ноль,
fDtrControl = DTR_CONTROL_DISABLE и fRtsControl = RTS_CONTROL_DISABLE
По идее дожно зафурыкать.
Фуухх, я уже окончательно запутался....
выкладываю настройку DCB
Код
....
DriverHandle = CreateFile (Com_Name, GENERIC_READ | GENERIC_WRITE,
0, NULL, OPEN_EXISTING, 0, NULL);
if (DriverHandle == INVALID_HANDLE_VALUE)
{
return (DriverHandle);
}
else
{
SetupComm (DriverHandle, 1024, 1024);
GetCommState (DriverHandle, &Our_DCB);
Our_DCB.BaudRate = DCB_Baud_Rate;
Our_DCB.fParity = 0;
Our_DCB.fOutxCtsFlow = 0;
Our_DCB.fOutxDsrFlow = 0;
Our_DCB.fDtrControl = DTR_CONTROL_ENABLE;
Our_DCB.fDsrSensitivity = NULL;
Our_DCB.fTXContinueOnXoff = 0;
Our_DCB.fOutX = 0;
Our_DCB.fInX = 0;
Our_DCB.fErrorChar = 0;
Our_DCB.fNull = 0;
Our_DCB.fRtsControl = RTS_CONTROL_DISABLE;
Our_DCB.fAbortOnError = 0;
Our_DCB.ByteSize = 8;
Our_DCB.Parity = NOPARITY;
Our_DCB.StopBits = ONESTOPBIT;
SetCommState (DriverHandle, &Our_DCB);
SetCommMask (DriverHandle, EV_TXEMPTY);
}
....
А потом вызываю WriteFile... Данные приходят
на контроллер, причем правильно им "понимаются"... а при вызове
ReadFile нет ни одного быйта в очереди...
а вот что происходит в паскале...
Код
{проверка контроллера на СОМ1}
{в первом байте -младший адрес, идентификатор}
{во втором байте-старший адрес, идентификатор, тип модуля, интервал ответа}
{третий байт (первый байт массива)-команда, идентификатор, интервал между ответами}
{если нужно передать данные, то следующие байт(ы) массива-данные}
{последний байт-контрольная сумма}
program com;
uses crt,dos;
var a,b,c,n,rs,P:byte;
rs_old:pointer;
r:registers;
KS:word;
I:byte;
const
MAX:byte = 1;{1-если нет данных} {команда---данные}
BUF:array[1..10] of byte = ($e0, $8f,$8f,$8f,$8f,$8f,$8f,$8f,$8f,$8f);
label no_RX_,no_0,no_1,no_2,no_RX__,yes_key;
begin
KS:=0;
I:=0;
port[$3fb]:=$83;{без паритета}
port[$3f8]:=$06;
port[$3f9]:=$00;{19200бод}
port[$3fb]:=$03;
port[$3f9]:=$00;
port[$3fc]:=$03; {настроить преобразователь RS232/485 на передачу}
delay(500);
b:=0;
KS:=0;
{--ФОРМИРОВАНИЕ МЛАДШЕГО АДРЕСА с битами идентификатора, типа модуля--}
P:=$00;
KS:=P;
port[$3f8]:=P;{передать адрес младший}
no_0:
rs:=port[$3fd];
rs:=rs and 64;
if rs<>64 then goto no_0
else
{goto yes_key;}
{-------------------------------------}
{--ФОРМИРОВАНИЕ СТАРШЕГО АДРЕСА с битами идентификатора, типа модуля и интервала ответа--}
P:=$70;
KS:=KS+P;
port[$3f8]:=P;{передать адрес старший}
no_1:
rs:=port[$3fd];
rs:=rs and 64;
if rs<>64 then goto no_1
else
{goto yes_key;}
{----------------------------}
{--СФОРМИРОВАТЬ КОМАНДУ с битом идентификатора и интервалом между байтами ответа--}
{если необходимо передать данные- изменить индекс и уст. данные массива}
while (I < MAX) do
begin
I:=I+1;
P:=BUF[I];
KS:=KS+P;
port[$3f8]:=P;{передать команду И ДАННЫЕ}
no_2:
rs:=port[$3fd];
rs:=rs and 64;
if rs<>64 then goto no_2
else
end;
{goto yes_key;}
{----------------------------}
{--СФОРМИРОВАТЬ К.С. с битом идентификатора--}
KS:=KS and $00ff;
P:=KS;
P:=P or $80;
port[$3f8]:=P;{передать КС}
port[$3fc]:=$02;{настроить преобразователь RS232/485 на прием}
write('com ');
{----------------------------}
{--ПРИНЯТЬ ВСЕ ПОДРЯД--}
no_RX_:
if memw[0:$41a]<>memw[0:$41c] then goto yes_key;
rs:=port[$3fd];
rs:=rs and 1;
if rs<>1 then goto no_RX_
else
a:=port[$3f8];a:=a and 127; {стереть, для вывода на экран, бит идентификатор}
write(a,';');
goto no_RX_;
yes_key:
writeln(KS);
end.
end
Может кто что подскажет....
Our_DCB.fDtrControl = DTR_CONTROL_ENABLE;
этой настройкой ты запрещаешь прием данных на комп, если в не устройстве установлен DTR.
короче
1 попробуй сменить на DTR_CONTROL_DISABLE
2 посмотри осцилографом идет ли вообще сигнал?
еще
????SetCommMask (DriverHandle, EV_TXEMPTY);
после
SetCommState(port, &dcb);
я ставлю
SetupComm(port, 50, 50);
а перед записью и считыванием
//сброс буфера порта
PurgeComm(port, PURGE_RXCLEAR|PURGE_TXCLEAR);
то Sam: включи аську
При установке DTR_CONTROL_DISABLE данные на контроллер не приходят
вообще... Хе, а осциллографа у меня нет

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

я уже облазил весь www.RS232.ru, перечитал кучу материала...но, никак не найду источник проблемы и метод устранения... с помошью WinDriver'a, тоже что-то не получается... хотя, код драйвера он генерит сам, главное настроить ресурсы устройства, а, потом, зарегить новый драйвер(удалив перед этим виндозный)... я в шоке.
а всем, кто принимает участие в обсуждении, большой
я бы отправил тебе свои исходники, да у меня как раз все настройки в файле сохраняются
если надо могу отправить.
но это завтра....
засиделся я, пора домой.
veter, Давай, буду очень признателен

присылай на uvw@ua.fm or _prog@ua.fm
если что придумается... я в аське (почти круглосуточно) ICQ# 342610002
Цитата(uvw @ Feb 3 2005, 18:39)
а вот что происходит в паскале...
Код
...
port[$3fc]:=$03; {настроить преобразователь RS232/485 на передачу}
...
port[$3fc]:=$02;{настроить преобразователь RS232/485 на прием}
...
Не в этом ли дело? Может, в Вашем примере для Win преобразователь RS232/485 все время на передачу работает? Я, правда, назначение портов UART не помню, поэтому сходу не скажу, как то же самое можно сделать в WinAPI. Если нужно, могу выслать исходники на Паскале (Delphi), где у меня реализована связь с контролером (правда, используется только TxD и RxD, управления преобразователем нет).
Здесь есть класс для работы с ком портом, у меня через него всё работает.
При порты в прикладной программе забудьте- это привелегия драйверов (vxd, sys). Вот хороший компонент для Дельфей с примерами. Работает на всем, и на USB переходниках тоже.
RS485 к сожалению под Виндой работает отвратительно. И переключать направление из программы корректно неполучится. Т.к. физическая передача в порт разнесена по времени с вызовом WriteFile, то даже ESC команды не переключат направление RS485 вовремя.
Если скорость постоянна, то направление можно переключать одновибратором в разъеме. Хотя более эффективное решение- маленькая схема на AT89c2051. Там же делали и опторазвязку.
[khach], естественно из прикладной программы с портами ни кто работать не собирается, всё делается через WriteFile/ReadFile
Цитата(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-битных ДОС программ, желательно на ассемблере?
>Вопрос- есть жизненно необходимая прога, управляющая устройством
>по КОМ порту (универсальный программатор). Написана под ДОС (
>прямая работа с портами, перехват прерывания).
Скорее всего проблема именно в прерываниях - винда дает прямой доступ к сом порту.
>Под виндой естественно не работает. Исходников нет. Прога
>отдизамленна в попытке реверс-инжиниринга алгоритма управления.
>Найдены куски кода, отвечающие за работу с КОМом и понята их
>логика. Возникла идея похакать прогу с целью вызова winAPI. Кто
>нибудь сталкивался с примерами вызова 32-битного winAPI из
>16-битных ДОС программ, желательно на ассемблере?
Под виндой нормально работают досовые проги с сом портами.
Скрестить 16 битный код с winAPI врядли получится.
Если найдены куски и понята их логика мож осталось только написать нормальную виндовую программу? Драйвер для работы с сом портом не нужен.
А что за программатор?
Цитата(andk @ Feb 4 2005, 14:36)
Скорее всего проблема именно в прерываниях - винда дает прямой доступ к сом порту.
Под виндой нормально работают досовые проги с сом портами.
Скрестить 16 битный код с winAPI врядли получится.
Если найдены куски и понята их логика мож осталось только написать нормальную виндовую программу? Драйвер для работы с сом портом не нужен.
А что за программатор?
98-дает, Миллениум - плохо, но дает, 2000, XP- нет. Если прога работает через int14- работает, если через порты в режиме пуллинга - так-сяк, если прога ставит свой обработчик IRQ3/IRQ4 ( как в моем случае)-не работает.
Программатор- польский
ACS MAX
http://www.acs.ats.pl/. Поэтому переписать прогу трудно - библиотека почти в 1000 устройств, в том числе таких, для которых алгоритм не открыт. Под 98 еще кое-как работает при пониженной скорости порта. А если большую флешку шить - теряет коммуникацию гарантированно. Приходится содержать к нему ДОС машину.
пожалуй, DPL прав! скорее всего так и происходит...
Цитата
Может, в Вашем примере для Win преобразователь RS232/485 все время на передачу работает
я об этом подумал... но позже чем следовало, одной доки мне не дослали(прикрепил в аттаче)
вторая часть документации на контроллер от разработчиков... блин, не могли в один файл запихнуть...
попаду на работу, попробую поковырять...
Цитата(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..
Я так понимаю, что поляки прекратили поддержку этой модели. Может вежливо попросить разработчиков отдать исходники?
-Tумблер-
Feb 7 2005, 12:49
Цитата(khach @ Feb 4 2005, 16:47)
98-дает, Миллениум - плохо, но дает, 2000, XP- нет. Если прога работает через int14- работает, если через порты в режиме пуллинга - так-сяк, если прога ставит свой обработчик IRQ3/IRQ4 ( как в моем случае)-не работает.
Сам проверял - в NT и в XP DOS программа работает с COM - портами
по прерываниям. Почему так получается - не знаю, но это факт.
Возможно у Вас прога "кривая". Везде то ей "плохо".
Что касается DOS-машины, можно ДОС грузить с CD-ROMа.
Только вот 32 FAT она не увидит. Надо FAT 16.
one_man_show
Feb 7 2005, 13:20
Попробуйте скачать отсюда
Torry компонент для Дельфи или Билдера. Этим компонентом пользуюсь давно, работает устойчиво. Самое главно - очень хорошо сделан сам компонент и документирован. Можно, посмотрев исходники, многое понять, особенно, как работать с API и портами. На сайте автора есть более свежая версия, но что-то сайт не откликается, попробуйте позднее
Dejan Crnila
Dimonira
Feb 9 2005, 06:15
Как я понял из всего сказанного, у человека порт контроллера полудуплексный и его надо переключать на приём/передачу на стороне хоста самому по одной из линий порта (RTS/CTS). А этого он и не может (пока) сделать.
Цитата
При установке 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!
Здравствуйте.
Есть не плохая книга: П. Агуров "Последовательные интерфейсы ПК.
Практика программирования".
С ней вместе идет CD, на котором, кроме прочего, есть занятная вещица - Драйвер GiveIoEx для прямого обращения к портам из Windows NT/2000/XP и пример его использования (приложение к разделу 9.3 главы "Переход в Windows"). Сделан этот драйвер как раз для таких случаев - работало в ДОС-е а вот понадобилось под NT...
Приложение в виде zip архива (файл Glava9-3.ZIP, ~ 500kB) прикрепляю к этому сообщению. Попробуйте, может Вам и поможет.
Успехов!
GiveIo с некоторыми программами ведет себя очень странно. У меня доходило до того, что переставал работать InstalShield, т.е. ничего нельзя было ни добавить, ни удалить. Поэтому рекомендую другую библиотеку, которая совмещена с драйвером для низкоуровнего доступа к портам ввода-вывода под W2K, WXP.
Прикол всех этих псевдо драйверов в том, что они просто открываю доступ к порту для всех программ. То есть практически убирают защиту доступа а ресурсам. Соответственно, возникает ситуация, когда несколько приложений могут пытаться использовать одни и те же ресурсы. Вывод - для попробовать пойдет, для серьезной работы - нет.
Цитата(andk @ Feb 9 2005, 16:18)
Прикол всех этих псевдо драйверов в том, что они просто открываю доступ к порту для всех программ. То есть практически убирают защиту доступа а ресурсам. Соответственно, возникает ситуация, когда несколько приложений могут пытаться использовать одни и те же ресурсы. Вывод - для попробовать пойдет, для серьезной работы - нет.
Все верно. Но в данном случае попробовать все-таки стоит.
Dimonira
Feb 15 2005, 08:33
Мужики, вы, похоже так и не поняли. Дело не в умении программировать хост компьютер для обмена по последовательному порту. Поэтому что толку предлагать разные либы и пакеты.
Дело в том, что, видимо, порт контроллера полудуплексный. Т.е. он может в один момент времени либо передавать, либо принимать. Так вот он изначально стоит на приём. Для переключения его на передачу (как я думаю) ему, видимо, надо послать нужную команду, в ответ на которую контроллер что-то выдаст. Просто так он сам, похоже только принимает данные, поэтому передавая ему просто всякую ересь (для тестирования обмена), ответа от него не дождётесь. Надо поддержать протокол, т.е. читать инфу по контроллеру.
Даже если у контроллера полный дуплекс, то не факт, что он просто так должен что-то выдавать пока его не попросишь.
Цитата(Dimonira @ Feb 15 2005, 11:33)
Мужики, вы, похоже так и не поняли. Дело не в умении программировать хост компьютер для обмена по последовательному порту. Поэтому что толку предлагать разные либы и пакеты.
Дело в том, что, видимо, порт контроллера полудуплексный. Т.е. он может в один момент времени либо передавать, либо принимать. Так вот он изначально стоит на приём. Для переключения его на передачу (как я думаю) ему, видимо, надо послать нужную команду, в ответ на которую контроллер что-то выдаст. Просто так он сам, похоже только принимает данные, поэтому передавая ему просто всякую ересь (для тестирования обмена), ответа от него не дождётесь. Надо поддержать протокол, т.е. читать инфу по контроллеру.
Даже если у контроллера полный дуплекс, то не факт, что он просто так должен что-то выдавать пока его не попросишь.
Да, но речь-то идет о
ПРОГРАММАТОРЕ! И, насколько я понимаю, инициатором обмена информацией с программируемым устройством должен быть в данном случае именно программатор. А он этого не делает. Кроме того, автор темы пишет, что под ДОС и Win9x он у него работает (или работал и уже не работает? - если уже не работает, тогда действительно, надо разбираться с железякой). А проблемы возникли под NT, что закономерно, т.к. NT не позволяет (без драйверов, нормальных, которых нет, или "псевдо") работать напрямую с портами. Точнее, не с самими COM портами, а с их управляющими регистрами. А именно так и работает (судя по написанному в теме) программка для этого программатора.
Лучше, пожалуй, действительно не морочить себе голову, а работать с ней так, как и работали - из-под ДОС-а.
Как автор подтопика о программаторе, уточню. Не работает он потому, что писался по канонам хорошего программирования КОМ портов под ДОС. Т.е кроме работы с регистрами UART, он еще работает с регистрами контроллера прерываний- ставит свой обработчик хардверного IRQ 3/4. Если работу с портами UART многие драйвера КОМ устройств для 2000, XP,'эмулируют корректно ( даже некоторые USB ком порты ставили виртуализатор хардвари, и досовые проги вполне корректно с ними работали), то к контроллеру прерываний XP понятное дело не пускает.
Все это выяснено при дизасме управляющей программы. Теперь осталось два пути - первое- патчить прогу на предмет обращения к Вин API. Но я не настолько крут в хакинге, чтобы вызвать 32 разрядный API из 16-битного DOS DPMI приложения. Хотя это и возможно.
Второе - переписывать целиком управляющую прогу. Что успешно делаеться - переписано несколько ( из сотен) микросхем под винду. Основная проблема- снятие и расшифровка лога обмена между программатором и компом. Он, зараза, может одновременно передавать и принимать данные. А снифера/мониторы Кома под ДОС не работают. Соответственно приходиться писать протокол двумя портами на дополнительном компе. А потом этот лог разгребать для каждой микросхемы в программаторе.
Dimonira
Feb 16 2005, 11:23
Я как-то пропустил слова о реверс-инжиниринге.
Тогда всё понятно. Ломаете чужую IP.
В вашем случае по-моему проще снять протокол обмена, понять его, а дальше наваять свою программу.
Serjio
Feb 17 2005, 08:01
Мы пользуемся CPORT под все Windows
-Tумблер-
Feb 17 2005, 18:40
Цитата(khach @ Feb 15 2005, 13:11)
Не работает он потому, что писался по канонам хорошего программирования КОМ портов под ДОС. Т.е кроме работы с регистрами UART, он еще работает с регистрами контроллера прерываний ... к контроллеру прерываний XP понятное дело не пускает.
Это не так.
Лично проверил это:
WinNT-4
WinXP Prof RUS
WinXp Rpof ENG
Win2003 Server Enterp. Edition
С компами - notebook какой-то там P~100, PII-300, Celeron-1100,
PIV~2,66 ДОС-программа с КОМ-портами по прерываниям РАБОТАЕТ !
Мало того - эта программа еще и лезет нагло в видеопамять - и все OK.
Чтобы не обманывать научно-техническую общественность зазря,
привожу сами программы (программа-терминал + драйвер),
файлы "read.me" и все исходные тексты.
http://spiprog.chat.ru/comdos.zipили
http://spiprog.narod.ru/comdos.zip Программа не просто как то там тестировалась - к ком-порту
цеплялся осциллограф. На предмет проверки соответствия
летящих байтов, скоростей, стопов и стартов.
Все OK по полной программе.
может кому пригодиться h__p://www.rs232.ru/
PowerF1
Mar 18 2005, 15:59
Подскажите, у меня такая проблема.
Когда собирал мк, написал прогу(а точне собрал уз кусочков) обмена информацией чз СОМ-порт. Это была передача в мк по нажатию клавиши и следом прием. т.е. при обработке сообщения WV_CHAR.
Никаких проблем, винда определила, что нажата клавиша, остается только отослать и принять данные. Так я оттестил мк, все работало.
Сейчас стоит другой вопрос. Мк должен только посылать данные на комп.А как их принимать я не знаю. Какое сообщение использовать, когда данные пришли? Может кто знает?
Мне говорили что-то про пользовательское сообщение. Как можно разрулить с ним?
Программируй на C++Builder - меньше заморачиваться с сообщениями будешь.
Судя по всему интересует асинхронное получение данных по COM порту. Пользовательское сообщение использовать можно, но судя по постановке задачи, опыта у тебя маловато. Не в обиду, хочу как лучше.
пользовательские сообщения описываешь, например, так:
#define MY_MSG (WM_APP+10)
заводишь поток(CreateThread), в котором читаешь COM порт (ReadFile). Операция чтения не должна быть OVERLAPPED! По получению данных, ReadFile разблокируется, вызывай тогда PostMessage(MY_MSG) или PostThreadMessage(MY_MSG), в зависимости от того, куда хочешь послать сообщение (окну или потоку). В том месте программы, где обрабатываешь WM_CHAR добавь обработку MY_MSG. Короче, данные из COM порта читаешь в одном потоке, а обрабатываешь в другом.
Можешь поступить проще - работать по таймеру.
1) Заводишь таймер (SetTimer), указывая хэндл своего окна.
2) В том месте, где обрабатываешь WM_CHAR, добавляешь обработку WM_TIMER. Обработка заключается в вызове ReadFile. ReadFile должен быть в этом случае overlapped, иначе он заблокирует твой поток до наступления таймаута, указанного при инициализации драйвера COM порта (SetCommTimeouts).
Уф! И да прибудет с тобой MS Win32 SDK...
Lukomor
Mar 28 2005, 07:40
Подскажите пожалуйста! Есть проблема работы с СОМ из под W2K с прямым доступом. Пробовал различные драйвера giveio/userport/porttalk/totalio - безуспешно. Данные в порт (0х3F8) уходят, но на выходе не появляются (проверял осциллографом). При запуске из w98 все работает (хотя там драйвера эти не нужны). К сожалению не могу перейти на WINAPI - протокол обмена конечного устройства не позволяет (из-за временнЫх задержек). Может кто с такой ситуацией сталкивался?
Если протокол связи накладывает жесткие временные ограничения (самый жесткач это ответ PC по запросу внешнего устройства через маленькое время), то спасет только собственный драйвер. Если под 98 задача решается, то под 2к при помощи своего драйвера ее тоже можно решить. Самые быстрые варианты управления COM-портом, в порядке возрастания (по собственным ощущениям):
1) DOS на СИ или ASMе

2) WinNT, 2k, XP с собственным драйвером
3) Win95/98 с дос программой
4) Win API
5) WinNT, 2k, XP с DOS программой (работа с портами напрямую)
5й вариант самый медленный из-за приема данных. Данные-то надо забирать из фифо по прерываниям, а они до VDM (VirtualDosMashine) могут долго доезжать. В виндовом приложении чтение можно организовать только полингом регистра статуса (LSR). Оно тебе надо? Это ж тормоза 100%, а на большой скорости данные теряться будут.
Если не переубедил - я бы выгрузил стандартный драйвер 2k, настроил порт как в дос, и молотил бы в 0х3F8. Только не понятно зачем это все нужно (запуск дос программ под 2к или в виндовых приложениях).
Если протокол опишешь(где какие минимальные задержки), может подскажу как на WinAPI задачку решить, если это вообще реально сделать.
-Tумблер-
Mar 28 2005, 11:05
Цитата(_VM @ Mar 23 2005, 20:01)
заводишь поток(CreateThread), в котором читаешь COM порт (ReadFile).
Можно лишь добавить - пишем в COM-порт из того же потока - WriteFile.
(Когда нужно- когда появились данные для вывода).
При этом эти операции выполняются строго
по-очередно. А иначе - при попытке читать/писать из разных
потоков получаются "полные раки".
А для отладки софта, работающего с СОМ под Windows, иногда удобно использовать драйвер виртуальных СОМ портов
Virtual Serial Ports DriverОн позволяет создать нужное количество пар COM портов , соедининенных виртуальными кабелями типа "null-modem". Виртуальные СОМ порты с точки зрения софта ничем не отличаются от реальных.
Цитата(-Tумблер- @ Mar 28 2005, 14:05)
Цитата(_VM @ Mar 23 2005, 20:01)
заводишь поток(CreateThread), в котором читаешь COM порт (ReadFile).
Можно лишь добавить - пишем в COM-порт из того же потока - WriteFile.
(Когда нужно- когда появились данные для вывода).
При этом эти операции выполняются строго
по-очередно. А иначе - при попытке читать/писать из разных
потоков получаются "полные раки".

А я что-то не соображу, почему из 2-х разных потоков одновременно читать/писать неполучится

. Вот если из 2-х потоков одновременно писать захочется, то да - понадобится синхронизацию реализовывать. А при разделенных записи/чтении в чем проблема?
Lukomor
Mar 29 2005, 05:36
Спасибо _VM за ответ.
Цитата(_VM @ Mar 28 2005, 12:19)
...
1) DOS на СИ или ASMе

2) WinNT, 2k, XP с собственным драйвером
3) Win95/98 с дос программой
4) Win API
5) WinNT, 2k, XP с DOS программой (работа с портами напрямую)
...
Варианты 1, 3, к сожалению, не подходят.
2 вариант - немного не понял. Что значит "с собственным драйвером"? Если это с использованием недокументированных I/O функций WINAPI, то это уже имело место быть в giveio и т.д.
Вариант 4 пробовал. При реализации на С++ с WINAPI (CreateFile + DCB + ...)
- не успеваю по протоколу.
Насчет 5, из DOSa, (я так понимаю что из консоли) заморочка для меня будет большая, так как основное приложение WIN32.
Я пробую в виндовское оконное приложение воткнуть команды ассемблера для прямой работы с портом, а чтобы не "орала" защита гружу giveio. Причем конфигурирую порт таким же образом, как в ДОСе. Все что посылаю при этом в 0x3F8...0x3FE уходит "в пустоту"
Чтение 0x3F8 возвращает ранее записанное туда слово (на выходе порта по прежнему ничего не появляется!), а чтение остальных 0x3F_ возвращает FF.
Цитата(_VM @ Mar 28 2005, 12:19)
... я бы выгрузил стандартный драйвер 2k, настроил порт как в дос, и молотил бы в 0х3F8...
Возможно, это как раз то, что нужно. Если можно расскажи подробнее.
Цитата(_VM @ Mar 28 2005, 12:19)
...
Если протокол опишешь(где какие минимальные задержки), может подскажу как на WinAPI задачку решить, если это вообще реально сделать.
...
В протоколе 2 "засады":
1) от передачи командного слова от PC до ответного слова устройства - 15...40 мкс.
2) от передачи командного слова от устройства до ответного слово от PC 11 мс.
Буду благодарен за помощь!
-Tумблер-
Mar 29 2005, 06:04
Цитата(_VM @ Mar 29 2005, 03:20)
А я что-то не соображу, почему из 2-х разных потоков одновременно читать/писать неполучится
Честно говоря - я тоже. И был бы рад и благодарен,
если бы мне обьяснили - почему.
Для меня это было неприятным сюрпризом.
Но опытным путем удалось установить:
Под:
WIN95 - никаких проблем.
WIN98 - становится неустойчиво
WINXP - система виснет так, что только аппаратный сброс.
Используя беседы в конфах, удалось выяснить, что не только
у меня так.
То ли это ошибки библиотек компиляторов (Рихтер весьма
прозрачно намекает об этом для VC). То ли это особенности ОС.
Я полагаю - возможно и то, и другое.
Собственно, это не мешает, если знаешь.
Один поток делает ReadFile, проверяет - есть ли для вывода,
если есть - WriteFile.
Иначе мне сделать не удалось.
-Tумблер-
Mar 29 2005, 07:35
Цитата(Lukomor @ Mar 29 2005, 08:36)
В протоколе 2 "засады":
1) от передачи командного слова от PC до ответного слова устройства - 15...40 мкс.
2) от передачи командного слова от устройства до ответного слово от PC 11 мс.
Полагаю, с пунктом 1 "API вариант" точно должен справится - почему нет ?
Не помню такого, что бы драйвер COM порта у WIN не принял
правильно данные даже на самой большой скорости и на не очень
сильном компьютере.
Со вторым пунктом действительно могут быть проблемы.
Тут можно попытаться:
1. поднять приоритет потока приложения повыше . Как можно выше и
не запускать другие приложения.
2. отрихтовать вручную (это для win98 - для XP сам смотри как там..):
пуск-настройка-панель управления-система-устройства-последовательный порт (1?)-свойства-настройка порта-дополнительно-буфер приема =1-OK.
Lukomor
Mar 29 2005, 09:22
Цитата(-Tумблер- @ Mar 29 2005, 10:35)
1. поднять приоритет потока приложения повыше . Как можно выше и
не запускать другие приложения.
2. отрихтовать вручную (это для win98 - для XP сам смотри как там..):
пуск-настройка-панель управления-система-устройства-последовательный порт (1?)-свойства-настройка порта-дополнительно-буфер приема =1-OK.
Настройка вручную порта из виндов не помогает - все равно не успеваю.
Насчет приоритета потока, насколько я понял, все не так просто. Вот здесь есть переводная статья
http://www.void.ru/?do=printable&id=701 ,правда по прямому доступу к порту, но основа там разложена хорошо.
Проблема в том, что у меня не работает (или я неправильно им пользуюсь) драйвер прямого доступа, хотя делал все по мануалу, включая ассемблерный код.
PowerF1
Mar 29 2005, 14:41
_WM, боьшое спасибо за ценную информацию!
Разобрался(на моем уровне) с потоками. Многие вещи стали понятны. Установка маски и ожидание события действительно очень удобны при работе с потоками. Но все же вопрос ткаой остался, не знаю корректный ли он. Как распределяются ресурсы по потокам? выставляются приоритеты?
На счет ввода/вывода в одном потоке. Свою программу писал под 98 и вывод производился в основном потоке, при нажатиии клавиши. Ввод, по совету _WM, я загнал в отдельный поток. Такая комбинация под 98 работает, под XP не хочет. Может конечно не в этом дело.
-Tумблер-
Mar 30 2005, 10:53
Цитата(PowerF1 @ Mar 29 2005, 17:41)
Как распределяются ресурсы по потокам? выставляются приоритеты?
Попробуй почитать это:
http://club.shelek.com/download.php?id=239Хотя лично мне в этой книге не все понравилось, но тем не менее
это одна из самых лучших книг.
Цитата(PowerF1 @ Mar 29 2005, 17:41)
На счет ввода/вывода в одном потоке. Свою программу писал под 98 и вывод производился в основном потоке, при нажатиии клавиши. Ввод, по совету _WM, я загнал в отдельный поток. Такая комбинация под 98 работает, под XP не хочет.
У меня было то же самое.
Скорее всего, поможет и ввод и вывод организовать в одном потоке.
-Tумблер-
Mar 30 2005, 11:52
Цитата(Lukomor @ Mar 29 2005, 12:22)
Настройка вручную порта из виндов не помогает - все равно не успеваю.
А в цифрах - это сколько получилось ?
Как я понял, нужно 10 ms.
И насколько большой выходит "перебор" ?
2Lukomor
Цитата(Lukomor @ Mar 29 2005, 08:36)
2 вариант - немного не понял. Что значит "с собственным драйвером"? Если это с использованием недокументированных I/O функций WINAPI, то это уже имело место быть в giveio и т.д.
С собственным драйвером, это значит с собственноручно написанным драйвером устройства, в котором делается обработка командных слов. Драйвер - грубо говоря, приложение работающее в контексте ядра, обладающее любыми возможностями для работы с аппаратурой.
11 мс это очень маленький интервал для Win приложения, увеличения приоритетов может не помогут. Логично предположить, что данные внешнему устройству нужно отправлять в обработчике прерывания COM-порта (сразу после получения командного слова). Сделать это можно только написав свой драйвер. Засада может быть одна - сложная (длительная) обработка командного слова в PC. Win не любит, когда драйвер много времени отжирает.
Цитата(Lukomor @ Mar 29 2005, 08:36)
Я пробую в виндовское оконное приложение воткнуть команды ассемблера для прямой работы с портом, а чтобы не "орала" защита гружу giveio.
Да я это понял:
Цитата(_VM @ Mar 28 2005, 12:19)
В виндовом приложении чтение можно организовать только полингом регистра статуса (LSR). Оно тебе надо? Это ж тормоза 100%, а на большой скорости данные теряться будут.
Вариант, по моему, тупиковый

Даже если ты и получишь доступ из виндового приложения к портам, как ты будешь узнавать, что данные поступили, т.е. в какой момент надо читать 0x3f8? Под ДОС все просто, либо прерывания по приему данных обрабатывай, либо регистр статуса (LSR) опрашивай (в нем есть бит, означающий наличие непрочитанных данных). В винде прерывания только в драйвере обработать можно. В пользовательском приложении(не драйвере) опрос(полинг) LSR может в любой момент прерваться по той же причине, по которой ты не успеваешь в WinAPI (многозадачность). Спасти может только наличие фифо буфера в UART.
Пуск->настройка->панель упр->система->оборудование->дисп.устройств->порты COM и LPT. Для выгрузки драйвера удали COM порт как устройство.
Далее не перезагружаясь запускай свою программу. Программа должна проинициализировать COM порт, а потом в цикле писать в 3f8. В общем все как под ДОС. Глупый вопрос, может ты данные не на том пине смотришь?
Увеличение приоритета меня порой спасало.
Для увеличение приоритета:
Приложения : SetPriorityClass() с GetCurrentProcessId()
Потока: SetThreadPriority() c GetCurrentThreadId();
Причем важно увеличивать приоритет не только приложения, но и потока в котором делаешь ReadFile()!!!
Для просмотра полной версии этой страницы, пожалуйста,
пройдите по ссылке.