Архив форумов ЦИТФорума

[shenon]

Имеется некоторая программа написанная для Windows. Некоторая процедура сидит на таймере получает данные из внешнего устройства и записывает их в файл. Параллельно с ней работает другая программа - Microsoft Windows 2000 , которая мешает работать первой программе. В момент, когда вторая программа начинает перерисовывать свои окна, в первой откладываются события таймера. В результате внешенее усторойство накапливает данные непрочитанные из-за перерисовки окон и икон на экране. После переполнения данных в выходном буффере устройства данные теряются, что недопустимо.

Пробывал создать процесс считывания, как невидимое окно WS_DISABLED - типа , то есть недоступное. Запускал его с приоритетом рельного времени
HANDLE process=GetCurrentProcess();
if (!SetPriorityClass(process,REALTIME_PRIORITY_CLASS)) {...}
Пробывал на таймер посадить функцию
VOID CALLBACK TimerProc(
HWND hwnd, // handle of window for timer messages
UINT uMsg, // WM_TIMER message
UINT idEvent, // timer identifier
DWORD dwTime // current system time
){...};
SetTimer( hWnd, 1, 1, (TIMERPROC )TimerProc); //ставим таймер на 1 мсек
Кажется стало немного лучше, но не радикально.

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

[and3008]

Windows (ЛЮБОЙ) не является системой реального времени. Лучше сразу смотреть в сторону QNX или других UNIX-систем.

Мышка говоришь не тормозит? Хе-хе. Еще как тормозит. У меня на серваке бывает тяжелые SQL-запросы гоняют. Нагрузка такая, что даже два 3 Гигагерцовых Xeon-а не справляются. Мыша при этом тормозит "не по-детски".
И это на Win2000 Server.

[dilnab]

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

[Valera]

-

[shenon]

∑

[Sclis]

В виндах графическая подсистема выполняется в режиме ядра, так что извиняйте, никакими приоритетами это не переплюнешь. And3008 прав, Винда изначально не предназначена для работы в реальном времени и тут тоже ничего не поделаешь. А впечатление, что скорость достаточна появляется от того, что ресурсов с избытком - задержка мышки на 13 мс, извини, не критична. "- А работают же сетевые карты или звуковые или модемы?"... фокус в том, что там используются буферы внутренние )Там хранятся данные, если система занята. Для такой системы которую ты пытаешься выстроить можно попробовать:
1. действительно перейти на настоящую систему реального времени, но сие чревато тупиком, большинство таких встроенных систем сделаны НА БАЗЕ *nix, (с большим переписыванием кода). Все это должно абсолютно согласовываться с железом и главное требование к таким системам - гарантированная ОТВЕТНАЯ реакция за заданное время - то бишь, для простого сбора данных это явно избыток.
2. Использовать промышленные контроллеры с буферами, а не просто писать в порт, есть такие штуки, продаются и используются предприятиями для контроля произв. процесса (тебе же именно для того надо?). Это решение самое лучшее, поскольку стандартное и обернуто нужным числом предложений на рынке, систем программирования, обучающих курсов...
3. Абсолютный тупик: в NT 3.5 графика выполнялась в пользовательском режиме если наворотишь машину, поставишь на нее 3.5 и запретишь юзерам запускать тяжелые приложения то (возможно) низкая вероятность потери данных тебя и устроит но потом от такого чуда будет трудно уйти, даже если получится

[shenon]

Графическую систему в основном победить удалось с помоьщью установки конфигурации таймеров, тредов, приоритетов и процессов. Все программы спокойно жили не блокировали блокировали мой таймер. Среди них C++Builder, WinAmp,WinCommander, MathCad, WordPad, IExplorer. Но кнопка Пуск оказалась непобедимой.
Насчёт второго варианта не понял в чём идея.
В моём устройстве тоже есть буффер, которого хватает на 13 мсекунд. Хотелось бы точно знать: дело всего лишь в его объёме этого буффера или дело в принципе, то есть при любом объеме всегда может возникнуть ситуация, когда Windows захочет заблокировать таймер на 13 мсек или на 100 мсек, а может и на 1000 мсек.

Не знает ли кто нибудь RTX - Real Time Extension for Windows?

[Sclis]

так ты поток постоянный читаешь? не дискретная выборка? круто
"при любом объеме.." - наверно да, только вероятнось этого сильно падает с величиной буфера и возрастает с количеством и прожорливостью клиентских программ. (а на каком-то этапе винда сама грохнется, избавив от необходимости вешаться программу ) )
Мне кажется, тогда главная проблема у тебя не в программировании, а организационная Нужен выделенный комп под это дело. Чтобы не возникало необходимости WinAmp и т.д. запускать на нем Нет же гарантии, что пользователь не захочет запустить все приложения сазу и в трех экземплярах. Какой нибудь пентиум с легкой ОС и быстрым хардом, заблокировать клавиатуру, отключить монитор и мышь и поставить его в шкаф а данные архивировать по сети. и защита от вирусов будет и от случайных ошибок и т.д. полноценный сервер
Потому как, допустим, пинболл занимает проц на 100% или адобе акробат при перетаскивании документа И они составят достойную конкуренцию кнопке "Пуск" мне так кааатся

[Alex369]

По какому порту работаешь? Стандартные дровишки пробоват юзить, у меня без проблем на RS232 на отдельных потоках прием и передача.