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

Предположим - есть ПО на персоналке под управлением распространенной десктопной ОС - 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) Какой физический интерфейс лучше подойдет?

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

В Linux нет приоритетной системы прерываний- одной из отличительных особенностей RTOS.

Завесить в своём драйвере (или модифицируя исходный код драйвера RS232) обработчик прерывания легко.

Управление обработчик прерываний гарантированно получит, сразу же при отсутсвии в системе одновременно с ним других аппаратных прерываний.

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

Приложение пользователя даже с наибольшим приоритетом получит упраление через шаг планировщика (scheduler) ядра ОС Linux.

Временной шаг планировщика задаётся при настройке до последующей сборки ядра Linux kernel. И может быть изменен только пере- сборкой ядра.

/boot/.config-2.6.32-5-686
В debian 6 это :
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250



Если не использоватьRTOS, возможно применить Linux Real Time Application Interface:
Например:
http://packages.debian.org/sid/rtai

Одно из возможных решений - использовать так называемые "временные метки". То есть фиксировать время интересующего события непосредственно в самом внешнем устройстве, по собственному таймеру (часам). Далее, включать это время, в качестве атрибута, в пакет передаваемых данных на PC. Задержки при передаче, конечно, ни куда не исчезнут. И их неопределенность останется. Но, по крайней мере, при обработке данных в своей прикладной программе Вы будете знать точную хронологию событий.
P.S. В этом случае, можно использовать и USB-канал.

В ванильном нет а c патчем -rt есть и прерывание там не зависнет. Все обработчики прерываний выолняются в отдельных потоках ядра - им можно назначить любой приоритет утилитой chrt, все спин-блокировки заменяются rt-мютексами и полностью вытесняемые.

Если Linux, то можно посмотреть в сторону ftrace (есть в составе ядра) или LTTng (нужно патчить ядро). Но не уверен что там есть нужный вам функционал, возможно, придется немного "доработать напильником".

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

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

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

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

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

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

http://www.opennet.ru/man.shtml?topic=requ...9&russian=2

По замеру времени, выше предложили типовой вариант: внешнее событие подаём на один луч осциллографа.
В обработчике прерывания выводим, например на LPT, логическую "1". Сигнал с LPT подаём на другой луч осциллографа.
Смотрим разность по времени импульсов.

Двух лучевой осциллограф рулит.