Выбор порта на персоналке с малыми задержками Опции

[DpInRock]

это время в ПК для коррекции и дальнейших подсчетов

Нет, конечно. Никакой коррекции. Что может знать такого PC, чего уже не знают фотодиоды и контроллер - НИЧЕГО.

А вот коллекционировать на нем РЕЗУЛЬТАТЫ - вполне можно. Любым из доступных интерфейсов.

Кстати, синхронизация по звуку, возможно удобнее, хотя и не так точна (хотя точность вам ни разу не упала). Ну и чутка сложнее в реализации.

А вообще - это все полный бред.
Нажатием на обычную клавишу обычной клавиатуры вы получите совершенно нормальный результат.
И кстати - частота опроса - в общем-то и есть время отклика. Ибо каждую миллисекунду вам в программу поступают данные о перемещении мыши.

---
Но в любом случае, для ФИЗИОЛОГИЧЕСКИХ тестов надо применять внешние по отношению к компу средства. Грубо говоря параллельно человеку - модель воспринимающего в электронном виде - т.е. ИДЕАЛЬНЫЙ кролик. И его уже сравнивать с НАСТОЯЩИМ кроликом. Вот это и будет похоже на настоящий эксперимент. По всем правилам.

---
Кроме того. Представьте, я есть супермен с бесконечно быстрой реакцией.
Вот он в нужный момент нажимает кнопку.
Ход кнопки 5 мм, например.
Чтоб за миллисекунду нажать кнопку, его палец должен двигаться со скоростью 5 метров в секунду.
Т.е. с 0 разогнаться до 5 метров.сек за миллисекунду (грубо).

Космонавты таких перегрузок не выдерживают. Никто не выдерживает 5 км в секунду за секунду.

Мож где-то ошибся, но не в этом суть.



Сообщение отредактировал DpInRock - Sep 15 2011, 07:20

[Andrey Pesoshin]

Demeny, DpInRock
Большое спасибо за проявленный интерес, правда! Все-таки, от вас я слышу про привязку временной отметки нажатия на кнопку пульта к развертке кадра. Может быть вы объясните мне, зачем? Видимо, я действительно этот момент не понимаю
Мое мнение такое - в тесте РДО (психологическом, физиологическом - не важно) испытуемый выбирает УПРЕЖДЕНИЕ, с которым следует выполнить нажатие на кнопку пульта.
Например, полный оборот движущегося объекта по часовой стрелке - 3 секунды. Тогда порядка 2 секунд испытуемый просто наблюдает, на 2й секунде начинает готовиться, а где-то начиная с 2,5 с до 3,5 с - совершает "маневр", причем за реальное ненулевое время. (Это же не супер-мен, и не космонавт с большими перегрузками!).
Разве недостаточно только фиксации времени нажатия (чтобы из 3 с вычесть это значение и получить результат ошибки испытуемого - со знаком плюс или минус)? К чему развертка кадра, если анимация показывается испытуемому только для восприятия движения объекта, а реакция от него требуется не мгновенная ("супер-быстрая")?

Нет, конечно. Никакой коррекции. Что может знать такого PC, чего уже не знают фотодиоды и контроллер - НИЧЕГО.

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

Не думаю, что кастомный пульт, подключаемый к PC, принципиально улучшит точность измерения времени реакции, поскольку основная неопределённость находится в программной части (драйвер - приложение) на PC. И правильно Вам сказали, что применение ОСРВ здесь вряд ли что-то изменит. Вам по сути нужно не столько получить отклик с минимальной задержкой, сколько привязать этот отклик к конкретной временной метке, связанной с кадром на экране. Чтобы получить временную метку с разрешением 500 мкс - системный тик должен быть как минимум такой же, а 500 мкс тик даже для QNX - это очень серьёзный стресс для ОС (типовое значение 10 мс).
Я бы сделал примерно так - пульт можно соединить с PC по RS-232 на скорости, например, 115200 бит/с. При этом переписать обработчик прерывания по приходу байта в COM-порт таким образом, чтобы он вычитывал из регистров видеокарты текущий номер разворачиваемого кадра и текущие координаты луча развёртки. Время передачи управления обработчику прерывания в любой ОС составляет единицы микросекунд, время передачи байта по RS-232 тоже известно (~87 мкс). Таким образом можно вычислить время нажатия кнопки почти до пикселя на экране

Demeny А смотрите, Вы пишете, что основная неопределенность в программой части (драйвер-приложение), а потом, что "в любой ОС передача управления обработчику прерывания составляет единицы микросекунд". А разве это не одно и то же? И почему в любой ОС?

[Demeny]

Demeny А смотрите, Вы пишете, что основная неопределенность в программой части (драйвер-приложение), а потом, что "в любой ОС передача управления обработчику прерывания составляет единицы микросекунд". А разве это не одно и то же? И почему в любой ОС?

Неопределённость возникает тогда, когда к обработке подключаются прикладные процессы, передачу управления которым осуществляет планировщик в соответствии с их приоритетами и состояниями (ready, blocked).
А первичный обработчик аппаратного прерывания не зависит от планировщика, во всех ОС он имеет максимальный приоритет и прервать его может только другой обработчик более высокоприоритетного прерывания, что составит доли микросекунд.
Отличие ОСРВ от других ОС как раз и заключается в такой политике планирования процессов, при которой исключается ситуация, когда один из процессов может не получить управления длительное время. Но это вовсе не означает, что время между разблокировкой процесса и получением управления будет строго одинаковым. Поэтому применение ОСРВ в вашем случае точность не поднимет, о чем и было сказано другими участниками обсуждения.

[muravei]

Нажатием на обычную клавишу обычной клавиатуры вы получите совершенно нормальный результат.

Можно сделать измеритель "скорости реакции" клавиатуры компа.
Иммитатор клавиатуры на МК индикацией насчитанных тиков.

[Andrey Pesoshin]

Неопределённость возникает тогда, когда к обработке подключаются прикладные процессы, передачу управления которым осуществляет планировщик в соответствии с их приоритетами и состояниями (ready, blocked).
А первичный обработчик аппаратного прерывания не зависит от планировщика, во всех ОС он имеет максимальный приоритет и прервать его может только другой обработчик более высокоприоритетного прерывания, что составит доли микросекунд.
Отличие ОСРВ от других ОС как раз и заключается в такой политике планирования процессов, при которой исключается ситуация, когда один из процессов может не получить управления длительное время. Но это вовсе не означает, что время между разблокировкой процесса и получением управления будет строго одинаковым. Поэтому применение ОСРВ в вашем случае точность не поднимет, о чем и было сказано другими участниками обсуждения.

В таком ключе понятнее. То есть, отключив на время эксперимента на персоналке все лишнее - сеть, другие неслужебные процессы - можно будет уменьшить возможность того, что первичный обработчик COM-порта не получит управление в срок или будет прерван. А время получения этого прерывания я могу зафиксировать с высокой точностью, если внедрю это в первичный обработчик. Круто.
А если поближе к практике - допустим ОС распространенная - винда или десктопный линукс. Как мне переопределить/дополнить этот первичный обработчик аппаратного прерывания, и это учитывая, что на уровне прикладного ПО я этого сделать не могу?
Переписать драйвер COM-порта и использовать его? Или может быть уже есть механизмы точной фиксации времени поступления аппаратного прерывания - на уровне ОС?

[_3m]

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

Геймерскую мышь купите.
Посмотрите какие модели используют на чемпионатах мира по кваке и вперед в магаз.

[Andrey Pesoshin]

Геймерскую мышь купите.
Посмотрите какие модели используют на чемпионатах мира по кваке и вперед в магаз.

В качестве пульта вполне обоснованно, только остальных проблем не решит