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

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

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

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




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

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

2Lukomor

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


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


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

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

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

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


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

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

2_VM

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

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

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

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

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

Соедени 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 */
}

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

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

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

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

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

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

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