Почитав вот это, задался вопросом - а какова частота обращения к джоям? Имеет ли смысл ее увеличивать? Что думает уважаемое коммьюнити?
Вид для печати
Почитав вот это, задался вопросом - а какова частота обращения к джоям? Имеет ли смысл ее увеличивать? Что думает уважаемое коммьюнити?
^Up.
Не могу найти в файле usbport.sys строку 3C 08 73 09 C6 86 0A 01 :confused: Система WinXP SP1. В статье юзалась SP2. Может кто подскажет - какую строку искать в SP1 и на какую менять :rolleyes:
Так usb шина и так на нескольких (а то и нескольких десятках) МГц бегает :) куда уж дальше? То что по ссылке, скорее называется "разгон контроллера мышки" а не шины. Да и смысл джойстик "разгонять" если его движения все равно напрямую не влияют на перемещение пикселов? В отличии от мышки с кваком.
В том и дело - несмотря на несколько десятков МГц, частота эта в винде загрубляется конкретно. И нет гарантии, что то же самое не происходит в hid-драйверах usb-джоев. В этом собственно и вопрос - происходит или нет?Цитата:
Сообщение от Sea
Хм... а смысл в большом разрешении осей джоя, если "если его движения все равно напрямую не влияют на перемещение пикселов"?Цитата:
Да и смысл джойстик "разгонять" если его движения все равно напрямую не влияют на перемещение пикселов? В отличии от мышки с кваком.
Вам, видимо, подойдет другой метод для того же самого.Цитата:
Сообщение от -SCS-UHU
Или я тормоз или одно из двух.
Цикл опроса устройства с конечной точкой по прерыванию (endpoint:Interrupt)
однозначно определяется через дескриптор(описание) ХИД-устройства.
Если ХИД-устройство запрашивает в дескрипторе интервал опроса 10 мс, то это означает что запрос от хоста(компьютера) может прийти в интервале от 1 ДО 10мс от ПРЕДЫДУЩЕГО запроса. Т.е. от 1000 до 100 запросов в секунду.
Остается вопрос НАКУА ? Дело в том. что никто не мешает пропатчить драйвер УСБ-устройства чтобы тот плевал на то, что объявлено самим устройство и инициировать прерывание когда хочет в диапазоне 1-10мс. Устройство ОБЯЗАНОГО обработать этот запрос. Но самое главное НЕ ФАКТ что устроство УСПЕЕТ обработать тот запрос. В идеале оно выдаст NAK на запрос пришедший не вовремя и драйвер уйдет на следующий цикл ожидания. В кривом устройстве - это может вызвать все что угодно вплоть до зависания.
Для примера возмем гипотетический драйвер джойстики на прошивке мин-дога.
8 осей АЦП по 65 мкс дают больше чем 1/2 мкс только на опрос АЦП, плюс еще какое-то время на опрос кнопок, т.е. опрос состояния джойстика дает меньше 1 мс. Все ОК. Никто не мешает запросить опрос хоть 1мс.
Однако оптическая мышь на чипе ADN2051 обеспечивает получение координат не чаще чем 5,6 мс., т.е. запрос должен быть МИНИМУМ 6мс.
Т.е. получается все опять-таки зависит от железа.
2 -SCS-UHU. в любом хекс редакторе поставь столбцы по 16 бит с выкл автопереноса и ищи в строке за номером 0015D00. если ищещь в HEX-е то смотри внимательно - ищи поиск 16-чных слов и вводи эту строку БЕЗ ПРОБЕЛОВ.
2LazyCamel. Эм, правильно ли я понимаю что для Вас не составить труда написать программу - измеритель частоты опроса джоя (типа mouserate)? Если да (не составит :) ) можно ли Вас просить о этом?
Джой тестер вешь нужная, но есть одно подозрение, связанное с профайлами кота+влияние на кота остальной ЮСБ периферии, которое только аналогом Mouserate проверить и можно.
Если уже такая прога есть - подкинтьте, плиз, ссылку.
Все бы хорошо но мелкомягкие ВСЕ устройства ХИД повесили на один драйвер и честно говоря я никогда не углублялся до того чтобы написать такую програмку. Мне дешевле и проще подправить в железке запрос, чтобы он просил почаще опрос, а как билин парни биллисофта будут из положени выкручиваться - дело другое :-)Цитата:
Сообщение от Shneck
А вот и программа. В дефолте способна показывать частоту обращений к джою до 1000Гц (1мс).
1. Выбираем джой;
2. Делаем палкой быстрые круговые движения и смотрим как бегают цифры.
У меня получаются значения, близкие к 1000. Так что видимо, всё в порядке...
З.Ы. В win98 программа работать, скорее всего, не будет.
-----
З.З.Ы. Программа показывает не сами обращения к джою, а изменения значений на его осях X и Y. Но по идее они не могут происходить чаще, чем обращения к джою, поэтому результаты проверки должны быть корректны.
Стукнись ко мне в асю или по почте. Я дам новую версию компонента для джойстика, там убраны ошибки кое-какие. Ну и ругаться триальным окошком не будет, я в ней случайно опять дебагером поковырялся :DЦитата:
Сообщение от Maximus_G
и наблюдаем дискреты 0-42-128-333-660. всё, 5 дискрет, что быстрые движения, что медленные.Цитата:
2. Делаем палкой быстрые круговые движения и смотрим как бегают цифры.
не, это фигня - нужна отдельная программа.
Извините, но фигня творится с вашим железом...Цитата:
Сообщение от Shneck
у вас, уважаемый, хотас кугар? нет? так что вы тут мое железо обсуждаете?
Окей, еще раз:
С нормальным железом таких дискретов нет.
критерий нормального железа в студию, плиз.
п.с. "окей, еще раз" своей подружке говорите, мне не надо.
эм, кугароведы, плиз, запостите здесь ваши результаты по частоте опроса кота (а не всякой виртуальной требухи), программа лежит здесь - http://forum.sukhoi.ru/showpost.php?...1&postcount=10
эм, проходила информация, что кто-то смотрел на ацп кота - кто знает - подскажите, пож-ста, какое у этого ацп быстродействие, это раз.
второе - джойстики же вроде вешаются как лоу спид юсб устройства, а мелкомягкие для лоуспид юсб устройств ввели явное ограничение на частоту опроса. кто может сказать, каким (лоу спид или нет) устройством видит винда кугар?
2LazyCamel. Гляньте, пож-ста, приват.
Неужели "эта фигня" по мнению гн.Shneck, таки оказалась полезным инструментом в выявлении проблем с железом?
Нда, трищ грубиян-гинеколог, не желающий корректно общаться, идет лесом...
идет лесом, имхо, тврщ с претензией на псевдонаучность.
критерий нормальности железа об-во так и не увидело, идет непонятное обсуждение о вкусе устриц с тем, кто их не пробовал. т.к. кроме "лесом" тврщ ничего сказать не может, пришлось просить коммунити подсказать параметры, ибо лично проблем с железом не вижу, а за базар отвечать привык.
вообщем в игнор.
вот DCU для версии 1.3Цитата:
Сообщение от UIV
Хм, не знаю насколько будет полезна моя информация. Вот картинка, которую нарисовал мой X52 - (кстати, после долгих плясок с бубном вокруг мервой зоны оного убедился в том, что первая буква - русская Хэ, а не английская Икс, как думают некоторые, причем эта Хэ совсем не от слова Хорошо). :rolleyes:
Картинку пришлось засунуть в архив, png почему-то приторочить нельзя.
В зависимости от скорости кручения ручкой цифирьки меняются от 0 до 900 с небольшим. В принципе может показать все, что угодно, какого-то конкретного шага дискретизации не заметил.
Спасиб! :)Цитата:
Сообщение от UIV
Алгоритм расчета частоты упрощенный (насколько хватило времени :) ): в данный момент времени проверяем, изменилось ли значение джоя, и если да, тоЦитата:
Сообщение от Avc
Freq = (1000 + Freq) / 2;
если нет - то
Freq = Freq / 2.
Поэтому при уменьшении скорости вращения ручки частота быстро падает, а при быстрой скорости - быстро достигает высоких значений, но затем до максимальных добирается медленно. Поэтому 900-950 - нормальная цифра, говорящая о том, что изменившиеся значения регистрируются почти в каждом такте.
Народ. Имхо вы херней страдаете, уж извините. В логе тогоже usbsniffa проставляется время получения ОСью пакета от джойстика.
Возьмите лог метров на 10, натравите на него парсер какой либо, чтобы период считал да и все.
Хорошая мысля, как известно, приходит опосля. Бум пробовать снифф. Тем более, есть устойчивые подозрения на некорректность компонента Timer, используемого в Joy PollFreq Check...
Спасибо Hruks - подсказал о, мягко говоря, несоответствии работы TTimer задаваемым параметрам... Задавая скорость таймера в 1мс (чтобы получить диапазон частот до 1000Гц), ничего толкового добиться нельзя. На моей машине реальная работа таймера не быстрей 15мс, что дает всего 64 максимальных Гц... Другими словами, цифры отображаемые программой не соответствуют действительности. Характер их изменения правильный, но абсолютные значения, увы, не правдивы.
И к сожалению я еще не нашел такого программного средства, которое реально позволило бы обрабатывать данные в цикле за хотя бы 2-5 миллисекунд... :/