Мышка называется W-Mouse и WX-Mouse





Программа тестирования нажатий кнопок мыши (проверка двойного клика) MBTester V2.0 описание внутри

Развёрнутый ответ.

Dx!, а какой программатор ?
Никто не запрещает выкинуть мой бутлоадер и пользоваться, например, FLIP. Дарадибога.
Установить на компе сам FLIP, DFU-драйверы и вывести на корпус мышки две кнопочки : reset и hwb.
И микросхему-супервизор с открытым стоком на контакте reset установить. Всего делов-то.
Другой программатор из "стандартных", который шьёт по SPI-линиям ? Пожалуйста. Всё то же, только вместо кнопочек
reset и hwb на корпус мышки вывести 6-контактный разъём и переключатель MISO. Любому юзеру - тоже пара пустяков,
не говоря уже о смешных фьюзах, которые известны каждому школьнику.

serj
Мышь не имеет лага движения больше, чем любая другая. Напротив, он даже меньше, чем в любой другой.
Что скрывается за выражением "динамический фильтр", что фильтровать. Хотя бы в двух словах : причина и следствие.
Как и, самое главное, для чего сделать загадочный компенсатор массы-инерции. Чтобы реакция системы была иной, нежели
силовые ощущения руки ? Хорошо, пусть актуально. Тогда для одной из координат имеем :
m*dx2/dt2 + b*dx/dt =~ Fx_руки
где b - сложнейшая, не поддающаяся никакому прогнозу нелинейная во времени функция - коэффициент трения.
где вычислить даже первую производную dx/dt - это надо хорошо постараться. А привести её в текущую точку t0 -
задача вообще провальная. На говоря уже о 2-й производной.
Но ладно, допустим, мы всё это преодолели : имеем обе производные, b у нас - измеренная константа,
мышку взвесили, получили Fx, всё знаем и... ?

О дефектах коврика. Откуда дефекты, и на что они влияют. Хорошо, пусть что-то есть, и оно мешает.
Сенсор живёт своею жизнью, раз в "когда_это_нужно" вычисляет по матрице пяток-десяток двойных интегралов и "когда_ему_удобно"
копит всё это фуфло в виде приращений координат. Как по этим данным можно вести речь о дефектах коврика и, тем более,
пытаться их обойти. И главное, зачем ?
И при чём тут материалы по получению изображения сенсора ? Даже если б сенсор мог запросто в реальном времени отдавать свою матрицу, и -
"дальше мучайтесь сами", то что, можно разработать алгоритм вычисления текущих Vx Vy ловчее, чем в сенсоре ?

Боже, я же ничего не имел в виду то. С вашим бутлоадером всё ок, просто первоначальное программирование (фьюзов тех же) один фиг нужно. Тут заходила речь о программировании/самопрограммировании двумя процессорами друг друга. Вот я и говорю - раз уж на такие высоты всё пошло - не проще ли таки сделать себе простой LPT или USB программатор (да да, вывести 6-контактный разъём) и приложить какойнить fuse_bootloader.bat да консольным программатором всё зашить? (например avreal32). А в bat файле уже указать все фьюзы чтобы не нужно было гадать - что же на этом скрине значит галочка - 0 или 1, programmed или unprogrammed, on или off.
Но я наверно чего-то как всегда недопонимаю.
И да, у мну никаких претензий - Вы мышку сделали. Я - нет, ничего не сделал. 8))
(Разве что откидывать MISO не нужно - только подтянуть к питанию nCS)

Просто раз уж кто-то начал паять микроконтроллеры - может ему было бы интересно сделать и следующий шаг - написать что-то своё. Контроллер есть, программатор тоже - почему нет? Тут такую шнягу народ паяет навесным монтажом, я бы на такое не пошёл, проще плату вытравить... Ведь всё может начаться с простого мигания светодиодом 8)))

Walkie как там 5.2 поживает?

Dx!
Да я вовсе не противник того, что программировать (первоначально и далее) можно как-то иначе. Люди разные. От тех, у кого уже
и программатор имеется, до тех, кто просто купил пару микросхем и затеял сборку собственной мышки. Первым и советы особо не
требуются. А вот вторым, чтоб не попали в тиски отсутствия опыта и нужного железа - я не смог придумать другого простого способа,
кроме как оживить контроллеры друг дружкой. Это не высоты, а скорее от "бедности" как бэ.
И тут опять же всё на местах. Пусть кто-то начал паять, захотел написать что-то своё, а контроллер-то уже и готовенький -
сам себе программатор без всяких разъёмов и других железок. Ведь не обязательно туда "мышка.hex" лить, можно и просто светодиодами помигать .

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

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

Walkie, я наконец-то купил ATtiny25, можно прошивку под неё? и краткую инструкцию по прошивке (фьзы нужны или нет? если нужны то какие)

Bubloid
Пожалуйста : Logitech-wheel convertor
Проверено - работает. Схема внутри. Установка фьюзов - wh518.txt

Вот пока что есть : V5.2
Флажок "Smooth" можно устанавливать и пробовать. Он более "шутерный", нежели общего назначения.
Пытается сглаживать и одновременно экстраполировать движение до +1 кадр монитора 60Гц.
Лучше всего работает, конечно, на ADNS-6090 с вертикальной оптикой и на ADNS-9500.
ADNS-3080 немного резковат из-за того, что норовит спрямлять движение.
В любом случае, наверное, надо привыкать.
Для датчиков 9500 ползунок LowFR игнорируется - сделан полный автомат управления частотой кадров
от 2000 до 11750 Гц в зависимости от текущей скорости.
Кривые EXP, LOG, Fn1-2 не менял. Если уж и пользовать ускорение, то по-любому лучше всего простая экспонента EXP.

Добавлено спустя 1 час 27 минут 21 секунду:
Добавлю по 5.2.
Ползунок LowFR задаёт частоту сканирования сенсором поверхности от 2 до 7 кГц для 6010(90) и от 2 до 6 кГц для 3080.
Установленная частота будет постоянна. Напомню : чем ниже частота и выше детальность коврика, тем вернее сенсор будет
вычислять слабые приращения координат. Но с понижением частоты и срываться будет на пропорционально меньших скоростях.
Для ADNS-9500 контроллер сам регулирует частоту сканирования, положение ползунка не играет роли.

Режим "Smooth" не любит неравномерного скольжения, микрорывков. Сделан больше для жестовой манеры управления
мышкой, где даёт хороший резкий останов и одновременно плавное изменение координат во время собственно перемещения.

спасибо бум пробовать

а при прошивке на 5.2 прежние установки сохраняются?

Добавлено спустя 7 минут 9 секунд:

а нельзя сделать адаптированый к скорости LowFR?
или хотя бы сделать скажем до 400мм/с =2кГц а выше максимальная частота...

BaCeK, профили сохраняются, я бы предупредил.
Я уж много раз пробовал найти сносный алгоритм управления переключением FR . Сенсоры, кроме 9500, после
получения команды несколько кадров "приходят в себя", творя произвол. Не даёт оно ничего положительного.

хм придется делать на 9500...
========
попробовал 5.2 в паинте и анриле.
в паинте с включонным зглаживанием стало заметно красивее - и линии и фигурки разные...

в анриле стало заметно хуже...
первую 5-ти минутку сыграл просто для вспомнить.
потом две подряд 60 и 70 с чемто попаданий за 5 минут.
Выключил сглаживание в результате две игры подряд - первая 100 попаданий вторая 113...
Со сглаживанием все довольно гладко и плавно чистенько так... но всевремя мимо то недолет прицела то перелет... мучения...

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

Добавлено спустя 50 минут 29 секунд:
побегал ону игру в BF ну ниче так... кажется лучше стало - меньше ложных вздрагиваний при небольших перемещениях...
читером вот назвали... хотя это случайность
#77

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

kemsky
Авто- нет смысла оставлять, я ведь писал. В датчиках ADNS режим autoFR - по сути фиксированный максимальный.
Когда мышь теряет коврик, FR становится минимальным. Когда есть контакт - сразу максимален. Вот и весь алгоритм.
Авто - это просто ползунок FR, загнанный в максимум.

BaCeK
Режим "Smooth" сложный. Одновременно и достоинства и недостатки. Сильно зависит от стиля управления и требует изрядного привыкания к его особенностям.
Главная особенность - эффект нестабильного лага движения. Образуется из-за не всегда верного предсказания. Чем нелинейнее жест, тем более лаг начинает
размазываться в диапазоне около 16мс. Это очень плохо, надо будет повозиться, усовершенствовать.
Одним словом, "Smooth" сейчас прилично работает только с датчиком 9500, стабильным по скольжению ковриком, верной рукой и низкими cpi .

вчера еще потестировал в BF-е, мне понравилось. правда играл с нубасами но всеравно хорошо было... вертолеты на ура начали сбиваться... Прикольно было когда летят два верта, пыщь пыщь два хедшота пилотам... и нету вертолетов...
Но сегодня вечером еще попробую с нормальными игроками (вчера патч на BF вышел а я не знал)

Всё-таки немного пришлось поправить параметры Smooth. Компромисс с учётом особенностей 3080.
Вот это немножко правильнее : V5.2b

Васёк, ты вчера вертолёты ловко сбивал, потому что не знал о патче. А теперь всё. Теперь фик. Чем больше знаешь,
тем меньше убитых вертолётов. Независимо от того, поставишь ты патч или продолжишь по-старинке.

а объясни пожалуйста по полярному в чом разница?:D
ненене... вчера непоставшие патч могли зайти только на соответствующие сервера т.е. которые не пропатчили... И такие тормозы в основном были нубасы... которые летают по прямой и часто зависают... и в них попасть проще...
но всеравно вчера было хорошо играть...
счас в себя приду после работы на выставке и буду пробовать 5.2b

BaCeK
Если по-пулярному, то примерно так.
Мышь стоит. Долго стоит. И вдруг ... о, ужас, начинает двигаться. В самом начале движения невозможно сделать даже приблизительный прогноз на будущее.
Поэтому некоторое время контроллер вынужден собирать данные, анализировать, а системе пока что передавать приращения напрямую от сенсора.
Эти приращения пока ещё нельзя интерпретировать как текущую скорость. Это именно кусочки пути, несмотря на то, что они забирались у сенсора
в интервалом ровно 1 мс. То есть, для ADNS-3080 каждый выданный тик - это не грубый скачок скорости на 15.875 мм/с (1/1600*25.4/0.001), а именно кусочек
коврика 25.4/1600 = 0.01587 мм.
Когда информации набирается достаточно для прогноза, происходит плавное переключение в режим сглаживания-экстраполяции, где данные представляются
уже текущей скоростью, причём со сдвигом в "будущее". Теперь система каждую 1мс может получать более равномерные кусочки пути. И поскольку эти
кусочку ещё и имеют упреждение, дисплей сможет "рисовать" реакцию, более соответствующую реальному положению мышки на ковре.

Вот реальный Smooth-пример, где делается пара элементарных горизонтальных сдвигов вправо. Такие приращения dX выдаются системе при 250 Гц USB-опроса.
В самом начале - прямо от сенсора, а затем ему "слегка вправляют мозги" :
#77
Так вот для нормальной и хоть сколько-нибудь полезной работы этого хозяйства очень важно оптимально подобрать все параметры анализа-переключения и пр.
И в 5.2б они просто немного изменены. В частости, увеличено время предварительного анализа.

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

СПАСИБО!

Васёк, рисование в пайнтах, кстати - далеко не показатель. Представь, некая прога вычитывает текущие положение курсора
в неизвестные моменты, и каким-то ей известным образом соединяет считанные точки линиями. Или кривыми, или ещё хрен чем
по нескольким точкам. То есть далеко не всегда так уж верно отображает настоящую траекторию движения.