Приветствую!

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

Пульты бывают двух видов - либо простая кнопка, у которой обрабатывается только время нажатия, либо плавный переключатель (например, педаль), для которого учитывается его мгновенное положение (как коэффициент от 0.0 до 1.0)

В устройстве критичны задержки при обработке сигналов от пульта, поэтому например компьютерная клавиатура, подключенная по usb, - сразу не подходит в качестве пульта (задержка буффера клавиатуры, задержка USB-порта).

Если делать устройство на базе персоналки, какой интерфейс я могу использовать в данном случае и какие задержки (именно задержки, а не скорость интерфейса) я могу получить? Как варианты - USB; FireWire; кастомная плата, подключенная по PCI/PCIe/PCMCI, может быть древний LPT/COM?

Естественно, на персоналке планируется ОСРВ, чтобы аппаратные прерывания обрабатывались жестко по мере поступления.

Время развертки одного кадра изображения на мониторе составляет 10-20 мс. Поэтому стремиться завести в компьютер обратную связь ранее следующего кадра, ИМХО, бессмысленно. А в 10-20 мс "влезает" любое устройство ввода (USB, RS-232, LPT) - особенно если на компьютере будет ОСРВ.

Спасибо за быстрый ответ!

Насчет 10-20 мс - соглашусь, это период перерисовки (обновления видеопамяти), чаще - нет смысла, т.к. это не покажет ни один монитор, реже тоже - картинка не будет какое-то время соответствовать модели.

Только в таком случае, если ориентироваться на этот интервал при обработке внешнего прерывания, то и погрешность будет в пределах 10-20 мс.
К тому же, если фактически сигнал от пульта сгенерирован во время первого кадра, то и обработать его желательно за время первого кадра, а не второго.

Время реакции испытуемого хотелось бы оценивать с большей точностью, в идеале - 1 мс.

Не поделитесь раскладкой по времени конкретных интерфейсов?

Обычная клавиатура. PS\2.
Обычная мышь. (Даже не кнопки мыши, а перемещение). Частота опроса мыши до килогерца. Это 1 мс.
У обычной 232 мыши - еще выше.

Точность 1 мс вам не нужна (если тест психологический). Нервный импульс проходит за это время 12 см. И это в самых лучших условиях.
А по жизни - сантиметра 3.

Из популярных интерфейсов ввода (RS-232, USB, LPT, PS/2) разве что в USB сложно строго детерминировать время от физического события (нажатия кнопки, условно говоря) до появления данных в буфере драйвера (обработчика прерывания). Это связано с тем, что USB-устройства всегда аппаратно опрашиваются хостом (поллинг) с помощью выстроенной цепочки дескрипторов, поэтому время реакции будет зависеть от правильности выстраивания этой цепочки драйвером, от количества USB-устройств и может составлять от 1 мс до 1 с (теоретически!).
Что касается остальных интерфейсов - LPT частота опроса до 200 кГц, RS-232 зависит от скорости передачи данных и т. п.
Однако когда прикладное приложение получит данные уже от драйвера - здесь гораздо всё более туманно в многозадачной системе, даже если она ОСРВ, зависит от периода "тика" планировщика задач, загруженности системы и интенсивности работы высокоприоритетных процессов (например, обмена по сети).
На мой взгляд, Вам не нужно бояться относительно длительного времени между событием и его фиксацией - главное, чтобы оно было как можно более определённым ( в идеале - одинаковым от измерения к измерению), тогда его можно просто вычесть при расчётах.

Тест - Реакция на движущийся объект (примерное описание на http://www.neurosoft.ru/rus/product/ns-psychotest/index.aspx )
Нервный импульс посылается заранее, с некоторым упреждением, которое испытуемый сам выбирает, так что на точность аппаратуры, мне кажется, этот факт не влияет.

А более современные/распространенные интерфейсы? К тому же, частота опроса - это все же не время отклика

Хм, значит USB точно нельзя использовать из-за недетерминированности времени отклика.

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

LPT с 200 кГц, ps/2 и rs232 (через DB9, а не виртуальный COM-порт через COM/USB-переходник) выглядят заманчиво, но встречаются на персоналках в природе уже редко, и тенденция, что скоро их не будет совсем.

Demeny, а как Вы считаете, если использовать кастомный пульт (допустим, с единственной кнопкой) и кастомную печатную плату для обработки сигналов от пульта и сопряжения с шиной PCI/PCIe (или PMCIA для использования в "полевых" условиях, когда в роли персоналки - ноутбук), можно ли выстроить систему так, что задержка интерфейса будет минимизирована? Я же правильно понимаю, что задержки генерации прерываний при использовании PCI/PCIe много меньше 1 мс?

Тогда сразу настраивайтесь на сопровождение передаваемых данных маркером времени. То есть часы контроллера (на котором нажимают-крутят) и компьютера синхронизируются с точностью до 1мс (может, с помощью другого интерфейса, например стандартный сигнал 1PPS). Далее все данные сопровождаются временем их съема. Таким образом, нужная вам точность будет обеспечена при любых задержках интерфейса. А вот максимальная задержка интерфейса уже определяется тем, как быстро вам нужно обработать данные (20мс).
Тонкое место- это синхронизация всех измерителей с такой точностью. Если с контроллером все более-менее решаемо, то с IBM PC даже не знаю. Проще наверное напрямую этим же контроллером начало кадра выделять и в попугаях кадрах и считать всю времянку

Кстати, это какой такой системой РВ на IBM PC вы миллисекунды считать будете? и что, привязку к началу развертывания кадра можно сделать? Я не покдкалываю, действительно интересно. Делали когда-то распределенные системы для определения порядка срабатывания тысяч реле, шаг времени был 1мс, вот и интересно можно ли сейчас это без хитрых инженерных выкрутасов, а только засчет шустрой техники достигнуть.

Ruslan1 Я, если честно, решил пока задачу "влоб" - сделал систему-на-чипе (Xilinx spartan 6), которая и сигналы с пультов снимает и видео-сигналы генерирует. Только к сожалению, масштабирование такого устройства сильно ограничено, да и сопряжено с большим временем разработки (зато, о таких таймингах практически не заботишься - или GPIO на сигнал от ножки ПЛИС, или контроллер АЦП с большой частотой; кроме времени выполнения кода прерываний, конечно). Собственно, поэтому и задаюсь сейчас вопросом о том, можно ли это перевести на персоналку - благо предметную область на C++ можно перенести.

Вообще, мне казалось, что если решать на персоналке, то пульты и их контроллеры должны быть "глупыми" - без RTC, вся обработка - на ЦП, а тайминги - определяться скоростями интерфейсов. Поэтому, если найти современный интерфейс с малыми задержками, то можно было бы добиться адекватной точности.

Из ОСРВ смотрю в сторону http://www.xenomai.org как открытого решения или QNX как продвинутого, хотя цен на лицензию опасаюсь. Так как по задумке вся обработка на персоналке, то программирую таймер на заданную частоту, по его тикам пересчитываю модель. Если прерывание от пульта приходит между тиками - считаю, что сигнал получен в прошлом такте. Отсюда и точность - 1 мс. Если обрабатывается постоянно изменяющееся действие испытуемого - то в каждом прерывании модель пересчитывается с только что полученным сэмплом от АЦП.

Привязку к кадрам - я ни разу такого не видел, хотя в SoC еще и не такое можно построить А про обработку за текущий кадр - я имел ввиду заметную глазу "скорость" обработки, в соотношении точности 1 мс против 10-20 мс на перерисовку. При таком соотношении, возможность, что обработан сигнал будет в начале следующего кадра, мне кажется, составит не более 1/10 или 1/20 (или того меньше, так как прерывание может придти в период бланкинга контроллера).

Время нажания кнопки (пока палец испытуемого ее вдавливает) - целая вечность по сравнению с аппаратными и программными задержками в компьютере!

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


Не имеет ни малейшего смысла использовать ОСРВ для таких целей. Советую вам почитать лиетратуру по компьютерными играм - там не раз проводились исследования на задержки реакции игрового персонажа на управляющее воздействие игрока. Так что не надо париться. Купите себе небольшого размера геймпад, и вперед с музыкой.

Xenia
А порекомендуете что-нибудь конкретное из литературы? И какие выводы из этих исследований? Я бы конечно еще про задержки аппаратных портов послушал )

Про геймпад я оценил Но согласиться не могу.
Дальше оффтопик ) Идея повышения точности существующей аппаратуры дурной быть не может. Тест РДО, на который я давал ссылку выше, характеризует индивидуальные особенности ЦНС, а не среднее по группе испытуемых (среднюю температуру по больнице). В зоне "нулевой ошибки" испытуемого, +- 1 мс уже определяет вывод о конкретном результате эксперимента (хотя да, он конечно может и усредниться по серии экспериментов).
Целую вечность по вдавливанию можно минимизировать малым ходом и временем срабатывания кнопки, плюс я где-то читал, что у человека это время до 10 мс.
Ну и ОСРВ нужна как раз, чтобы реакция системы "была константой для всех испытуемых", так как на практике в многозадачной системе нет гарантий в какой срок будет обработано аппаратное прерывание - отклик системы становится недетерминированным (тут данные разные, кто-то говорит про +- 10 мс, кто-то про 50-80 мс, но сути это не меняет)

Ну как же люди любят все усложнять....

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

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

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

Вот! Это оно!
Реально нужно-то плясать от того момента когда изображение на экране появилось, а не когда софт его в вроде бы отправил на дисплей.
Сто пудов хорошее решение, все остальные варианты синхронизации с изображением- это действительно лотерея(вероятностный процесс)

Кстати, есть такая фирма Tiny Love, делает игрушки которые в соответствии с видеорядом на экране гавкают-мяукают в нужное время. Так там просто в начале мультика идет кодовая посылка (но кажется звуковая), по которой игрушка синхронизируется и дальше гавкает в нужное время. Может и вам достаточно чего-то подобного, разовой синхронизации в начале непрерывного теста, а не ловить каждый кадр.

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

DpInRock
Ну решение конечно интересное. Я правильно понял, Вы предлагаете считать время на контроллере, который разовым образом (через фотодиоды) синхронизируется с монитором в момент начала эксперимента? А потом отдает в нереальном времени по любому интерфейсу это время в ПК для коррекции и дальнейших подсчетов? А разрешающая способность фотодиода позволит события точно синхронизировать, у меня в этом сомнения?
И, такой подход ведь не подойдет для теста, в котором в каждом прерывании важно значение АЦП?

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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