Как зафиксировать время получения прерывания?, RS232/LPT/etc Опции

[Andrey Pesoshin]

Доброго времени суток!

Предположим - есть ПО на персоналке под управлением распространенной десктопной ОС - Windows/Ubuntu/other-desktop-linux/etc.

ПО занимается просчетом некоторой модели и отрисовкой объектов (примитивов) на мониторе (более подробно тут - http://electronix.ru/forum/index.php?showtopic=94410)

К персоналке подключен внешний контроллер-пульт с кнопкой - подключить можно по RS232, LPT или другому интерфейсу с постоянными/прогнозируемыми задержками (USB не подойдет, так как задержка не детерминирована).

На персоналке нужно получить максимально точно время получения прерывания - даже сам факт прерывания от контроллера, а не содержание полученных данных.

В прошлой теме выяснил для себя, что между первичной обработкой прерывания драйвером и передачей управления прикладному процессу, который бы это прерывание обработал, может пройти ВЕЧНОСТЬ (десятки миллисекунд, или ~10 мс при использовании ОСРВ). При этом драйверу для первичной обработки управление будет передано через интервал времени порядка микросекунд после получения.

Отсюда вопросы:
1) Как в Windows/Linux переопределить первичную обработку аппаратного прерывания? (И куда временно положить захваченное время, чтобы потом передать его прикладному процессу?)
2) Есть ли в Windows/Linux УЖЕ механизм, который фиксирует время получения аппаратных прерываний? И как его "интерфейсить" из ПО?
3) Какой физический интерфейс лучше подойдет?

Заранее благодарен!

[Andrey Pesoshin]

gosha, sasamy
А расскажите, пожалуйста, как завесить имеющееся аппаратное прерывание своим? Делал раньше такие штуки только на asm'е под DOS, там просто добавлялся обработчик для int 14h, но здесь я так понимаю совершенно другой уровень абстракции.
В идеале - мне бы сразу по получению запомнить текущий тик от системных часов, а дальше отдать управление в дефолтный хандлер. (Неужели никто не догадался при разработке драйвера это время запоминать?)

kurtis
Спасибо за много умных слов, пойду кормить гугл

всем
Я же правильно понимаю, RTOS поможет только для планирования прикладного процесса (-ов), а на аппаратные прерывания никак не повлияет?

@Ark
Я тоже думаю об этом варианте, но тогда действительно есть узкое место - синхронизация контроллера и ПК с заданной точностью. В прошлой теме предложили 1PPS или фотодиод, который прикреплен в угол экрана и ждет управляющего символа - начала движения объекта. Тогда вроде бы и лаг ЖК-монитора можно убрать из цепочки задержек, но что-то меня в этом подходе настораживает.