Вектор-06Ц. подключение USB-мыши.

[KTSerg]

Добавил в контроллер USB-мыши регистры, предоставляющие информацию о смещении мыши, а не её координаты.
Сделал универсальный тест контроллера мыши.
Исходники во вложении к первому сообщению темы.
На фотках: контроллер отключен, подключен к порту "ПУ", и "ВУ".

Тесты наводят на мысли, что математику в контроллере нужно переводить на работу с положительными числами, как это сделано в PS/2-мышах. Там смещения всегда положительные числа, а направление указано специальными флагами.
Работать с переменными типа int удобнее (всегда используется сложение, не нужно заранее контролировать направление), и сама USB-мышь выдаёт значения именно типа int. Но при замедлении мыши делением скорости на 8, возникают трудности с отрицательными значениями, так как простое смещение значения на 3 бита вправо (деление на 8), "округляет" полученное значение до "-1" (FFh) даже если смещение изначально было например только "-3", хотя желательно при этом получить "0".
А при округлении положительных смещений, все значения смещения от 1 до 7, в результате округляются до "0" ( как и ожидается ).
Вот и размышляю, как поступить, дрейф значений не значительный, и особо для пользователя не заметен.
На универсальном тесте этот дрейф значений заметен по выводимым на экран значениям координат курсора мыши.
В верхней строке, 2е и 3е значение - это содержимое регистров контроллера, в них проблем от округлений значений нет из-за особенностей вычислений координат (вычисления ведутся постоянно, без корректировки значений).
В нижней строке, 2е и 3е значение - это координаты курсора, вычисляемые на основе значений регистров смещения.

В любом случае, корректировка работы с отрицательными числами в контроллере, ни как не влияет на работу с самим контроллером со стороны пользователя. Просто в результате, пользователь сможет получать более корректные значения.

Кстати, мысля сейчас посетила, вариант стандарта значений смещения как в PS/2-мышах, можно так-же в контроллер засунуть, на отдельные регистры.

[Advertiser]

[KTSerg]

Пока прикручивал к контроллеру регистры 6 и 7, обнаружил косячокс...
Изначально решил, что контроллер будет предоставлять данные исходя из того, что "начало координат" находится в нижнем-левом углу экрана Вектора.
Но при вычислениях 5-го регистра временно не стал его инвертировать в контроллере, а сделал это в программе Вектора.
И конечно благополучно об этом забыл. Начал добавлять новые регистры смещения, и увидел, что с вычислениями что-то не так.

Короче внёс инверсию значения смещения по "Y" в контроллер, из программы для Вектора можно эту инверсию убирать.
Перезалью исходники в первом сообщении, когда допилю регистры 6 и 7.

[KTSerg]

Чем больше вожусь с "контроллером мыши", тем больше мне не нравится привязка одного регистра к другому.
К примеру у PS/2-мыши, все регистры читаются последовательно, начиная с "0"-го (кнопки/флаги).
И видимо при чтении "0"-го, значения остальных фиксируются в каких-то буферных регистрах для их выгрузки, и это логично и нормально.
В таком случае нет ни чего особенного, что в регистре "0" хранятся флаги направления движения, для смещений, которые находятся в остальных регистрах.
Но на Векторе, регистры контроллера могут считываться независимо, друг от друга, значит размещение значения в одном регистре, а "флагов" для него в другом регистре, создаёт привязку и обязанность программиста обязательно считывать эти пары в определённом порядке.
Это не сложно, но мне не нравится.
Сейчас в регистре "0" хранится младший бит координаты по оси "Х" для регистра "1". И значение регистра "1" обновляется только при чтении регистра "0".
И это только для возможности использования режима разрешения 512х256. При том, что наиболее популярно разрешение экрана 256х256.
Аналогичная ситуация с новыми регистрами "6"-смещение по "Х", и "7"-смещение по "Y". Их значения всегда положительные в диапазоне от 0 до 127, а флаги направления (у мыши PS/2) хранятся в "0"-ом регистре.

Думаю поступить следующим образом:
Для регистра "1" - младший бит и дальше хранить в регистре "0", только сделать привязку значений наоборот. Т.е. в регистре "0" состояние кнопок обновляется постоянно и не зависимо от других регистров, их состояние при любом чтении регистра "0" всегда актуально. А вот значение младшего бита обновлять только когда читается регистр "1".
В таком случае, для режима экрана 256х256 все регистры контроллера не будут зависеть друг от друга, и могут быть прочитаны в любой комбинации и в любой последовательности. Мне кажется это удобнее.
А вот если пользователь захочет использовать мышь в режиме разрешения экрана 512х256, и пользоваться регистрами "1" и "2" (координатами курсора), просто нужно будет после чтения регистра "1" (получив значение смещения по оси Х), дополнительно прочитать регистр "0", для получения актуального значения младшего бита координаты.
В принципе, всё сводится к тому, что для режима экрана 256 читать регистры ("0", "1", "2") можно в любой последовательности. А для режима 512 : "2", "1", "0" (или "1", "2", "0"), главное, читать регистр "0" после регистра "1".

Для новых регистров "6" и "7", думаю флаг направления хранить в старшем бите самого регистра.
Значение "0" старшего бита означает смещение мышки в положительном (вправо или вверх) направлении оси, "1" - в отрицательном направлении (влево или вниз).

На данный момент, режим экрана 512 корректно поддерживается контроллером только регистрами "1" и "2" (координатами курсора).
В остальных регистрах смещения по оси "Х" ("4" и "6") скорость перемещения корректна для режима экрана 256. Если перемещать курсор с учётом всех пикселей в режиме экрана 512, то скорость перемещения уменьшится в 2 раза.
Как решить проблему корректировки скорости при переходе на режим экрана 512, я пока не знаю, точнее сказать не принял однозначного решения.
Варианта два:
1. как и с регистром "1", поместить в регистр "0" дополнительный младший бит смещения по оси "Х".
2. в регистр управления контроллером мыши, добавить бит переключения скорости смещения курсора по оси "Х". ("0" - для 256х256, "1" - 512х256).

[Improver]

Как решить проблему корректировки скорости при переходе на режим экрана 512, я пока не знаю, точнее сказать не принял однозначного решения.
Варианта два:

Можно и третий вариант: просто забить на 512 и в этом режиме указатель мыши перемещать просто по чётным (или нечётным) пикселям, и тогда скорость движения не изменится. Не думаю, что кому-то когда-нибудь понадобится "двойная" точность, но если вдруг, то есть регистр "0" на этот случай и программист, который скорректирует скорость перемещения в своей программе.

[ivagor]

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

[KTSerg]

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

Вариант предоставления Вектору сырых данных перемещения мыши, подходит для PS/2-мышей.
К огромному сожалению, usb-мышь гонит данные постоянно пока с ней есть какие-то манипуляции. А если Вектор будет получать сырые данные один раз в 20мс, то ни о каком контроле за перемещениями речи идти не будет, так как практически все данные будут теряться.
Именно по этому контроллер и готовит данные для Вектора. Собирает все данные о перемещениях, и предоставляет Вектору, по запросу, уже итоговую сумму всех перемещений за промежуток между запросами Вектора.

Решил, что ни как не буду корректировать скорость по "X" для режима 512.
Поскольку реальный контроллер вряд-ли кто-то ещё будет собирать, а если вдруг "контроллер мыши" появится в эмуляторе, то там этот вопрос вообще не актуален, так как смещение по осям будут браться из перемещения по экрану курсора РС, соответственно и коррекция скорости не нужна.

А для тех кто решит делать реальный контроллер, я дал подсказки, из своих экспериментов, что для комфортного перемещения курсора по экрану Вектора, данные мыши нужно делить на 8. Суммирует реальные полученные от мыши данные, а по запросу, предоставляет данные делённые на 8. Так не теряются мелкие движения мыши. Если делить на 8 сразу, и потом прибавлять к счётчику, то для смещения курсора на 1 пиксель, нужно довольно значительно дёргать мышью.
Это результаты моих экспериментов, они очень субъективны.

[ivagor]

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

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

[KTSerg]

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

Регистры 4 и 5 именно в таком формате и содержат данные.
Для USB-мыши, стандарт - это целое со знаком, от -128 до +127.

На тестах я пытался перемещать (дёргать) мышь с максимально возможной скоростью, получил пиковые скорости перемещения в пределах 80-90 пикселей за 20мс. Это уже адаптированная для Вектора скорость.

[ivagor]

Хорошо, насчет "делать это в формате, который получает от мыши" я погорячился, реализовать это 1 в 1 не очень хорошо. Основная проблема, которую хотелось бы преодолеть - потеря точности. Движение курсора - частная задача, и подгонять мышь к разрешению вектора - так себе вариант для мыши 2024 года. Лучше бы оставить полную точность добавив регистр или даже два с младшими частями смещений, которые, как понимаю, сейчас отбрасываются.

- - - Добавлено - - -

Хотя бы в варианте для ВУ.

[KTSerg]

Хорошо, насчет "делать это в формате, который получает от мыши" я погорячился, реализовать это 1 в 1 не очень хорошо. Основная проблема, которую хотелось бы преодолеть - потеря точности. Движение курсора - частная задача, и подгонять мышь к разрешению вектора - так себе вариант для мыши 2024 года. Лучше бы оставить полную точность добавив регистр или даже два с младшими частями смещений, которые, как понимаю, сейчас отбрасываются.

- - - Добавлено - - -

Хотя бы в варианте для ВУ.

У usb-мыши, данные перемещения так-же имеют разрядность байт. Просто за 20мс в счётчике может накопиться 10бит-ное значение, скорее всего, примерно до 800 пикселей.

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

Я вроде где-то писал причину, по которой начал делить скорость на 8.
Когда использовал родные данные, для перемещения курсора на экране Вектора, то курсор пробегал от края до края экрана за 1см перемещения мыши по коврику.
Ни о какой точности позиционирования курсора не может быть речи, курсор слишком чувствителен.