Работа с СОМ портом, Win2000 Опции

[uvw]

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

[IgorKossak]

Попробуйте следуюшее в прикреплённом файле.
У меня под Win2000 получалось.

Прикрепленные файлы

 com_win32.rar ( 27.65 килобайт ) Кол-во скачиваний: 801

 

[uvw]

Спасибо, но эту статью я недавно читал (на сайте www.rs232.ru) но, дело в том, что я никак не могу получить вообще ничего от контроллера... Я пробовал событийную модель(с помощью Overlapped и WaitCommEvent) с различными масками. Как поется, "Крикну, а в ответ - тишна"...
Тут вопрос стоит в прямом обращении к порту, а это возможно только при наличии соответстующего драйвера(во всяком случае, в Win200/XP и им подобным) Для написания драйвера, посоветовали использовать WinDriver...
Если кто ее использовал при работе с СОМ портом, подскажите плизз!!!

[IgorKossak]

Зачем такие сложности с прямым доступом если и через API всё прекрасно работает?
Вы видимо не очень тщательно разобрались. Я делал всё как сказано в статье и всё получилось и под Win98 и под Win2000.

[uvw]

Могу привести исходник на паскале, присланный разработчиками железки, и свой, на С++ который пытаюсь переписать с паскалевской и перевести на WinAPI... Был бы благодарен, если укжете в чем ошибка...

[veter]

а вы попробуйте RxD и TxD закоротить, и отправить в порт чтенить.
если ничего не приниматься не будет - проверьте настройку DCB структуры, у меня было что в настройках проверку DSR , CTS , RTS или DTR отключить надо. давно было не могу сказать что точно. но история таже - в 98 работало, а в 2к нет. потом все пучком стало

О!!! нашел

fDsrSensitivity = NULL
Задает чувствительсть коммуникационного драйвера к состоянию линии DSR. Если это поле равно TRUE, то все принимаемые данные игнорируются драйвером (коммуникационный драйвер расположен в операционной системе), за исключением тех, которые принимаются при установленом сигнале DSR.

его в ноль,

fDtrControl = DTR_CONTROL_DISABLE и fRtsControl = RTS_CONTROL_DISABLE
По идее дожно зафурыкать.

[uvw]

Фуухх, я уже окончательно запутался....
выкладываю настройку 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

Может кто что подскажет....

[veter]

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: включи аську

[uvw]

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

[veter]

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

[uvw]

veter, Давай, буду очень признателен
присылай на uvw@ua.fm or _prog@ua.fm
если что придумается... я в аське (почти круглосуточно) ICQ# 342610002

[DPL]

а вот что происходит в паскале...

Код

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

Не в этом ли дело? Может, в Вашем примере для Win преобразователь RS232/485 все время на передачу работает? Я, правда, назначение портов UART не помню, поэтому сходу не скажу, как то же самое можно сделать в WinAPI. Если нужно, могу выслать исходники на Паскале (Delphi), где у меня реализована связь с контролером (правда, используется только TxD и RxD, управления преобразователем нет).

[Shedon]

Здесь есть класс для работы с ком портом, у меня через него всё работает.

[khach]

При порты в прикладной программе забудьте- это привелегия драйверов (vxd, sys). Вот хороший компонент для Дельфей с примерами. Работает на всем, и на USB переходниках тоже.
RS485 к сожалению под Виндой работает отвратительно. И переключать направление из программы корректно неполучится. Т.к. физическая передача в порт разнесена по времени с вызовом WriteFile, то даже ESC команды не переключат направление RS485 вовремя.
Если скорость постоянна, то направление можно переключать одновибратором в разъеме. Хотя более эффективное решение- маленькая схема на AT89c2051. Там же делали и опторазвязку.

Прикрепленные файлы

 cport_3.0.zip ( 210.06 килобайт ) Кол-во скачиваний: 642

 

[Shedon]

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

[khach]

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

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

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

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

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

[andk]

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

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

[khach]

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

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

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

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

[uvw]

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

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

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

Прикрепленные файлы

 RS232_485.pdf ( 136.15 килобайт ) Кол-во скачиваний: 487

 

[andk]

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

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

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

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

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

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

[-Tумблер-]

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

Сам проверял - в NT и в XP DOS программа работает с COM - портами
по прерываниям. Почему так получается - не знаю, но это факт.
Возможно у Вас прога "кривая". Везде то ей "плохо".

Что касается DOS-машины, можно ДОС грузить с CD-ROMа.
Только вот 32 FAT она не увидит. Надо FAT 16.

[one_man_show]

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

[Dimonira]

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

[_Sam_]

При установке 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

 

[SergM]

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

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

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

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

Успехов!

Прикрепленные файлы

 Glava9_3.ZIP ( 489.02 килобайт ) Кол-во скачиваний: 505

 

[makc]

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

Прикрепленные файлы

 IO_Ports.rar ( 36.74 килобайт ) Кол-во скачиваний: 413

 

[andk]

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

[SergM]

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

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

[Dimonira]

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

[SergM]

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

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

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

[khach]

Как автор подтопика о программаторе, уточню. Не работает он потому, что писался по канонам хорошего программирования КОМ портов под ДОС. Т.е кроме работы с регистрами UART, он еще работает с регистрами контроллера прерываний- ставит свой обработчик хардверного IRQ 3/4. Если работу с портами UART многие драйвера КОМ устройств для 2000, XP,'эмулируют корректно ( даже некоторые USB ком порты ставили виртуализатор хардвари, и досовые проги вполне корректно с ними работали), то к контроллеру прерываний XP понятное дело не пускает.
Все это выяснено при дизасме управляющей программы. Теперь осталось два пути - первое- патчить прогу на предмет обращения к Вин API. Но я не настолько крут в хакинге, чтобы вызвать 32 разрядный API из 16-битного DOS DPMI приложения. Хотя это и возможно.
Второе - переписывать целиком управляющую прогу. Что успешно делаеться - переписано несколько ( из сотен) микросхем под винду. Основная проблема- снятие и расшифровка лога обмена между программатором и компом. Он, зараза, может одновременно передавать и принимать данные. А снифера/мониторы Кома под ДОС не работают. Соответственно приходиться писать протокол двумя портами на дополнительном компе. А потом этот лог разгребать для каждой микросхемы в программаторе.

[Dimonira]

Я как-то пропустил слова о реверс-инжиниринге.
Тогда всё понятно. Ломаете чужую IP.
В вашем случае по-моему проще снять протокол обмена, понять его, а дальше наваять свою программу.

[Serjio]

Мы пользуемся CPORT под все Windows

Прикрепленные файлы

 cport_3.0.zip ( 210.06 килобайт ) Кол-во скачиваний: 907

 

[-Tумблер-]

Не работает он потому, что писался по канонам хорошего программирования КОМ портов под ДОС. Т.е кроме работы с регистрами 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 по полной программе.

[Angel]

может кому пригодиться h__p://www.rs232.ru/

[PowerF1]

Подскажите, у меня такая проблема.
Когда собирал мк, написал прогу(а точне собрал уз кусочков) обмена информацией чз СОМ-порт. Это была передача в мк по нажатию клавиши и следом прием. т.е. при обработке сообщения WV_CHAR.
Никаких проблем, винда определила, что нажата клавиша, остается только отослать и принять данные. Так я оттестил мк, все работало.
Сейчас стоит другой вопрос. Мк должен только посылать данные на комп.А как их принимать я не знаю. Какое сообщение использовать, когда данные пришли? Может кто знает?
Мне говорили что-то про пользовательское сообщение. Как можно разрулить с ним?

[_VM]

Программируй на 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]

Подскажите пожалуйста! Есть проблема работы с СОМ из под W2K с прямым доступом. Пробовал различные драйвера giveio/userport/porttalk/totalio - безуспешно. Данные в порт (0х3F8) уходят, но на выходе не появляются (проверял осциллографом). При запуске из w98 все работает (хотя там драйвера эти не нужны). К сожалению не могу перейти на WINAPI - протокол обмена конечного устройства не позволяет (из-за временнЫх задержек). Может кто с такой ситуацией сталкивался?

[_VM]

Если протокол связи накладывает жесткие временные ограничения (самый жесткач это ответ 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умблер-]

заводишь поток(CreateThread), в котором читаешь COM порт (ReadFile).

Можно лишь добавить - пишем в COM-порт из того же потока - WriteFile.
(Когда нужно- когда появились данные для вывода).
При этом эти операции выполняются строго
по-очередно. А иначе - при попытке читать/писать из разных
потоков получаются "полные раки".

[SergM]

А для отладки софта, работающего с СОМ под Windows, иногда удобно использовать драйвер виртуальных СОМ портов Virtual Serial Ports Driver

Он позволяет создать нужное количество пар COM портов , соедининенных виртуальными кабелями типа "null-modem". Виртуальные СОМ порты с точки зрения софта ничем не отличаются от реальных.

[_VM]

заводишь поток(CreateThread), в котором читаешь COM порт (ReadFile).

Можно лишь добавить - пишем в COM-порт из того же потока - WriteFile.
(Когда нужно- когда появились данные для вывода).
При этом эти операции выполняются строго
по-очередно. А иначе - при попытке читать/писать из разных
потоков получаются "полные раки".

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

[Lukomor]

Спасибо _VM за ответ.

...
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.

... я бы выгрузил стандартный драйвер 2k, настроил порт как в дос, и молотил бы в 0х3F8...

Возможно, это как раз то, что нужно. Если можно расскажи подробнее.

...
Если протокол опишешь(где какие минимальные задержки), может подскажу как на WinAPI задачку решить, если это вообще реально сделать.
...

В протоколе 2 "засады":
1) от передачи командного слова от PC до ответного слова устройства - 15...40 мкс.
2) от передачи командного слова от устройства до ответного слово от PC 11 мс.

Буду благодарен за помощь!

[-Tумблер-]

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

Честно говоря - я тоже. И был бы рад и благодарен,
если бы мне обьяснили - почему.
Для меня это было неприятным сюрпризом.
Но опытным путем удалось установить:
Под:
WIN95 - никаких проблем.
WIN98 - становится неустойчиво
WINXP - система виснет так, что только аппаратный сброс.
Используя беседы в конфах, удалось выяснить, что не только
у меня так.
То ли это ошибки библиотек компиляторов (Рихтер весьма
прозрачно намекает об этом для VC). То ли это особенности ОС.
Я полагаю - возможно и то, и другое.
Собственно, это не мешает, если знаешь.
Один поток делает ReadFile, проверяет - есть ли для вывода,
если есть - WriteFile.
Иначе мне сделать не удалось.

[-Tумблер-]

В протоколе 2 "засады":
1) от передачи командного слова от PC до ответного слова устройства - 15...40 мкс.
2) от передачи командного слова от устройства до ответного слово от PC 11 мс.

Полагаю, с пунктом 1 "API вариант" точно должен справится - почему нет ?
Не помню такого, что бы драйвер COM порта у WIN не принял
правильно данные даже на самой большой скорости и на не очень
сильном компьютере.

Со вторым пунктом действительно могут быть проблемы.
Тут можно попытаться:
1. поднять приоритет потока приложения повыше . Как можно выше и
не запускать другие приложения.
2. отрихтовать вручную (это для win98 - для XP сам смотри как там..):
пуск-настройка-панель управления-система-устройства-последовательный порт (1?)-свойства-настройка порта-дополнительно-буфер приема =1-OK.

[Lukomor]

1. поднять приоритет потока приложения повыше . Как можно выше и
не запускать другие приложения.
2. отрихтовать вручную (это для win98 - для XP сам смотри как там..):
пуск-настройка-панель управления-система-устройства-последовательный порт (1?)-свойства-настройка порта-дополнительно-буфер приема =1-OK.

Настройка вручную порта из виндов не помогает - все равно не успеваю.
Насчет приоритета потока, насколько я понял, все не так просто. Вот здесь есть переводная статья http://www.void.ru/?do=printable&id=701 ,правда по прямому доступу к порту, но основа там разложена хорошо.

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

[PowerF1]

_WM, боьшое спасибо за ценную информацию!
Разобрался(на моем уровне) с потоками. Многие вещи стали понятны. Установка маски и ожидание события действительно очень удобны при работе с потоками. Но все же вопрос ткаой остался, не знаю корректный ли он. Как распределяются ресурсы по потокам? выставляются приоритеты?
На счет ввода/вывода в одном потоке. Свою программу писал под 98 и вывод производился в основном потоке, при нажатиии клавиши. Ввод, по совету _WM, я загнал в отдельный поток. Такая комбинация под 98 работает, под XP не хочет. Может конечно не в этом дело.

[-Tумблер-]

Как распределяются ресурсы по потокам? выставляются приоритеты?

Попробуй почитать это:
http://club.shelek.com/download.php?id=239
Хотя лично мне в этой книге не все понравилось, но тем не менее
это одна из самых лучших книг.

  На счет ввода/вывода в одном потоке. Свою программу писал под 98 и вывод производился в основном потоке, при нажатиии клавиши. Ввод, по совету _WM, я загнал в отдельный поток. Такая комбинация под 98 работает, под XP не хочет.

У меня было то же самое.
Скорее всего, поможет и ввод и вывод организовать в одном потоке.

[-Tумблер-]

Настройка вручную порта из виндов не помогает - все равно не успеваю.

А в цифрах - это сколько получилось ?
Как я понял, нужно 10 ms.
И насколько большой выходит "перебор" ?

[_VM]

2Lukomor

2 вариант - немного не понял. Что значит "с собственным драйвером"? Если это с использованием недокументированных I/O функций WINAPI, то это уже имело место быть в giveio и т.д.

С собственным драйвером, это значит с собственноручно написанным драйвером устройства, в котором делается обработка командных слов. Драйвер - грубо говоря, приложение работающее в контексте ядра, обладающее любыми возможностями для работы с аппаратурой.
11 мс это очень маленький интервал для Win приложения, увеличения приоритетов может не помогут. Логично предположить, что данные внешнему устройству нужно отправлять в обработчике прерывания COM-порта (сразу после получения командного слова). Сделать это можно только написав свой драйвер. Засада может быть одна - сложная (длительная) обработка командного слова в PC. Win не любит, когда драйвер много времени отжирает.

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

Да я это понял:

В виндовом приложении чтение можно организовать только полингом регистра статуса (LSR). Оно тебе надо? Это ж тормоза 100%, а на большой скорости данные теряться будут.

Вариант, по моему, тупиковый Даже если ты и получишь доступ из виндового приложения к портам, как ты будешь узнавать, что данные поступили, т.е. в какой момент надо читать 0x3f8? Под ДОС все просто, либо прерывания по приему данных обрабатывай, либо регистр статуса (LSR) опрашивай (в нем есть бит, означающий наличие непрочитанных данных). В винде прерывания только в драйвере обработать можно. В пользовательском приложении(не драйвере) опрос(полинг) LSR может в любой момент прерваться по той же причине, по которой ты не успеваешь в WinAPI (многозадачность). Спасти может только наличие фифо буфера в UART.

Пуск->настройка->панель упр->система->оборудование->дисп.устройств->порты COM и LPT. Для выгрузки драйвера удали COM порт как устройство.
Далее не перезагружаясь запускай свою программу. Программа должна проинициализировать COM порт, а потом в цикле писать в 3f8. В общем все как под ДОС. Глупый вопрос, может ты данные не на том пине смотришь?

Увеличение приоритета меня порой спасало.
Для увеличение приоритета:
Приложения : SetPriorityClass() с GetCurrentProcessId()
Потока: SetThreadPriority() c GetCurrentThreadId();
Причем важно увеличивать приоритет не только приложения, но и потока в котором делаешь ReadFile()!!!

[_VM]

2-Tумблер-&PowerF1&Lukomor
Проблем с разными потоками под XP не испытывал.
Отрываю от сердца самописный пример под ц++дебилдер 6.0
Он, по моему, работал на всем, что только можно.
В одном потоке нон-стопом льет данные в коматоз, в другом потоке из этого же кома принимает. Софтина задумывалась как тестер канала связи. Динамически снижает скорость при появлении ошибок.
Для проверки замкнуть пины RX и TX.
Глючит при закрытии, если не приняла ни одного байта.
Кто будет запускать exe - проверте на вирусы, я антивирусами не пользуюсь.
Исходники предоставляю для ознакомления, просьба ими не раскидываться.


о п с .... старая версия только есть. завтра с работы нормальную принесу.

[Lukomor]

А в цифрах - это сколько получилось ?
Как я понял, нужно 10 ms.
И насколько большой выходит "перебор" ?

По грубой оценке около 30-40 ms.

[Lukomor]

2_VM

Пуск->настройка->панель упр->система->оборудование->дисп.устройств->порты COM и LPT. Для выгрузки драйвера удали COM порт как устройство.
Далее не перезагружаясь запускай свою программу. Программа должна проинициализировать COM порт, а потом в цикле писать в 3f8. В общем все как под ДОС. Глупый вопрос, может ты данные не на том пине смотришь?

Увеличение приоритета меня порой спасало.
Для увеличение приоритета:
Приложения : SetPriorityClass() с GetCurrentProcessId()
Потока: SetThreadPriority() c GetCurrentThreadId();
Причем важно увеличивать приоритет не только приложения, но и потока в котором делаешь ReadFile()!!!

Спасибо за совет, обязательно попробую, но чувствую придется мне писать драйвер.
Пин вроде тот - проверял в W98 - передача идет.

2All
Никто случайно не знает, где в сети можно найти информацию по написанию драйверов на простеньком уровне? Потому как дело это для меня совсем новое.

[_VM]

Если владеешь C++ поищи Numega Driver Studio (софт коммерческий). Она с документацией идет. Для твоей задачи ненадо глубоко вникать в архитектуру виндов, а нумега ее внутри своих C++ классов скрывает. В общем я с нее начинал и доволен.

Но я бы на винапи еще подолбился бы. С драйвером конечно интереснее и надежнее, но разобраться не быстро получится.

[max123]

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

Привет.
Может быть мой ответ устарел
Попробуй проверить свою программу так.

Соедени Com порты(Com1 , Com2) своей персоналки через нуль - модемный кабель.
Распайка
2-3
3-2
5-5
6 6
| |
4 4
7 7
| |
8 8
Запусти гипертерминал для Com2 в Win2000 и поставь настройки Com2
такие как в твоей программе для опроса контроллера.
Запусти свою программу для Com1 попробуй опросить контроллер.
Если программа что то кидает на Com1 то ты увидишь это в гипертерминале,
т.е. ты убедишься что у тебя программа что то посылает.


Так же я тебе могу предложить библиотеку программирования для COm
портов, если ты ее используешь то в программировании много знать не надо
она работает и под win2000 и под win98 (С ,VC, BC, VB)
ее можно скачать на www.webfile.ru
Файл номер 240397, pcommpro20.rar (размер 652 кбайт)




Пример:
int port = 2;

//настроить COM2 38400 8 бит данных 1 стоповый
ret = sio_ioctl ( 2, B38400, P_NONE | BIT_8 | STOP_1 );

if (ret != SIO_OK) {
/* Setting fail */
}


Нужно еще DTR поднять посмотри функцию в хелпе

ret = sio_open (port); //Открыть COM2
if ( ret != SIO_OK ) {
/* Open fail */
}
int len;
char buf[10];
len = sio_read( 2, buf, 10); //прочитать 10 байт с COM2
if (ch < 0) {
/* Fail */
}

[-Tумблер-]

А в цифрах - это сколько получилось ?
Как я понял, нужно 10 ms.
И насколько большой выходит "перебор" ?

По грубой оценке около 30-40 ms.

Сегодня я ноконец померил - и вот что получилось:

При работе с одним потоком на прием и передачу - ~6 ms на ответ.
Если поток имеет приоритет NORMAL действительно, его прерывают
и иногда выходит ~30ms. Хотя и редко, это бывает.
Если поставить приоритет этому потоку Тайм_Критикал, то ему
никто особенно не мешает. Кроме ~6ms других значений времени
не зафиксировано.
Система была WIN98, PII-300, VC6+API ONLY.
Ничего особенно навороченного..
В качестве темплате использовалось готовое приложение
с двумя потоками - основной Нормал+2 и еще рабочий Нормал.
Под WIN-XP измерять буду завтра...

[-Tумблер-]

Под WIN-XP измерять буду завтра...
 

Так вышло, что измерил сейчас.
Получилось то же самое ~6ms на ответ.
Все то же самое.

Вполне вероятно, можно обойтись без драйверов
и лазания в порты.

[Lukomor]

Под WIN-XP измерять буду завтра...
 

Так вышло, что измерил сейчас.
Получилось то же самое ~6ms на ответ.
Все то же самое.

Вполне вероятно, можно обойтись без драйверов
и лазания в порты.

2-Тумблер-
Спасибо, я действительно поигрался с приоритетами и потоками, вроде получилось, но проблема была в другом, "поймать" ответ устройства. Ответ приходит через ~11 мкс после запроса, при этом обмен идет через интерфесный девайс. От компьютера до девайса RS232 с управлением RTS, от девайса до устройства 485 интерфейс без управления потоком. Мне надо успеть вручную переключить RTS. Для работы с портом выставляю REALTIME_PRIORITY_CLASS и THREAD_PRIORITY_TIME_CRITICAL. С натягом, но все успеваю.

[-Tумблер-]

Для работы с портом выставляю REALTIME_PRIORITY_CLASS и THREAD_PRIORITY_TIME_CRITICAL. С натягом, но все успеваю.

Извините, если скажу общеизвестное.
Приоритет потока - вешь относительная.
Если посмотреть каким-либо процесс вьювером,
можно обнаружить, что абсолютный приоритет
потоков "обычного" приложения не может превысить ~15.
У Кернела - вдвое больше.
Так что резервы еще есть.
Можно попытаться увеличить приоритет процесса.
Тогда "THREAD_PRIORITY_TIME_CRITICAL" станет еще выше..

[Lukomor]

Извините, если скажу общеизвестное.
Приоритет потока - вешь относительная.
Если посмотреть каким-либо процесс вьювером,
можно обнаружить, что абсолютный приоритет
потоков "обычного" приложения не может превысить ~15.
У Кернела - вдвое больше.
Так что резервы еще есть.
Можно попытаться увеличить приоритет процесса.
Тогда "THREAD_PRIORITY_TIME_CRITICAL" станет еще выше..

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

[-Tумблер-]

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

И я тоже не рад этой особенности XP.
Еще раз подтверждаю (опять "влетел") - дело не в разных
потоках. Если в программе возможно обращение к порту
ОДНОВРЕМЕННОЕ из разых потоков, под XP аппликэйшн зависнет насмерть.
А для WIN98 нет проблем.
Это касается всех функций использующих idComDev
( где idComDev это : HANDLE idComDev = ::CreateFile.......)

В том числе и
::GetCommModemStatus
::GetCommMask
::EscapeCommFunction
::SetCommState(idComDev, &dcb)..
И видимо вообще для всех.

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

[yuriyc]

[/quote]

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

[/quote]

Обратимся к книге Джеффри Рихтера "Windows Создание эфективных win-32 приложений".
" -Концепция класса приоритета вводит некоторых в заблуждение. Они делают отсюда вывод, будто процессы учавствуют в распределении процессорного времени. Так вот, процессы никогда не получают прцессорное время - оно выделяется лишь потокам. Класс приоритета процесса - сугубо абстрактная концепция, введенная Microsoft с единственной целью: скрыть от разработчика внутреннее устройство планировщика".

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

Клас приоритета потока
Относительный приоритет Idle Bellow Normal Above High Real-time
потока Normal Normal

Time-Critical 15 15 15 15 15 31
Highest 6 8 10 12 15 26
Above Normal 5 7 9 11 14 25
Normal 4 6 8 10 13 24
Bellow Normal 3 5 7 9 12 23
Lowest 2 4 6 8 11 22
Idle 1 1 1 1 1 16

Уровень 0 зарезервирован. Кроме того, уровни 17-21 и 27-30 в обычном приложении тоже не доступны.Вы можете пользоваться ими, только если пишите драйвер устройства, работающего в режиме ядра. И еще одно: уровень приоритета потока в процессе с классом real time не может опускаться ниже 16. а потока с любым другим классом поднималься выше 15.

И еше :
1. Планировщик не документирован полностью
2 Microsoft не разрешает в полной мере использовать особенности планировщика
3. Microsoft предупреждает, что алгоритмп ланировщика постоянно меняется, и не рекомендует писать программы в расчете на текущий алгоритм.

Вот так обстаят дела

[Lukomor]

Обратимся к книге Джеффри Рихтера "Windows Создание эфективных win-32 приложений".
" -Концепция класса приоритета вводит некоторых в заблуждение. Они делают отсюда вывод, будто процессы учавствуют в распределении процессорного времени. Так вот, процессы никогда не получают прцессорное время - оно выделяется лишь потокам. Класс приоритета процесса - сугубо абстрактная концепция, введенная Microsoft с единственной целью: скрыть от разработчика внутреннее устройство планировщика".

...

Уровень 0 зарезервирован. Кроме того, уровни 17-21 и 27-30 в обычном приложении тоже не доступны.Вы можете пользоваться ими, только если пишите драйвер устройства, работающего в режиме ядра. И еще одно: уровень приоритета потока в процессе с классом real time не может опускаться ниже 16. а потока с любым другим классом поднималься выше 15.

2yuriyc:
Спасибо за информацию. Я пользовался в основном "Windows 98. Руководство разработчика. Бен Эззель, Джим Блейни". Правда _измеренный_ приоритет потока THREAD_PRIORITY_TIME_CRITICAL в REALTIME_PRIORITY_CLASS не поднимался выше 15. Но я проверил опытным путем. Запустил бесконечный цикл с этим приоритетом, в результате повесилась даже мышка .

2all:
Кто нибудь знает, каким образом можно точно переключить RTS после передачи слова? Автоматический вариант не подходит Происходит или большая задержка между концом слова и переключением или RTS переключается раньше.

[yuriyc]

[/quote]

2all:
Кто нибудь знает, каким образом можно точно переключить RTS после передачи слова? Автоматический вариант не подходит Происходит или большая задержка между концом слова и переключением или RTS переключается раньше.

[/quote]

Как вариант: можно отследить событие/прерывание возникающее по окончанию передачи байта. И ручками выставить RTS.

[vm1]

Мне кажется из под Win управлять RTS дело безнадежное.
Вы видимо подключаетесь к RS485 и вам понадобится
преобразователь интерфейса.
Обычно он автоматом управляет активностью
передатчика ориентируясь на заданную для него скорость.
Работает как одновибратор на время передоваемого
слова, стартует от стартового бита.
RTS от PC при этом не используется.

[Lukomor]

Как вариант: можно отследить событие/прерывание возникающее по окончанию передачи байта. И ручками выставить RTS.

Отлов прерываний WIN32? Это если только на уровне драйвера. Других способов не знаю.
Событие - возврат из функции записи в порт. При этом если сразу выставить RTS, а потом посмотреть на осциллограф то получится что RTS выставляется в СЕРЕДИНЕ передаваемого слова, то есть надо вводить программную задержку, при этом она (задержка) должна определяться для каждой машины отдельно.
RTS выставляю EscapeCommFunction(...).

2vm1:
Вы правы, но к сожалению преобразователь интерфейса уже есть и изменить его нельзя, поэтому управлять RTS могу только с машины. Причем добавлять какое-либо оборудование тоже нельзя - все задокументировано и согласовано

[vm1]

а есть возможность передавайть последний байт транзакции
тогда когда вы достоверно контролируете
возможную задержку по снятию RTS?

[Krom]

Вот примерчик для Borland C++ Builder из моей тестовой программки. hCOM, dcb, и sTO обьявлены глобально ( HANDLE hCOM, DCB dcb, COMMTIMEOUTS sTO), в классе MainForm, cbBaudRate - комбо-бокс на главной форме с выбором скорости обмена.

int __fastcall TMainForm::InitComm(int portno)
/////////////////////////////////////////////////////////////////////////////
//
// Инициализация COM-порта с номером portno. Если инициализация прошла
// успешно, то функция возвращает 0, в противном случае один из следующих
// кодов:
// -1 не удалось получить доступ к COM-порту
// -2 не удалось получить доступ к блоку dcb
// -3 не удалость перенастроить порт
// -4 ошибка при настройке тайм-аутов
//
/////////////////////////////////////////////////////////////////////////////
{
char portname[8];
int result;
DWORD val;

sprintf(portname,"COM%d",portno); //

hCOM = CreateFile(
portname, //
GENERIC_READ|GENERIC_WRITE, // Пробуем получить доступ
0, // к COM-порту
NULL, //
OPEN_EXISTING, //
FILE_ATTRIBUTE_NORMAL, //
NULL //
);

if( hCOM != INVALID_HANDLE_VALUE )
{//*1*-----------------------------------------------------------------
// Настройка параметров порта
//--------------------------------------------------------------------
if( GetCommState(hCOM,&dcb) )
{//*2*
switch( cbBaudRate->ItemIndex )
{
case 0: {
dcb.BaudRate=CBR_4800;
break;
}
case 1: {
dcb.BaudRate=CBR_9600;
break;
}
case 2: {
dcb.BaudRate=CBR_19200;
break;
}
case 3: {
dcb.BaudRate=CBR_38400;
break;
}
case 4: {
dcb.BaudRate=CBR_57600;
break;
}
case 5: {
dcb.BaudRate=CBR_115200;
break;
}
default: dcb.BaudRate=CBR_9600;
}// end of switch (cbxBaudRate)

dcb.ByteSize = 8; // в байте 8 битов
dcb.fBinary = True; // альтернативы как бы нет

dcb.fNull = False; //

dcb.fOutxCtsFlow = False; // disable TS output flow control
dcb.fOutxDsrFlow = False; // disable DSR output flow control
dcb.fErrorChar = False; // disable error replacement

dcb.fAbortOnError = True; // abort reads/writes on error

dcb.fDtrControl = DTR_CONTROL_DISABLE; // DTR flow control disable
dcb.fRtsControl = RTS_CONTROL_DISABLE; // RTS flow control
dcb.fDsrSensitivity = False; // DSR sensitivity disable

dcb.fOutX = False; // disable XON/XOFF out flow control
dcb.fInX = False; // disable XON/XOFF in flow control

dcb.XonLim = 256; // transmit XON threshold
dcb.XoffLim = 2048; // transmit XOFF threshold

dcb.XonChar = 0x7F; // Tx and Rx XON character
dcb.XoffChar = 0x7F; // Tx and Rx XOFF character

dcb.EvtChar = 0x02; // received event character
dcb.ErrorChar = 0x00; // error replacement character
dcb.EofChar = 0x03; // end of input character

dcb.fTXContinueOnXoff = False; // XOFF continues Tx (????)

if( !SetCommState(hCOM, &dcb) )
{
CloseHandle(hCOM);
hCOM = INVALID_HANDLE_VALUE;
return( -3);
}
}
else
{
CloseHandle(hCOM);
hCOM = INVALID_HANDLE_VALUE;
return( -2);
}//*2*

}//*1*
else return( -1);


//---------------------------------------------------------------------
// Настройка тайм-аутов
//---------------------------------------------------------------------

if( GetCommTimeouts(hCOM, &sTO) )
{
sTO.ReadTotalTimeoutConstant = 250;
sTO.ReadTotalTimeoutMultiplier = 3;
sTO.ReadIntervalTimeout = 2;
sTO.WriteTotalTimeoutConstant = 100;
sTO.WriteTotalTimeoutMultiplier = 5;

if( !SetCommTimeouts( hCOM, &sTO ) ) {
CloseHandle( hCOM );
hCOM = INVALID_HANDLE_VALUE;
return( -4);
}
}
else
{
CloseHandle(hCOM);
hCOM = INVALID_HANDLE_VALUE;
return( -4);
}

PurgeComm(hCOM,PURGE_TXABORT|PURGE_RXABORT|PURGE_TXCLEAR|PURGE_RXCLEAR);
ClearCommError(hCOM,&val,NULL);

return( 0 );
}//<<< End of InitComm() >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


Ну а дальше через функции ReadFile и WriteFile.
1. Передача:

len = 5;
fSucs = WriteFile( hCOM, &txbuf[0], len, &len, NULL );

if( !fSucs )
{
Errors = CE_BREAK|CE_FRAME|CE_IOE|CE_MODE|CE_OVERRUN|CE_RXOVER|CE_RXPARITY|CE_TXFULL;
ClearCommError(hCOM, &Errors, NULL);
}

2. Прием:

len = 5;
fSucs = ReadFile( hCOM, &rxbuf[0], len, &len, NULL );

if( fSucs && (len==5) ) { принято } else { сбросить ошибки как при передаче}

Количество принятых байт проверять желательно, так как иногда функция возвращает вроде все ОК, хотя считано 0 байтов. Что это за глюк не разбирался.

По переключению RTS. Автоматический вариант проходит - сам когда-то писал утилитку для заливки в кассу базы товаров по 485 интерфейсу. Долго мучался, но в конце-концов разобрался - хитрость там какая-то с настройками com-порта, давно это было, попрбую найти в архивах примерчик.

[fluent]

Помогите плиз.
Взялся за курсовик.Для начала надо написать прогу для работы с мобилой через com порт.
Я в этом совсем не ничего не понимаю.Объясните новичку
Скиньте кто что может.Буду очень благодарен

[haker_fox]

Помогите плиз.
Взялся за курсовик.Для начала надо написать прогу для работы с мобилой через com порт.
Я в этом совсем не ничего не понимаю.Объясните новичку
Скиньте кто что может.Буду очень благодарен

Меня вот удивляет, зачем учиться, если ничего не понимаешь? Просто уже наприятно видеть на форуме сообщения типа "в электронике не шарю, но хочу сделать устройство на микроконтроллере". Сори за оффтоп.
По теме: в интернете, да и на этом форуме полно материала. Поиск спасет Вас.

[Djimmy]

Запоздало, но тем не менее..

Прикрепленные файлы

 Serial.zip ( 136.29 килобайт ) Кол-во скачиваний: 280

 

[MaxPIC]

Я делал так в Visual Studio 2005:
Инициализация:
SerialPort system_port;
system_port = new SerialPort();
system_port.PortName = "COM1";
system_port.BaudRate = 115200;
system_port.DtrEnable = true;
system_port.ReadBufferSize = 100000;
system_port.DataReceived += new SerialDataReceivedEventHandler(system_port_DataReceived);
system_port.Open();
system_port.DiscardOutBuffer();
system_port.DiscardInBuffer();
А далее по событию, которое вызывается, когда приходит байт в буфер COM-порта (объемом 100000 байт) пишете свою процедуру обработки принятых данных:
void system_port_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
byte newbyte;
while (system_port.BytesToRead >=3) // К примеру, если пришло более трех байт
{
newbyte=(byte)system_port.ReadByte();
...... // Тут пишем свою часть обработки принятых данных
}
}
Передавать данные также просто: записываем в выходной буфер - и всё.
Вот пример передачи 7-байтного пакета с хэшем
data = new byte[7];
data[0] = 183;
data[1] = 5;
data[2] = 0xA0;
data[3] = 0x01;
data[4] = 0x01;
data[5] = 0x00;
data[6] = (byte)(data[1] ^ data[2] ^ data[3] ^ data[4]);
system_port.Write(data, 0, data.Length);
Всё общение использует только класс SerialPort. Преимущества такого решения в следующем:
1. Поддержка с Win98 (только dotNet 2.0 поставить надо) по WinXP и даже Vista.
2. Программа не занимает ресурсов ПК для постоянного опроса COM-порта. Пришел байт - сработало событие. Не пришел - можете выполнять любые другие действия.
3. Как следствие из пункта 2 программа может быть легко использована в многозадачном приложении.
4. Никаких драйверов писать не надо. Код максимально простой. Читаем MSDN как использовать SerialPort и всё.
5. Есть возможность устанавливать таймер на ожидание прихода данных, просто в данном примере он не использован.
Недостаток - Windows не операционная система реального времени, а поэтому НЕТ четкого временного интервала, в течение которого будет передан байт в линию из выходного буфера COM-порта. Но на практике, я общался со скоростью 115200 и реальной информационной ёмкостью 72000 как в сторону ПК, так и в сторону железа - проблем не было, хотя параллельно работал Emule.

[MMP]

Подскажите как cport310 прицепить к Borland

[badik]

Судя по Вашей переписке - лето было боевое.
Есть очень простое решение COM - Delphi + компонент Async32.
http://www.tmssoftware.com/
http://www.tmssoftware.com/ta32.htm
Downloads Asynchronous serial communications made easy for your Delphi & C++Builder applications

Вообще не нужно знать. Задать нужную скорость (константа) - максимум усилий. Работает везде, есть рабочий пример, если ваш контроллер выдаёт символы - их сразу увидите. На Delphi (если не пробывали) писать намного удобней чем на С (мне так кажется).
Я правда из-за Async32 остался на Delphi 3 (кто-то ухмыльнётся), когда-то для более старших не получилось и руки не дошли, на сайте то есть, сейчас время жалко. Главное хочется уйти на USB, вот для этого нужен компонент.
К стати компонент Delphi 3 есть сам исходный текст - я раз заглянул и мне хватило навсегда. Понял мне в калашный ряд не стоит... Такие вещи будут жить и потом. Иногда приходиться иметь дело с самоделками, хороши до времени. Пример с Win XP.
С уважением
badik

[dimka76]

Запоздало, но тем не менее..

Спасибо классный класс. Давно искал что-то подобное.

[Hmm]

... классный класс.

Да неплохой. Использовал под C++Builder что-бы не нарушать лицензионного соглашения.

[dm37]

в архиве cport310 есть файл readme.txt всё (правда по английски) написано

а если кратко, то так (на примере Delphi 7):
- открываем в Delphi файл cport-3.10\sources\CPortLib7.dpk
- в открывшемся окне "Package - CPortLib7.dpk" жмём кнопку "Compile"
- закрываем окно "Package - CPortLib7.dpk", но запрос "Сохранить" жмём "Нет"
- открываем в Delphi файл cport-3.10\sources\DsgnCPort7.dpk
- в открывшемся окне "Package - DsgnCPort7.dpk" жмём кнопку "Compile", потом "Install"
- закрываем окно "Package - DsgnCPort7.dpk", но запрос "Сохранить" жмём "Нет"
- проверяем на вкладке компонентов наличие вкладки "CPortLib"
- все файлы cport которые будет требовать компилятор копируем из cport-3.10\sources\ в C:\Program Files\Borland\Delphi7\Projects\Bpl\, как правило это *.dcu, *.dfm, *.pas, CPort.inc, CPortImg.res

вроде всё

Сообщение отредактировал dm37 - Sep 26 2016, 18:47