Здравствуйте! Подскажите пожалуйста, как программно запрещать, а потом разрешать создание прерываний мышью и некоторыми(всех кроме одной) кнопками клавиатуры? Приложение в котором надо это реализовать должно гарантированно успевать обрабатывать прерывания от своего железа, а если будут шевелить мышью или использовать клавиатуру, то оно может не успеть. Нужно ли вообще запрещать мыши генерировать прерывания или лучше сделать максимально пустыми обработчики? В любом случае, насколько я понимаю, нужен верхний фильтр-драйвер для класса, находящегося непосредственно под mouclass.sys(kbdclass.sys для клавиатуры). А также нужно управлять фильтром через пользовательское приложение.
А почему только от мыши и клавиатуры? Остальные девайсы не считаются? А что у Вас за девайс, если не секрет? Может, вам в обрабочике ISR запрашивать DPC, а потом складывать данные в очередь, которая и будет обрабатываться приложением?
Спасибо, что откликнулись, думал уже никто не ответит. Эта программа будет загружаться вместо стандартной оболочки explorer при загрузке винды и поэтому предполагается, что действие графической подсистемы будет минимизировано и других процессов(пользовательского режима) не будет. Следовательно, остается мышь и клава, они больше всего будут грузить систему. Хотя есть еще системный таймер, но без него никак.)) Обращений к остальным девайсам этой программой не предполагается, хотя может быть винда что-то будет вызывать. Девайс - генератор радиосигналов. Эта программа должна в реалтайме обрабатывать прерывания от генератора. Т.к. для клиентов, получающих эти сигналы, очень важна точность вычислений, а она напрямую зависит от точности синхронизации.
Через регистры устройства. А вообще, устройство подключено к шине ISA. В драйвере регистры проецируются на определенную область ОП.
Мне кажется, что ваша затея сделать из Windows realtime ОС без использования кастомного HAL обречена на провал. Потому как вы не можете гарантировать, какие именно прерывания будут генерится устройствами в вашем ПК, а так как эти прерывания будут отрабатываться ОС и драйверами этих устройств. Так же, помимо вашего приложения в системе всё равно существуют запущенные процессы, которые будут требовать процессорного времени.
Справедливые замечания. Значит лучше найти realtime ОС и переписать драйвер под неё? Какую из realtime ОС лучше выбрать с точки зрения простоты написания драйвера и устойчивости работы, а то я с подобными ОС никогда не сталкивался и нахожусь в некоторой растерянности.
Лучше для начала уточнить\осмыслить задачу. Если ты под реалтаймом понимаешь "мгновенную" реакцию на внешние события, то возможно тебе не только ОС придется менять, но и железо, поскольку сама обработка прерывания тоже требует определенного времени. Но есть и другое понятие реалтайма - просто успевать обрабатывать данные по мере их поступления с внешнего устройства. В этом случае не обязательно получать и обрабатывать данные сразу "тик в тик", главное просто успевать их все получать, объединять в пакеты и затем обрабатывать пачками. В таком случае и другие (в т.ч. и более приоритетные) прерывания не столь страшны, если они не приводят к потерям данных и в среднем оставляют достаточно времени на обработку. А у тебя не понятно - что в итоге требуется и почему "точность вычислений ...напрямую зависит от точности синхронизации"? Раз речь идет о генераторе сигналов, то он должен выдавать не просто какие-то данные, а последовательность отсчетов, уже упорядоченных\привязанных ко времени (или с явными метками времени или просто последовательность с фикс.частотой дискретизации). И соотв-но не важно на сколько микро или миллисекунд задержится прием каждого отсчета - главное, что вместе они образуют однозначную последовательность = функцию времени x(t) PS: Твоя настойчивая борьба с мышиными прерываниями без пояснения\формулировки исходной задачи чем-то напоминает "Сагу о Х, Y и Z...", которую любят цитировать на другом не безизвестном тебе форуме
Ок. Уточнил: прерывания приходят от устройства строго периодично(с периодом T), компьютер сначала производит некоторые вычисления, а потом результаты отправляет на устройство. Результаты считываются устройством непосредственно перед прерыванием. Таким образом, если компьютер не успеет выслать результаты до окончания очередного цикла, то устройство будет работать со старыми данными один цикл(что увеличивает погрешности результатов для клиентов при сравнении с исходными данными генератора) и через цикл поступят либо устаревшие данные, либо новые (в зависимости от реализации драйвера). Так что нужно успевать принять и обработать одну порцию данных за время T. Считается, что приемник и передатчик синхронизированы. Сигнал излучается постоянно с начала сеанса работы. И всё что приходит на приемник он фиксирует с некоторым шагом дискретизации(который меньше T). Приемник анализирует как физические параметры сигнала, так и информацию. Получается, что отсчеты образуют функцию времени, но не во всех точках соответствующую той, что должна была получиться. Realtime OS скорее всего для этого подходит больше, чем винда, но никто мне не разрешит переписывать весь софт под другую ось. Так что речь идёт о том, чтобы повысить вероятность положительного исхода.)) "Сага о X, Y, Z" порадовала. Автор зрит в корень. Какая наблюдательность8)
С одной стороны, вроде вполне нормальная величина, сравнимая и с квантом потока и с частотой опроса мыши. Интересно, что там у тебя за супервычисления, что ты боишься не уложиться даже в одну десятую от этой величины ? И еще не понятно, можно или нельзя подготавливать данные заранее, с запасом на несколько тактов, чтобы по прерыванию драйвер только брал очередную порцию из подготовленного буфера и отправлял ее на устройство, а сама подготовка и помещение данных в буфер могли бы выполняться в свободные промежутки. И чего ты так мышиных прерываний боишься, если ты своему девайсу можешь задать приоритет "выше мыши" (по кр.мере стандартной PS\2 на IRQ 12), а на IRQL выше Passive и мышиные, и клавиатурные прерывния и так минимум действий выполняют, а диспатчами сообщений вроде как RIT занимается на Passive, наравне с другими потоками (поэтому и реалтайм потоки могут его "подвешивать"), да и BlockInput в конце концов существует от излишнй "мышиной возни" Но с другой стороны, под досом ес-но все было бы проще и надежнее. Тем более не понятно, зачем тут вообще винда, если "Сигнал излучается постоянно с начала сеанса работы" и ты готов заблокировать от юзера и клаву, и мышь - ему останется только любоваться на красочный рабочий стол или заставку "звезное небо" ?
