Просмотр полной версии : Вектор-06Ц. подключение USB-мыши.
Я всё думаю, как мышь прицепить...
PS/2 - просто, но получение данных занимает очень много времени, и реализация на эмуляторах не очевидна, в виду малого количества реалов и большей доступности эмулятора - такой вариант подключения не очень практичен. :(
Нашел USB-хост на stm32f103, в продаже есть готовые платы, не очень дорогие.
...
Сошлись таки "звёзды на небе", ..... подключил USB-мышь к реальному вектору, через контроллер.
Пока сделал самый простой в реализации вариант, контроллер мыши выдаёт состояние клавиш и текущие координаты "курсора" по осям в диапазоне: для Х - [0-511] для Y - [0-255] ;)
Начало координат - нижний левый угол.
Пока без колеса прокрутки.
В регистре состояния клавиш, хранится младший бит (дополнительный) положения курсора по оси "Х".
Собственно, если этот младший бит не учитывать, то в режиме экрана 256х256, указатель имеет диапазон из регистра [0-255].
А при переключении экрана в режим 512х256, учитывая дополнительный младший бит координаты "Х" можно позиционировать все точки экрана, скорость перемещения курсора не изменится.
"Контроллер USB-мыши" собран на stm32f103ret6 (что было под рукой).
Данные из мыши контроллер читает через "usb-hub" собранный на чипе "max3421e". ;)
Готовая плата usb-hub на max3421e, обошлась примерно 300руб. Вредная, но юзать вполне можно.
Подключается контроллер к "ПУ" Вектора, порт С - управление, А - выставляется номер регистра контроллера, В - чтение данных из выбранного регистра.
; Порт 5:
; бит С5 - запись - вкл/сброс мыши, "0" - вкл. , "1" - откл. и сброс начальных координат в 128/128
; бит С4 - запись - строб запроса данных, перед чтением данных из мыши, нужно сбросить бит в "0", затем восстановить в "1"
;
; Порт 6:
; В7-0 - чтение - байт данных из мыши
;
; Порт 7:
; биты А3-0 - запись - номер регистра контроллера мыши, для чтения данных
; регистры контроллера мыши:
; регистр "0" - состояние кнопок и младший бит "Х" для режима экрана 512/256
; бит 7 - "левая" кнопка мыши "1" - нажата
; бит 6 - "правая" кнопка мыши "1" - нажата
; бит 5 - "средняя" кнопка мыши "1" - нажата
; бит 0 - младший бит "Х" для режима экрана 512/256
; регистр "1" - "Х" положение курсора мыши (от 0 до 255), значение обновляется только при чтении регистра "0"
; регистр "2" - "Y" положение курсора мыши (от 0 до 255), значение обновляется независимо от чтения других регистров
За кнопки мыши, отвечают биты, которые были описаны в тех-доках на Вектор. Там есть описание подключения мыши к Вектору, и соответствие кнопок-бит. Они отзеркалены по отношению к стандарту для USB и РС/2 мышей.
Взял вариант уже предложенный для Вектора.
С младшим битом положения по "Х" для режима экрана 512х256, получилось очень удобно.
Из-за особенностей реализации этого режима, этот "младший бит" отвечает за переключение плоскостей, а не за координату на плоскости. Соответственно, по значению из регистра для "Х" (№1) вычисляем позицию указателя по горизонтали, а по состоянию "младшего бита" выбираем экранную плоскость.
Во вложении исходник и "rom" теста контроллера. Сочетание клавиш пкм+скм - переключает экран в режим 512х256, пкм+лкм - в режим 256х256 точек.
;
MVI A,82H ; ПУ - А,С на вЫход , В на вход
OUT 4
MVI A,0FFH
OUT 5 ; отключить/сбросить мышь
OUT 7 ; номер регистра мыши НЕ указан
;------------------------
;========== инициализация мыши ==============
mvi a,0Ah ; бит 5 - "0" - включить мышь
out 4
;============================================
RDMous: ; прочитать
;--------------- прочитать регистры мыши -----------------
xra a ; регистр "0"
out 7
mvi a,08h ; строб бит 4 в "0"
out 4
mvi a,09h ; строб бит 4 в "1"
out 4
in 6 ; чтение выбранного регистра
STA MKey ; сохранить состояние кнопок
mvi a,01h ; регистр "1"
out 7
mvi a,08h ; строб бит 4 в "0"
out 4
mvi a,09h ; строб бит 4 в "1"
out 4
in 6 ; чтение выбранного регистра
STA POSMX ; сохранить позицию Х
mvi a,02h ; регистр "2"
out 7
mvi a,08h ; строб бит 4 в "0"
out 4
mvi a,09h ; строб бит 4 в "1"
out 4
in 6 ; чтение выбранного регистра
STA POSMY ; сохранить позицию Y
;
При тесте usb-мыши, возник вопрос, что делать со скоростью перемещения курсора...
На РС-шном экране с большим разрешением, курсор проходит от края до края, при перемещении мыши примерго сантиметров на 7-8, это привычная скорость.
А у Вектора всего 256х256 - курсор пробегал от края до края примерно за 1см перемещения мыши по коврику... 8()
Пришлось уменьшить скорость в 8 раз.
Сейчас перемещение указателя мыши по экрану Вектора вполне комфортно.
На скриншоте - тест мыши. "Сетка" помогает понять как движется "указатель мыши", и визуализировать режим экрана 512х256.
Исходник проекта для stm32 на Keil можно будет потом выложить. Пока в нём много мусора, так как переделывался из исходников, скачанных с просторов и-нета.
Откопал в кладовке плату с ПЛИС, у которой распаян переходник на "ВУ", в сырец старого проекта добавил "мост" между портом D4h и "контроллером USB-мыши", поменял в тестовой программе чтение регистров "контроллера мыши".
"Контроллер USB-мыши" переткнул с "ПУ" в разъём платы ПЛИС, и все дела.
Во вложении исходник и rom, с тестом USB-мыши, подключенной к шине "ВУ".
;
; тест USB-мыши в разъёме "ВУ"
; 08.2024
;--------------------------------------------------
; порт D4h - на запись - слово управления контроллером мыши
;
; бит 5 - запись - вкл/сброс мыши, "0" - вкл. , "1" - откл. и сброс начальных координат в 128/128
; биты 3-0 - запись - номер регистра мыши, для чтения данных
;
; порт D4h - на чтение - данные из запрошенного регистра контроллера мыши
;================================================= ================================================== ====
;========== инициализация мыши ==============
mvi a,0DFh ; бит 5 - "0" - включить мышь
out 0D4h
;
;================================================= ========
RDMous: ; прочитать и вывести на экран
;--------------- прочитать регистры мыши -----------------
;
xra a ; регистр "0"
out 0D4h
in 0D4h ; чтение выбранного регистра
STA MKey ; сохранить состояние кнопок
mvi a,01h ; регистр "1"
out 0D4h
in 0D4h ; чтение выбранного регистра
STA POSMX ; сохранить позицию Х
mvi a,02h ; регистр "2"
out 0D4h
in 0D4h ; чтение выбранного регистра
STA POSMY ; сохранить позицию Y
;
Так-же во вложении проект на Квартус, для ПЛИС EP4CE6E22C8.
Я криворукий прогер на верилоге, даже на любиреля не тяну, за стиль не пинать.
Но надеюсь запись и чтение порта будет понятна.
Для "Мыши" выбрал порт D4, так как 4Dh - код символа "М".
Архив MOUSE_USB_R9 содержит исходник универсального теста и адаптера контроллера на шину ВУ, для контроллера, предоставляющего доступ к ДЕВЯТИ регистрам ( кнопки, X, Y, W, mX, mY, , Xps, Yps, Id ).
Архив MOUSE_USB_R12 содержит исходник универсального теста контроллера, добавлены регистры: 8, 9, 10.
Это сырые данные мыши. Данные регистров 9 и 10 смещения только защищаются от переполнения.
"0" кнопки - состояние кнопок и младший бит координаты "Х" для режима экрана 512х256
бит 7 - "левая" кнопка мыши "1" - нажата
бит 6 - "правая" кнопка мыши "1" - нажата
бит 5 - "средняя" кнопка мыши "1" - нажата
бит 0 - младший бит координаты "Х" для режима экрана 512х256, значение обновляется только при чтении регистра "1"
"1" - "Х" координата курсора мыши (от 0 до 255)
"2" - "Y" координата курсора мыши (от 0 до 255)
"3" - колесо прокрутки, правда с моими мышами не работает;
"4" - смещение мыши по X, за период между чтениями этого регистра от -128 до 127 ( от 80h до 7fh );
"5" - смещение мыши по Y, за период между чтениями этого регистра от -128 до 127 ( от 80h до 7fh );
"6" - смещение мыши по "X" между чтениями этого регистра от 0 до 127 ( бит 7 - направление "1" - влево )
"7" - смещение мыши по "Y" между чтениями этого регистра от 0 до 127 ( бит 7 - направление "1" - вниз )
"8" - состояние кнопок
бит 0 - "левая" кнопка мыши "1" - нажата
бит 1 - "правая" кнопка мыши "1" - нажата
бит 2 - "средняя" кнопка мыши "1" - нажата
"9" - "Х" смещение курсора мыши (от -127 до +127) сырые данные мыши
"10" - "Y" смещение курсора мыши (от -127 до +127) сырые данные мыши
"15" - регистр идентификатора, выдаёт значение 6Dh, позволяет определить факт подключения контроллера.
На фото, четыре крайние левые столбца экрана - статистика значений регистров R4, R5, R6, R7 (соответственно) полученных от контроллера позволяет определить максимальные значения регистров - максимальное смещение мыши за отрезок времени.
Добавил во вложение "arkanoid", адаптированный под контроллер USB-мыши, разъём "ВУ", порт D4h.
Если "контроллер мыши" не подключен, то управление обычное.
Визуальное отличие - в нижнем левом углу экрана есть маркер и отображаются байты, прочитанные из регистров "0" и "4" контроллера.
В каталоге обнаружился исходник игры "MINSWEEPER", сделал из неё демонстрашку мыши, во вложении "MINES_M".
Адаптирована под контроллер USB-мыши, разъёмы "ПУ" и "ВУ".
Если "контроллер мыши" не подключен, то управление обычное.
Визуальное отличие - в верхнем левом углу экрана есть маркер и отображаются байты, прочитанные из регистров "0", "1" и "2" контроллера.
На дополнительном скриншоте экран теста контроллера R12.
Добавлены столбцы статистики для регистров R9, R10.
Во второй строке состояние добавленных регистров R8, R9, R10.
В тесте R12:
клавиша "РУС/LAT" - переключает на перемещение мыши по данным регистров 1 и 2.
клавиша "УС" - переключает на перемещение мыши по данным регистров 4 и 5.
клавиша "СС" - переключает на перемещение мыши по данным регистров 9 и 10.
игра "mines" - для экспериментов есть сборка с "сервером мыши" и конфигом для эмулятора emu https://zx-pk.ru/threads/35656-vektor-06ts-podklyuchenie-usb-myshi.html?p=1202779&viewfull=1#post1202779
игра ARKANOID - для экспериментов есть сборка с "сервером мыши" и конфигом для эмулятора emu https://zx-pk.ru/threads/35656-vektor-06ts-podklyuchenie-usb-myshi.html?p=1202815&viewfull=1#post1202815
игра COLLINES - для экспериментов есть сборка с "сервером мыши" и конфигом для эмулятора emu https://zx-pk.ru/threads/35656-vektor-06ts-podklyuchenie-usb-myshi.html?p=1202874&viewfull=1#post1202874
Improver
26.03.2024, 07:05
Да, думаю, лучше начать с простого, а если тема пойдёт, то и ПДП можно, и колесо добавить... Хотя, отражение портов на память -- не Векторовский метод.
Да, думаю, лучше начать с простого, а если тема пойдёт, то и ПДП можно, и колесо добавить... Хотя, отражение портов на память -- не Векторовский метод.
Колесо добавить, даже на "ПУ" - не проблема, 4 бита управления, один можно использовать для замены данных "Y" на данные о состоянии колеса.
Мысль о ПДП прицепилась случайно, при обдумывании возможности переноса контроллера с "ПУ" на "ВУ", и упрощении опроса мыши.
Improver
26.03.2024, 11:45
Колесо добавить, даже на "ПУ" - не проблемаДа, не проблема, но не в этом дело... Если мышь будет подключена, "пойдёт в народ", появится под неё хотя бы с десяток программ (новых и/или адаптированных старых), то потом можно и усложнять -- добавлять колёса, настройки... На первых порах пусть будет хотя бы просто координаты и две кнопки, а так тут уже не раз обсуждалось подключение мыши, только пока результата нет.
... На первых порах пусть будет хотя бы просто координаты и две кнопки,...
Я пока думал для начала действительно сделать чтение с контроллера текущих координат. Но потом задумался, как адаптировать Арканоид?
Если мышь достигла крайней координаты, а каретка ещё нет (она ведь сдвигается направлением/смещением), то её не возможно будет сдвинуть дальше. Нужно будет полностью переделывать управление кареткой, привязывать его не к "нажатию клавиш курсора" а к координатам положения мышки. Над этим нужно будет думать отдельно, адаптация будет сложнее, чем в случае чтения с контроллера смещений мыши.
Ломать копья я не стану, но на всякий случай напомню с нехарактерной для меня категоричностью, что передавать от мыши абсолютные координаты -- гнилая идея.
Если реализовывать мышь на микроконтроллере, что по-моему правильно, нельзя ли сделать в нем внутреннюю очередь? Пусть копит буфер, а программа на Векторе будет читать данные, пока они есть. В контроллере можно сделать промежуточное накопление, чтобы без потерь отдавать в Вектор накопленные данные меньшим количеством пакетов. То есть например, если пришло 1, 1, 3, а Вектор в это время делал что-то еще, когда он спросит можно отдать сразу 5. Если накопилось больше 127, отдавать по частям.
Improver
26.03.2024, 14:29
адаптация будет сложнее, чем в случае чтения с контроллера смещений мыши.В любом случае, на Векторе нет программ, в которых внедрение мышки было бы простым, все в той или иной степени адаптированы к кнопкам. Но если преодолеть эти сложности, то мышка тогда не превратиться в унылый эмулятор джойстика/клавиатуры.
...
Если реализовывать мышь на микроконтроллере, что по-моему правильно, нельзя ли сделать в нем внутреннюю очередь? Пусть копит буфер, а программа на Векторе будет читать данные, пока они есть. В контроллере можно сделать промежуточное накопление, чтобы без потерь отдавать в Вектор накопленные данные меньшим количеством пакетов. То есть например, если пришло 1, 1, 3, а Вектор в это время делал что-то еще, когда он спросит можно отдать сразу 5. Если накопилось больше 127, отдавать по частям.
Я размышлял аналогично.
Пусть контроллер суммирует все перемещения между запросами, и выдаёт уже итоговое значение перемещения.
Думаю, что если перемещение было больше чем 127 (половина экрана), этого вполне достаточно. Но отдать 127 из большего перемещения, тоже не проблема.
Для начала нужно со средой разработки для stm32 разобраться, установлена древняя версия, а свежую скачать не могу, хоть она и бесплатная.
- - - Добавлено - - -
В любом случае, на Векторе нет программ, в которых внедрение мышки было бы простым, все в той или иной степени адаптированы к кнопкам. Но если преодолеть эти сложности, то мышка тогда не превратиться в унылый эмулятор джойстика/клавиатуры.
Воткнуть в контроллер оба режима смещение/координаты, не проблема. Подозреваю, что свои "плюсы" можно найти в обоих режимах (если поискать).
Главное, что-бы в контроллере вообще режим usb-хост заработал.
Improver
26.03.2024, 15:31
Кстати, интересная идея: а что если для мышки использовать магнитофонный вход? При работе Вектора он практически всегда свободен, поддерживает горячее подключение/отключение, есть подпрограммы по чтению байтов с него, скорости должно хватить... Да, туда идёт и музыка с ВИ, но писать на мышку надо гораздо меньше, чем читать. :)
Для начала нужно со средой разработки для stm32 разобраться, установлена древняя версия, а свежую скачать не могу, хоть она и бесплатная.
Ты твердо определился с выбором контроллера? Популярный молодежный тренд сейчас ch32x035.
Ты твердо определился с выбором контроллера? Популярный молодежный тренд сейчас ch32x035.
Пока да. Буду пробовать на stm32.
Если молодёжь будет использовать ch32x035, буду только рад.
Если молодёжь будет использовать ch32x035, буду только рад.
CityAceE учит программировать RISC-V (https://www.youtube.com/watch?v=XNPolrDzr5s), bitluni запилил самодельный ассемблер для ch32x035 (https://www.youtube.com/watch?v=UPd5qPuhOCs). Жизнь проносится мимо.
Подключил USB-мышь к "ПУ" Вектора.
Подробности в первом сообщении темы.
Подключил USB-мышь через "ВУ" Вектора.
Подробности в первом сообщении темы.
(Затаив дыхание жду, что же будет, когда в третий раз закинет старик невод).
(Затаив дыхание жду, что же будет, когда в третий раз закинет старик невод).
Кроме мыши, я ни чего не планировал подключать.
Хотя судя по описанию:
USB Host Shield 2.0 построен на микросхеме MAX3421E, которая может выступать в роли хоста USB-соединения. Общение её с основным микроконтроллером происходит по интерфейсу SPI (на скорости до 26 Мбит/с). В режиме хоста микросхема поддерживает USB 2.0 Full и Low Speed (12 Мбит/с и 1.5 Мбит/с).
Библиотека поддерживает следующие внешние устройства:
устройства Android (в режиме «периферии», ADK)
HID-совместимые устройства, такие как клавиатура, мышь и т.д.
CDC-устройства – эмуляторы COM-портов
Геймпады от PS3, PS4, Nintendo Wii, Xbox One и Xbox 360
Цифровые зеркальные камеры, такие как Canon, Nikon, Powershot и т.д.
Устройства Mass Storage хранения данных, такими как USB-накопители, устройства чтения карт памяти, внешние жесткие диски
Некоторые адаптеры Bluetooth
Другие устройства последовательной связи USB, такие как GPS, FTDI и т. д
Можно даже флешку подцепить, и вроде как уже даже готовая библиотека имеется.
Как я уже писал, реальных Векторов мало, и я не уверен, что кто-то повторит в железе мой "контроллер usb-мыши для ПУ" и его "адаптер для ВУ".
Но я предложил работающий вариант для реализации "адаптера" в эмуляторах.
Если эмулятор предоставит данные о положении мыши через порт "D4", то даже программы на Бейсике смогут этим пользоваться :)
Какое раздолье для фантазии, при реализации пользовательского интерфейса в потенциальных (программах) игрушках ;)
Только над идентификатором подключения контроллера, нужно подумать.
Я подключаю к FPGA, но проблема та же. Текущий план использовать для этого Pi Pico (в моем случае rp2040-zero, но разницы нет). Пока только смотрел примеры от TinyUSB. Тоже обратил внимание на то, что бесплатно можно подключить mass storage на тот же usb порт. Пока не придумал зачем, но прикольно, когда можно.
Геймпад 8bitdo SN30Pro зацепился, но требует чего-то еще, пока не разобрался. Клавиатура одна завелась, вторая нет.
Еще есть адаптеры из USB в последовательный порт на CH9350DS. Они удобные, потому что вообще ничего делать не надо. Просто выдают HID пакеты на последовательный порт. Но там если что-то не поддержалось, то уж точно никаких шансов исправить положение нет. Поэтому я пока решил что на Пипико более перспективно.
... Текущий план использовать для этого Pi Pico (в моем случае rp2040-zero, но разницы нет). ...
rp2040-zero - выглядит интересно, правда как по мне, выводов GPIO маловато... "не развернёшься" ;)
Сначала не обратил внимания, почему ни в одном из примеров "USB-мыши" не юзают колесо прокрутки, только 3 кнопки и X/Y, хотя по протоколу от мыши приходит пакет из 8 байт.
Начал кидать все 8 байт на экран... а колесо не активно!!!
Получается так-же как и у ps/2 мыши его включать нужно... а это не гуглится.
Если сильно "зачешется" разобраться, нужно будет запускать на компе прогу с логгером USB-порта, подключать мышь и смотреть обмен, может команда включения колеса найдётся...
а это не гуглится
Нагуглилось на самом деле. Я правда не нашел твоих исходников для stm32, поэтому не уверен, что это подойдет. Но если ты используешь ту же самую библиотеку TinyUSB, то подойдет.
Протокол при инициализации выбирается Boot. На Report он переключается так из колбаска tuh_hid_mount_cb():
tuh_hid_set_protocol(dev_addr, instance, HID_PROTOCOL_REPORT)
Репорты тогда будут приходить в таком формате. Поскольку hid_mouse_report_t TinyUSB как-то сразу узурпировало под BOOT, пришлось назвать его hid_wheelmouse_report_t:
typedef struct TU_ATTR_PACKED
{
uint8_t report_id; // mouse=1
uint8_t buttons;
int8_t x;
int8_t y;
int8_t wheel;
} hid_wheelmouse_report_t;
Соответственно надо подменить этот тип в колбасках, которые обрабатывают мышиные репорты и будет хорошо. У меня колесо ожило.
- - - Добавлено - - -
P.S. попробовал другую мышь и она шлет колесо в BOOT протоколе. А первая вот не слала.
Нагуглилось на самом деле. Я правда не нашел твоих исходников для stm32, поэтому не уверен, что это подойдет. Но если ты используешь ту же самую библиотеку TinyUSB, то подойдет.
...
P.S. попробовал другую мышь и она шлет колесо в BOOT протоколе. А первая вот не слала.
Внимательнее глянул дескрипторы мыши, в них нет протоколов "приёма" данных, только "отправка".
Значит у USB-мышей не предусмотрены настройки по стандартному протоколу (каналу).
Да, надо будет смотреть обработку прерываний.
Исходник в котором я ковырялся, и из которого переделывал в "контроллер мыши", написан для "pic18f26k20" https://github.com/felis/lightweight-usb-host.
В нём предусмотрен интерфейс пользователя по UART, несколько вложенных меню, для изучения МАХ3421 и состояния подключения.
В итоге (когда немного разобрался) достаточно было переопределить pin-ы с pic-а на мой stm32, подшаманить SPI и USART, и проект завёлся. Дальше только косметические изменения под протокол "ПУ".
P.S. попробовал другую мышь и она шлет колесо в BOOT протоколе. А первая вот не слала.
Мне тоже нужно попробовать другие мыши.
МАХ не выставляет флаг запроса прерывания при вращении колеса. Запрос прерывания выставляется только при перемещении мыши и нажатии/отпускании кнопок. При этом МАХ сообщает, что из буфера нужно забрать ТРИ байта, хотя по дескриптору мыши, в протоколе 4 байта.
Любопытно, TinyUSB похоже не поддерживает host на stm32 судя по этой табличке https://docs.tinyusb.org/en/latest/reference/supported.html
Любопытно, TinyUSB похоже не поддерживает host на stm32 судя по этой табличке https://docs.tinyusb.org/en/latest/reference/supported.html
Ну да. В них USB юзабельный, но хилинький, я копаю исключительно серию F1. С серии F4 вроде начинался "крутой" usb, но мне такие не попадались, и я даже подробности не узнавал.
Проводные мыши у меня оказались одинаковые, даже vid/PID совпадает, а беспроводная, с дескрипторами какая-то фигня...
По итогу, у меня, ни с одной мышью колесо не работает. Беспроводная реагирует, когда кручу колесо, происходят прерывания, но "МАХ" по прежнему сообщает, что в буфере только ТРИ байта, и они не изменяются при вращении колеса.
У меня вот есть клавиатура, которая работает со всеми компами, но ни ch9350 ни TinyUSB не могут ее проинициализировать. TinyUSB говорит, да, это клавиатура. И всё.
У меня вот есть клавиатура, которая работает со всеми компами, но ни ch9350 ни TinyUSB не могут ее проинициализировать. TinyUSB говорит, да, это клавиатура. И всё.
Не удивлён.
Дескрипторы слишком запутанная штука, что-бы "Tiny" версии драйверов, могли их корректно распарсить. У комповых драйверов на много больше возможностей и ресурсов.
Думаю если внимательно изучить различия в дескрипторах, то можно настроить.
У меня вот беспроводная мышь определяется как "составное устройство - клавиатура".
Возможно эта мышь действительно должна была идти в комплекте с беспроводной клавой, но у меня её не было, и кто мне подкинул эту мышь, тоже не помню.
Я к сожалению не так хорошо подкован в этих делах. Мне нравится покопаться, но тут тот случай, когда просто хочется гет шыт дан, а уж потом как-нибудь можно будет достичь совершенства. К счастью у меня сейчас есть другая клавиатура, которая нормально работает. Но кстати, в ней тоже не без фокусов: у нее есть медиа-кнопки и крутилочка для громкости. И вот она тоже видимо работает как что-то совсем отвлеченное, потому что я никакого эффекта в tiny-штуковинах от нее не замечаю.
Я к сожалению не так хорошо подкован в этих делах. Мне нравится покопаться, но тут тот случай, когда просто хочется гет шыт дан, а уж потом как-нибудь можно будет достичь совершенства. К счастью у меня сейчас есть другая клавиатура, которая нормально работает. Но кстати, в ней тоже не без фокусов: у нее есть медиа-кнопки и крутилочка для громкости. И вот она тоже видимо работает как что-то совсем отвлеченное, потому что я никакого эффекта в tiny-штуковинах от нее не замечаю.
Лет 10-15 назад, был период активного использования hid-девайсов, которые делались для разных нужд. К USB подключалось много чего из самоделок. Правда по HID, соответственно для всего ещё и дескрипторы корректировались и проги для РС писались специальные...
Конечно за это время уже почти всё забыл.
Но могу с уверенностью сказать, что клава с медиа-кнопками, это составное устройство. У клавы свой дескрипторы, у медиа кнопок - свои. И таких в одном устройстве может быть много.
При этом каждый дескриптор такого составного устройства указывает на свою "конечную точку" ЕР, со своими характеристиками.
Комп конечно корректно их распознаёт и настраивает, а вот такие "проекты" только частично.
К примеру, простая мышь, имеет только один дескриптор, настроен на ЕР под номером 01. А моя беспроводная имеет два устройства, и они настроены соответственно на ЕР 02 и 04. Только после ручной корректировки запроса данных (изменения номера ЕР) я начал получать пакеты данных.
Если для tinyusb есть "примеры" с выводом данных дескрипторов, то изучение клавы/мыши нужно начинать с их анализа. Будет видно и номер используемых ЕР (конечных точек), какое устройство к ним привязано, длина пакета данных и т.д. и т.п. ...
Например в исходнике который я использовал за основу, номер ЕР для работы с мышью берётся не из распарсенного дескриптора, а для функции чтения тупо указан параметр "1".
HardWareMan
07.08.2024, 20:38
Не удивлён.
Дескрипторы слишком запутанная штука, что-бы "Tiny" версии драйверов, могли их корректно распарсить. У комповых драйверов на много больше возможностей и ресурсов.
Думаю если внимательно изучить различия в дескрипторах, то можно настроить.
У меня вот беспроводная мышь определяется как "составное устройство - клавиатура".
Возможно эта мышь действительно должна была идти в комплекте с беспроводной клавой, но у меня её не было, и кто мне подкинул эту мышь, тоже не помню.
Часто клавиатурной частью мыши выступают её дополнительные кнопки. Т.е. кнопки помимо стандартных 3х.
Часто клавиатурной частью мыши выступают её дополнительные кнопки. Т.е. кнопки помимо стандартных 3х.
Если бы на моей мыши были дополнительные кнопки, то вопросов бы не возникло совсем, но она обычная 3-ёх кнопочная.
Больше склоняюсь к варианту, что изначально это была пара клава и мышь на один приёмник.
На то оно и "составное устройство", что в нём совмещены элементы разных устройств.
Я когда-то сам такое делал на процессоре "lpc21**", создал на его основе составное HID-устройство "клава-мышь-мультимедиа", подключил к нему ИК-приёмник, отсканировал бесхозный ИК-пульт. Получился самодельный пульт ДУ для ТВ-тюнера, с возможностью гонять курсор мыши по экрану, открывать/закрывать приложения ( не вставая с дивана ). Беспроводной мыши у меня тогда ещё не было.
А вообще возможно ли получить координату курсора мыши в пределах активного окна, при этом не отображая сам курсор?
Это вопрос к возможной реализации мыши на эмуляторах.
Отображать в окне "Вектора" курсор мыши РС - нет ни какого смысла. Значит его нужно отключить или "не отображать". Но если курсор мыши "отключен" или "спрятан", то есть ли возможность узнать его текущие координаты?
Если нет, то и пытаться эмулировать "мышь" видимо нет смысла.
Будет ведь не интересно видеть на окне два курсора, один РС-шный, второй - "Вектора".
И я уже писал, что эмулировать Мышь на разъёме "ПУ" не вижу смысла. Хоть к нему (в реале) и проще подключить "контроллер мыши", но он и так перегружен всевозможным (обвесом) "железом". И не думаю, что эмулятору будет просто совместить обработку данных РС-мыши и ПУ-разъём. Если только в эмуляторе не сделать дополнительную "галку" - "Эмуляция мыши на "ПУ", при активации которой всё остальное, подключенное к "ПУ" будет просто игнорироваться.
Но это всё просто мои личные домыслы, так как о (внутренней кухне) эмуляции Вектора на РС, я вообще не имею ни какого представления.
Если эмулятор будет эмулировать Векторовскую мышь, он сможет "захватить" мышь и погасить общегражданский курсор, это не должно быть большой проблемой.
Добавил в контроллер USB-мыши регистры, предоставляющие информацию о смещении мыши, а не её координаты.
Сделал универсальный тест контроллера мыши.
Исходники во вложении к первому сообщению темы.
На фотках: контроллер отключен, подключен к порту "ПУ", и "ВУ".
Тесты наводят на мысли, что математику в контроллере нужно переводить на работу с положительными числами, как это сделано в PS/2-мышах. Там смещения всегда положительные числа, а направление указано специальными флагами.
Работать с переменными типа int удобнее (всегда используется сложение, не нужно заранее контролировать направление), и сама USB-мышь выдаёт значения именно типа int. Но при замедлении мыши делением скорости на 8, возникают трудности с отрицательными значениями, так как простое смещение значения на 3 бита вправо (деление на 8), "округляет" полученное значение до "-1" (FFh) даже если смещение изначально было например только "-3", хотя желательно при этом получить "0".
А при округлении положительных смещений, все значения смещения от 1 до 7, в результате округляются до "0" ( как и ожидается ).
Вот и размышляю, как поступить, дрейф значений не значительный, и особо для пользователя не заметен.
На универсальном тесте этот дрейф значений заметен по выводимым на экран значениям координат курсора мыши.
В верхней строке, 2е и 3е значение - это содержимое регистров контроллера, в них проблем от округлений значений нет из-за особенностей вычислений координат (вычисления ведутся постоянно, без корректировки значений).
В нижней строке, 2е и 3е значение - это координаты курсора, вычисляемые на основе значений регистров смещения.
В любом случае, корректировка работы с отрицательными числами в контроллере, ни как не влияет на работу с самим контроллером со стороны пользователя. Просто в результате, пользователь сможет получать более корректные значения.
Кстати, мысля сейчас посетила, вариант стандарта значений смещения как в PS/2-мышах, можно так-же в контроллер засунуть, на отдельные регистры.
Пока прикручивал к контроллеру регистры 6 и 7, обнаружил косячокс...
Изначально решил, что контроллер будет предоставлять данные исходя из того, что "начало координат" находится в нижнем-левом углу экрана Вектора.
Но при вычислениях 5-го регистра временно не стал его инвертировать в контроллере, а сделал это в программе Вектора.
И конечно благополучно об этом забыл. Начал добавлять новые регистры смещения, и увидел, что с вычислениями что-то не так.
Короче внёс инверсию значения смещения по "Y" в контроллер, из программы для Вектора можно эту инверсию убирать.
Перезалью исходники в первом сообщении, когда допилю регистры 6 и 7.
Чем больше вожусь с "контроллером мыши", тем больше мне не нравится привязка одного регистра к другому.
К примеру у 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
16.08.2024, 10:57
Как решить проблему корректировки скорости при переходе на режим экрана 512, я пока не знаю, точнее сказать не принял однозначного решения.
Варианта два:Можно и третий вариант: просто забить на 512 и в этом режиме указатель мыши перемещать просто по чётным (или нечётным) пикселям, и тогда скорость движения не изменится. Не думаю, что кому-то когда-нибудь понадобится "двойная" точность, но если вдруг, то есть регистр "0" на этот случай и программист, который скорректирует скорость перемещения в своей программе. :)
Режим "смещений" на мой взгляд лучше бы просто доносил до вектора то, что дает мышь, а все коррекции, если они понадобятся, сделает программист.
Режим "смещений" на мой взгляд лучше бы просто доносил до вектора то, что дает мышь, а все коррекции, если они понадобятся, сделает программист.
Вариант предоставления Вектору сырых данных перемещения мыши, подходит для PS/2-мышей.
К огромному сожалению, usb-мышь гонит данные постоянно пока с ней есть какие-то манипуляции. А если Вектор будет получать сырые данные один раз в 20мс, то ни о каком контроле за перемещениями речи идти не будет, так как практически все данные будут теряться.
Именно по этому контроллер и готовит данные для Вектора. Собирает все данные о перемещениях, и предоставляет Вектору, по запросу, уже итоговую сумму всех перемещений за промежуток между запросами Вектора.
Решил, что ни как не буду корректировать скорость по "X" для режима 512.
Поскольку реальный контроллер вряд-ли кто-то ещё будет собирать, а если вдруг "контроллер мыши" появится в эмуляторе, то там этот вопрос вообще не актуален, так как смещение по осям будут браться из перемещения по экрану курсора РС, соответственно и коррекция скорости не нужна.
А для тех кто решит делать реальный контроллер, я дал подсказки, из своих экспериментов, что для комфортного перемещения курсора по экрану Вектора, данные мыши нужно делить на 8. Суммирует реальные полученные от мыши данные, а по запросу, предоставляет данные делённые на 8. Так не теряются мелкие движения мыши. Если делить на 8 сразу, и потом прибавлять к счётчику, то для смещения курсора на 1 пиксель, нужно довольно значительно дёргать мышью.
Это результаты моих экспериментов, они очень субъективны.
Именно по этому контроллер и готовит данные для Вектора. Собирает все данные о перемещениях, и предоставляет Вектору, по запросу, уже итоговую сумму всех перемещений за промежуток между запросами Вектора.
Контроллер может и приращения сам накапливать и отдавать вектору по мере опроса, просто он может делать это в формате, который получает от мыши.
Контроллер может и приращения сам накапливать и отдавать вектору по мере опроса, просто он может делать это в формате, который получает от мыши.
Регистры 4 и 5 именно в таком формате и содержат данные.
Для USB-мыши, стандарт - это целое со знаком, от -128 до +127.
На тестах я пытался перемещать (дёргать) мышь с максимально возможной скоростью, получил пиковые скорости перемещения в пределах 80-90 пикселей за 20мс. Это уже адаптированная для Вектора скорость.
Хорошо, насчет "делать это в формате, который получает от мыши" я погорячился, реализовать это 1 в 1 не очень хорошо. Основная проблема, которую хотелось бы преодолеть - потеря точности. Движение курсора - частная задача, и подгонять мышь к разрешению вектора - так себе вариант для мыши 2024 года. Лучше бы оставить полную точность добавив регистр или даже два с младшими частями смещений, которые, как понимаю, сейчас отбрасываются.
- - - Добавлено - - -
Хотя бы в варианте для ВУ.
Хорошо, насчет "делать это в формате, который получает от мыши" я погорячился, реализовать это 1 в 1 не очень хорошо. Основная проблема, которую хотелось бы преодолеть - потеря точности. Движение курсора - частная задача, и подгонять мышь к разрешению вектора - так себе вариант для мыши 2024 года. Лучше бы оставить полную точность добавив регистр или даже два с младшими частями смещений, которые, как понимаю, сейчас отбрасываются.
- - - Добавлено - - -
Хотя бы в варианте для ВУ.
У usb-мыши, данные перемещения так-же имеют разрядность байт. Просто за 20мс в счётчике может накопиться 10бит-ное значение, скорее всего, примерно до 800 пикселей.
Сейчас в контроллере сеть счётчик (на ось) разрядностью 16бит. при запросе Вектора, три младших бита отбрасываются, остальное обрезается по разрядности байта.
Потом (после передачи данных в порт) переданные данные умножаются на 8 и вычитаются из счётчика.
Я вроде где-то писал причину, по которой начал делить скорость на 8.
Когда использовал родные данные, для перемещения курсора на экране Вектора, то курсор пробегал от края до края экрана за 1см перемещения мыши по коврику.
Ни о какой точности позиционирования курсора не может быть речи, курсор слишком чувствителен.
Просто за 20мс в счётчике может накопиться 10бит-ное значение
В последнем посте я как раз об этом.
Слишком активно агитирую. Чтобы потом не было претензий должен написать отказ от ответственности - не гарантирую, что сам буду активно использовать такую возможность, если она будет в эмуляторе. Если текущий вариант несколько "винтажный", это не принципиальная проблема, для курсора подходит, это главное.
В последнем посте я как раз об этом.
Слишком активно агитирую. Чтобы потом не было претензий должен написать отказ от ответственности - не гарантирую, что сам буду активно использовать такую возможность, если она будет в эмуляторе. Если текущий вариант несколько "винтажный", это не принципиальная проблема, для курсора подходит, это главное.
Возможно это я не совсем понял. Но ещё раз выскажу своё предположение, что все эти свистопляски с коррекцией и делением скорости, это проблемы только реального контроллера. При эмуляции, перемещения курсора будут в пределах экрана "Вектора", а значит (после пересчёта к соответствию масштаба) о значениях типа 800 пикселей за 20мс в одном направлении речи быть не должно. Мне так кажется.
Решил погуглить по поводу чувствительности сенсора мыши.
Ни когда не задумывался, оказывается есть такой параметр DPI, и он от 400 до 5000 dpi (пикселей на дюйм), если верить хухлу.
И моя мышь имеет 1200dpi, собственно около 480 пикселей на 1см.
Значит с реальным "контроллером мыши", с разными мышами, скорости перемещения могут отличаться.
Обновил вложение в первом сообщении.
Заменил исходники на актуальную версию теста контроллера с 9-ю регистрами.
Где-то я аркрноида адаптировал под PS/2-мыщь, найду, переделаю под порт D4h.
Не понимаю, зачем и 4-5 и 6-7. При желании можно преобразовывать в векторе или "процедурно" или таблицей, если нужно побыстрее. Вместо этого точно полезнее добавить младшие части смещений.
Не понимаю, зачем и 4-5 и 6-7. При желании можно преобразовывать в векторе или "процедурно" или таблицей, если нужно побыстрее. Вместо этого точно полезнее добавить младшие части смещений.
Ну "понесло" меня на разнообразие представления одних и тех-же данных...
Думал ещё выделить регистры для эмуляции формата джойскиков. Типа при смещении мыши со скоростью больше некоего значения (для защиты от дребезга) - выставлять в регистрах соответствующие джойстикам биты направлений и кнопок.
Но пока продолжаю считать, что джойстик из мыши - совсем не юзабельная фигня.
Свободные регистры есть, могу и эти (отрезанные от смещения) 3 бита воткнуть в отдельные регистры.
Только что туда будут передавать в эмуляторах (если эмуляция контроллера появится) ?
При эмуляции ведь этих "отрезанных бит" не будет.
На самом деле, разнообразные варианты представления манипуляций с мышью, вталкиваю к контроллер, для предоставления возможности как можно проще адаптировать уже имеющиеся программы, под применение мыши.
Поскольку при адаптации готовых (старых) программ, каждый байт "на вес золота", то прочитать данные из порта, которые подойдут для интеграции в данную программу, значительно удобнее, чем ещё и преобразовывать их, после получения, пытаясь подогнать под условия задачи.
Будешь дразнить, я в этот контроллер ещё и USB-клавиатуру воткну... хотя пока не собирался ;)
Во вложении первого сообщения добавил адаптированный под контроллер вариант "arkanoid".
- - - Добавлено - - -
Я тут где-то пургу нёс про представление смещения в PS/2-мышах...
Откудава я взял, что там только положительные значения, а флаг направления отдельно - я не имею представления :(
В PS/2-мышах, смещение также как в usb-мышах, 8бит целое со знаком (-128 ... +127), и ещё (не понятно для чего) отдельно флаг "отрицательного значения".
К адаптации старых программ под мышь отношусь умеренно скептически. Что имеет смысл адаптировать - (нормальные) графические редакторы (наверно Draw и хватит) и подходящие игры, типа Minesweeper, Ветка, карточные и игры на доске (шахматы, шашки, реверси и т.п.).
Свободные регистры есть, могу и эти (отрезанные от смещения) 3 бита воткнуть в отдельные регистры.
Только что туда будут передавать в эмуляторах (если эмуляция контроллера появится) ?
При эмуляции ведь этих "отрезанных бит" не будет.
Если правильно сделать эмуляцию, то там будет примерно то же самое, что и в железном контроллере.
Я сейчас глянул на тему чуть более внимательно, чем раньше, потому что у меня заработала USB-клавиатура и я потихоньку морально готовлюсь к тому, чтобы может быть подключить и мышь. Но пока по-моему сыровато. Интересно ставить эксперименты, они должны что-то показать, но в конце труха должна отпасть и должен остаться один ясный и понятный способ. Проблему адаптации старых программ я понимаю, но разделяю здоровый скепсис ivagor-a, поэтому не хочется делать калеку ради того, чтобы адаптировать две-три старые программы.
Предлагаю смещения передавать в таком виде:
* X смещение со знаком / 8
* X смещение со знаком % 8
* Y смещение со знаком / 8
* Y смещение со знаком % 8
Это даст перемещения с удобной для Вектора скоростью и точность для тех случаев, где она может быть понадобится.
Про абсолютные координаты я уже не раз высказывался, но вижу, что эта идея не умрет просто так от моего напряженного взора. В конце концов мне не жалко.
Объясни, почему в эмуляции должны возникнуть какие-то проблемы с младшими битами?
...
Объясни, почему в эмуляции должны возникнуть какие-то проблемы с младшими битами?
Если этот вопрос ко мне, то разве я говорил, что при эмуляции могут возникнуть какие-то проблемы с младшими битами скорости перемещения мыши?
Я говорил о том, что для эмуляторов Вектора они не пригодятся, а с реальным контроллером, при их использовании курсор мыши становится слишком чувствительным к перемещениям самой мыши, и носится по экрану как угорелый, не возможно точно позиционировать. Вот и пришлось "замедлять" до "комфортной" скорости, отбрасывая 3 младших бита скорости.
Эти 3 младшие бита "скорости" - это 3 младших бита чувствительности сенсора мыши.
Обычная мышь имеет чувствительность 1200 пикселей на 2.5см (дюйм) смещения.
Обычный экран РС (при разрешении 1280х1024) курсор мыши пробегает за 2.5 см смещения мыши по коврику, это если в настройках не снижена чувствительность мыши. Обычно мышь нужно сместить примерно на 5 см.
У реального Вектора экран 256х256, при обычной чувствительности сенсора, курсор будет пробегать от края до края за 0.53см смещения мыши по коврику.
Вопрос: Это очень удобно?
Я в реальном контроллере, отбросил 3 младшие бита "скорости", т.е. чувствительности сенсора, и получил чувствительность 150 пикселей на 2.5см смещения мыши по коврику.
Т.е. экран Вектора 256 пикселей курсор будет проходить за чуть меньше 5см смещения мыши (300 пикселей за 2 дюйма смещения).
Эта скорость очень сильно отличается от скорости смещения мыши по экрану РС ?
Нет, я конечно понимаю, что сейчас только я пользуюсь старым монитором с разрешением 1280х1024, а почти у всех остальных мониторы с разрешением 3840 x 2160 и всем пользователям эмулятора Вектора понадобится точно позиционировать каждую 1/64 площади каждого пикселя на экране Вектора, для этого им нужны будут эти 3 отброшенные бита скорости.
И я повторюсь, мне не жалко.
Если этот вопрос ко мне, то разве я говорил, что при эмуляции могут возникнуть какие-то проблемы с младшими битами скорости перемещения мыши?
Я неточно выразился. Но ты сказал, что:
Только что туда будут передавать в эмуляторах (если эмуляция контроллера появится) ?
При эмуляции ведь этих "отрезанных бит" не будет.
Исправляю вопрос -- почему не будет отрезанных бит при эмуляции? Потому что координаты курсора в сообщениях винды привязаны к пикселям? Тут тоже есть много деталей. Как ты точно подметил, сейчас мало кто может позволить себе запустить эмулятор с увеличением 1х на современных мониторах, так что 1/4 пикселя будет не редкость. Кроме того, перемещения курсора можно получать через WM_INPUT и они будут в нативном разрешении мыши, ну или по крайней мере в каком-то минимально пережеванном. Это может быть нужно не для супбиксельного позиционирования курсора, а для плавного движения какого-нибудь предмета в игре, например.
Improver
19.08.2024, 13:14
Это может быть нужно не для супбиксельного позиционирования курсора, а для плавного движения какого-нибудь предмета в игре, например.Мне кажется, что для плавного движения лучше сделать регулируемую скорость перемещения мыши, т.е. просто нужен некий внутренний регистр в контроллере, куда можно занести коэффициент деления, чтобы можно было программно (или аппаратно, переключателем) настроить комфортную скорость. И тогда "X смещение со знаком % 8" и "Y смещение со знаком % 8" могут пригодиться ровно никогда и их можно будет просто отбросить.
А вот как это всё встроить в эмулятор... Ну, например, в винде есть параметр "скорость курсора мыши", можно попробовать его изменять в моменты, когда курсор находится над окном эмулятора. Как вариант, делать полный захват курсора окном эмулятора, как это делается в некоторых программах удалённого доступа.
...
Исправляю вопрос -- почему не будет отрезанных бит при эмуляции?
Потому что смысла нет.
... Кроме того, перемещения курсора можно получать через WM_INPUT и они будут в нативном разрешении мыши, ну или по крайней мере в каком-то минимально пережеванном. Это может быть нужно не для супбиксельного позиционирования курсора, а для плавного движения какого-нибудь предмета в игре, например.
Спасибо. Рассмешил, развеселил, сделал день.... :)
Я себе так живо представил картинку....
Сидит "Курсор" почти по центру экрана Вектора, в координатах 127,127.
А тут "Программа" получает от "Контроллера" сообщение, что "Мышь" сместилась на (11-битное число со знаком) 1023 пикселя в сторону, и нужно туда "Курсор" отправить... срочно!!!
Кто знает, что ответит "Программа" "Контроллеру", в ответ на приказ отправить "Курсор" на такое расстояние?
- - - Добавлено - - -
...
А вот как это всё встроить в эмулятор... Ну, например, в винде есть параметр "скорость курсора мыши", можно попробовать его изменять в моменты, когда курсор находится над окном эмулятора. Как вариант, делать полный захват курсора окном эмулятора, как это делается в некоторых программах удалённого доступа.
Не нужны эмулятору ни какие скорости.
Конечно, я уже писал, что я вообще не разбираюсь в эмуляции.
Но с моей ламерской точки зрения, решение вопроса, это несколько переменных и минимум вычислений.
1. Позиция "курсора" РС всегда привязана к пикселям на экране Вектора, шаг/пиксельклок/коэффициент - как хотите это назовите.
2. При запросе данных из регистра смещения, эмулятор фиксирует текущую координату "курсора" (по запрошенной оси) и вычисляет разницу с координатой, которая была зафиксирована во время предыдущего запроса. Разница и есть смещение "курсора" по оси за промежуток времени между запросами.
Фиксация координаты и вычисления делаются отдельно для регистров смещения по X и Y.
3. После предоставления значения смещения, текущие координата сохраняется как "предыдущая" и ждём следующего запроса из этого регистра.
Это правда справедливо для перемещения мыши в пределах экрана эмуляции. Как адаптировать "смещение" мыши ЗА пределами экрана эмуляции - нужно думать.
И "скорость" смещения в эмуляторе ВСЕГДА будет зависеть от настроек чувствительности мыши в операционке РС. Хочешь 50 dpi выстави, хочешь 5000 dpi.
Я ведь много раз говорил, что корректировка скорости мыши в контроллере, это проблема исключительно РЕАЛЬНОГО контроллера мыши.
И это первая и главная задача любого реального контроллера, подготовить внешние данные для принимающей стороны, чтобы она (принимающая сторона) этими данными не подавилась...
Нафига РЕАЛЬНОМУ Вектору скорости смещения мыши в 1023 пикселя, если РЕАЛЬНЫЙ экран Вектора всего 256 пикселей...
Improver
19.08.2024, 15:18
несколько переменных и минимум вычисленийЕсли минимум вычислений на Векторе, то да, согласен полностью. Но контроллер и эмуляторы могут вычислять сколько угодно...
Как адаптировать "смещение" мыши ЗА пределами экрана эмуляции - нужно думать.А что там думать? Мышь за пределами экрана эмулятора -- координаты не меняются, завели указатель в экран -- начали обновлять...
И "скорость" смещения в эмуляторе ВСЕГДА будет зависеть от настроек чувствительности мыши в операционке РС.Увы, но не всегда. Как пример могу привести "VMware Remote Console", там при захвате мышки удалённой машиной в пределах окна скорость перемещения зависит не от настроек хоста, а от настроек удалённой виртуальной машины. Значит такой фокус вполне возможен и в эмуляторе Вектора, если вдруг понадобится.
Я ведь много раз говорил, что корректировка скорости мыши в контроллере, это проблема исключительно РЕАЛЬНОГО контроллера мыши.И с этим тоже согласен. Но мне кажется, иметь в контроллере такую настройку не помешает, чтобы можно было выставлять комфортную для себя скорость, для любой мышки.
Нафига РЕАЛЬНОМУ Вектору скорости смещения мыши в 1023 пикселя, если РЕАЛЬНЫЙ экран Вектора всего 256 пикселей.Я тоже не понимаю, зачем это, но у других, видимо, есть идеи, где это можно использовать...
...
А что там думать? Мышь за пределами экрана эмулятора -- координаты не меняются, завели указатель в экран -- начали обновлять...
...
Я вот думаю, что при выходе курсора РС за экран эмулятора (в режиме окна), регистры координат меняться не будут, они ведь имеют ограничения значений, координаты будут указывать на кромку/край окна.
А вот в регистры смещения можно записывать некое значение, указывающую направление, в котором находится курсор. чем дальше от края окна, тем больше значение "смещения".
Для полноэкранного режима эмулятора этот вариант конечно не подходит, но наверное тоже как-то решаемо.
Потому что смысла нет.
Как ты определяшь смысл до того, как написан софт? Какие критерии?
Вот это твои слова, может быть устаревшие, потому что они из самого первого сообщения и может быть с тех пор что-то изменилось, но я отталкивался от них:
Пришлось уменьшить скорость в 8 раз.
Вроде бы не такое огромное число раз. Это всего три бита, которые не нужны ровно до тех пор, пока они не понадобятся. Сейчас тебе субъективно показалось, что с твоей мышью и для той игры, которую ты адаптируешь, это хороший делитель. Но будут другие мыши и другие игры и там это может быть не так.
Мне показалось, или ты не настроен на конструктивную беседу? Я всегда рад развеселить коллегу, но это не моя основная цель. Если ты твердо принял решение делать по своему, то я не хочу мешать.
Как ты определяшь смысл до того, как написан софт? Какие критерии?
...
Я за конструктивный диалог.
Прошу пояснить мне, какой смысл для Вектора, в перемещениях на 1023 пикселя, если сам экран 256 пикселей?
Если только прикоснулся к мыши, а курсор уже пролетел все "элементы управления", и упёрся в край экрана.
Improver
19.08.2024, 16:51
координаты будут указывать на кромку/край окна.Обычно так и бывает. И да, координаты мыши в эмуляторе при этом меняться не будут.
А вот в регистры смещения можно записывать некое значение, указывающую направлениеНет, туда писать просто нули -- смещения нет, где бы мышка ни находилась за пределами окна. В том числе и не писать биты нажатия кнопок, иначе можно получить много неприятных эффектов, например, если пользователь захотел переместить мышкой окно эмулятора на экране... Указатель снова вернулся в окно -- писать в регистры смещения значение разности координат с его новой позицией в окне.
Прошу пояснить мне, какой смысл в перемещениях на 1023 пикселя, если сам экран 256 пикселей?
Если только прикоснулся к мыши, а курсор уже пролетел все "элементы управления", и упёрся в край экрана.
Смысл такой же, как в 16 битах звука. Младшие 8 мы не особо то слышим, но если оставить только старшие 8, становится понятно, как плохо без младших 8. Зачем ты повторяешь, что при малейшем касании мышка должна улететь на 1023 пикселя? Я точно так же могу продолжить твой аргумент и привести его к абсурду. Потому что если 10-битная мышка улетает на 1023 пикселя, значит 7-битная улетает сразу на 127 пикселей, я правильно поделил? И чем одно другого лучше?
Мое предолжение просто в том, чтобы оставить возможность программе эти младшие три бита получить, если они ей понадобятся. Может быть кто-то захочет сделать продвинутую акселерацию курсора. А может быть мышка будет управлять не курсором вообще, это просто устройство ввода с относительным перемещением. Мы пока не знаем, что программы будут делать с данными, они еще не написаны. Если такое простое желание стоит стольких сломанных копий и высмеивания, ну что ж. Я понимаю, ты все решения уже принял. Обсуждать больше нечего.
...
Зачем ты повторяешь, что при малейшем касании мышка должна улететь на 1023 пикселя? Я точно так же могу продолжить твой аргумент и привести его к абсурду. Потому что если 10-битная мышка улетает на 1023 пикселя, значит 7-битная улетает сразу на 127 пикселей, я правильно поделил? И чем одно другого лучше?
...
Я уже писал, что первоначально проводил такой эксперимент с полными данными мыши.
Чуть больше 5мм смещения мыши и курсор уже от края экрана до края экрана пробежал. Практически не мог его нормально позиционировать.
Я уже писал, мне не жалко регистров, можно и эти младшие биты в контроллер добавить.
Уже писал, что режу эти три бита не сразу на входе, а использую их (полные данные от мыши) для 16-битного счётчика смещения. Это позволяет не терять мелкую моторику и плавное перемещение курсора. А вот для комфортного перемещения курсора по экрану Вектора, 150 dpi оказалось в самый раз.
И пока так и не могу себе представить практического применения манипуляций мыши, когда пользователь не может попасть ни в один элемент управления.
Я предложил "заготовку" контроллера, адаптировал под неё игру, желающие могут повторить и попробовать.
Вообще не буду против, даже буду ЗА, если кто-то в предложенный "контроллера мыши" добавит что-то ещё, и предложит протестировать в своей программе.
Бузу только рад, с удовольствием попытаюсь повторить доработку и испытать.
Improver
19.08.2024, 18:15
Может быть кто-то захочет сделатьА может не захочет... Тут вопрос в чём: KTSerg сделал аппаратный контроллер, и он работает, протестирован в реале и даже имеет примеры использования на Векторе и тестовые программы. Что ещё надо? Хотите дополнительные возможности -- напишите программу, где они действительно требуются, и тогда можно будет дорабатывать под них этот контроллер, в чём проблема-то? Выдвигать хотелки без подкрепления практическим применением -- так себе занятие...
А так, KTSerg молодец, взял и сделал то, о чём тут впустую говорили не один год. :v2_thumb:
Вот никто не сказал, что KTSerg -- не молодец. Очень даже молодец. Речь вообще не о нем, а о том, чтобы в спецификации записать еще два регистра. Пусть сегодня там будут нули, или единицы. Просто можно написать, что вот эти два регистра зарезервированы на будущее для высокоточной мышки. Сейчас есть единственный рабочий прототип. Постепенно эмуляторы и железки начнут обрастать реализациями. У всех будут какие-то отклонения, кто во что горазд, кому как удобней. Если сейчас чего-то четко не записать, дальше все будет все более и более расплывчато. А потом окажется, что у кого-то на этом порту realtime clock, или еще какие-нибудь вещи и будет как всегда.
Improver
20.08.2024, 16:41
Просто можно написать, что вот эти два регистра зарезервированы на будущее для высокоточной мышки.Зарезервировать два регистра легко (без поправки "для высокоточной мышки"), но делать что-то ещё, придумывать стандарты -- сейчас не вижу смысла, честно. Давайте хотя бы просто внедрим мышку в том виде, в каком она уже есть, начнём её применять, писать новые и модифицировать старые программы под неё, а потом, на практике, станет понятно, что надо там добавлять, а что нет.
А потом окажется, что у кого-то на этом порту realtime clock, или еще какие-нибудь вещи и будет как всегда.Когда-то да, было так, но сейчас, если реально смотреть на вещи, разработчиков железа на Вектор можно пересчитать на пальцах одной руки в единичной системе счисления и практически все читают этот форум. Неужто они как-то не договорятся, когда появится реальная необходимость в этой "высокоточной мышке"? И разработчики эмуляторов потом подтянутся...
(без поправки "для высокоточной мышки")
Нет, я понял, мне тут делать больше нечего.
Improver
20.08.2024, 18:15
Нет, я понял, мне тут делать больше нечего.Ну что за детские обиды... Просто напишите программу, хотя бы простую тестовую, где будет явно заметно преимущество "высокоточной мышки" на Векторе, и все Ваши идеи будут приняты, а теоретических рассуждений у нас тут и так предостаточно.
Добавил в контроллер ещё 3 регистра, с "сырыми данными".
Регистр 8 - клавиши, 9 и 10 - смещения.
Смещение по Y даже инвертировать направление не стал ни в контроллере ни в тесте, что-бы было понятно, что это "родные данные" мыши.
Регистры смещения в контроллере только блокируются на максимальных значениях [-127..+127] при переполнении.
В каталоге нашел исходник игры "MINSWEEPER", адаптировал её для тестирования мыши. Поддерживаются оба подключения контроллера. Закинул во вложение первого сообщения.
Когда-то делал "сервер", для передачи данных в эмулятор "emu" через сокеты, для эмуляции загрузки данных по протоколу ЛВС.
Сейчас, для тестирования программы с поддержкой "контроллера мыши" переделал тот сервер для передачи в эмулятор данных мыши.
Информация через сокеты передаётся очень медленно, соответственно о полностью корректной работе с виртуальным контроллером, говорить не приходится.
Но у меня заработало.
Допускаю возможность, что работа "контроллера мыши" через сокеты будет зависеть от конкретного компьютера.
Сервер сделан примитивно, и годится только для данной конкретной демонстрации, тестировался только с программой mines_s.
Глюк возможен в порядке чтения данных от контроллера.
В верхнем левом углу есть маркер данных.
Далее в верх должны быть данные от кнопок, X, Y.
Бывает, что порядок чтения нарушен, из-за задержек в передаче данных через сокеты, тогда программа будет путать команды управления курсором.
Если такое будет происходить, сообщите.
Запускаем сервер, потом эмулятор с игрой, располагаем окна рядом, водим мышью по окну сервера, и курсор в игре должен перемещаться соответственно.
Во вложении архив "MOUS_USB_MIN_S.ZIP" в нём:
сервер "virt_mous_vu.exe"
игра "mines_s.rom"
конфиг для эмулятора emu "Vector06c_vm.cfg"
и краткая инструкция "mines_s.txt"
Когда я запускаю emu, virt_mous_vu пишет "connected: 5 26321". Но когда загружаю rom, появляется "disconnected: 5". emu для уверенности скачал только что самый свежий (сборка 13.04.23 20:30).
Когда я запускаю emu, virt_mous_vu пишет "connected: 5 26321". Но когда загружаю rom, появляется "disconnected: 5". emu для уверенности скачал только что самый свежий (сборка 13.04.23 20:30).
Действительно.
Просто я так ни разу не пробовал, так как запускаю rom-ы через меню FARа, командной строкой:
C:\emu\emu /c "Vector06c_vm" !.!
Если при запуске игры, всё-же происходит смещение при чтении данных от сервера, то во вложении три варианта сборки игры, с установкой разной компенсации смещения.
Возможно один из вариантов будет читать данные мыши правильно, остальные будут глючить.
C:\emu\emu /c "Vector06c_vm" !.!
Так работает. С первого раза похоже вышло как раз как ты говоришь, съехало начало пакета. Перезапустил эмулятор с игрой, стало работать нормально.
Вроде ощущения вполне нормальные мышиные прикольно. Я не ощутил на себе медленности сокетов.
Так работает. С первого раза похоже вышло как раз как ты говоришь, съехало начало пакета. Перезапустил эмулятор с игрой, стало работать нормально.
Вроде ощущения вполне нормальные мышиные прикольно. Я не ощутил на себе медленности сокетов.
Эта игра адаптирована на использование регистров (1, 2) контроллера мыши, которые передают текущие координаты "курсора".
Медленность сокетов заключается в том, что ответа на запрос (чтение) "порта" программа будет ждать долго, соответственно чтение портов, получает данные, которые программа запрашивала одно прерывание назад, т.е. 20мс тому назад.
Так как каждое прерывание запрашиваются одинаковые пакеты, то для программы не важно, что приходят они только к следующему запросу.
Короче, программа запрашивает данные, и читает порт, но прочитанные сейчас данные просто стояли в очередь на чтение, и являются данными, которые программа запрашивала в прошлом прерывании.
Аналогичная сборка игры с сервером, для тестирования мыши с эмулятором emu, для ARKANOIDа.
Для этой игры, используются смещения мыши только по горизонтали, соответственно сервер растягивать по всей ширине экрана, так как перемещения мыши фиксируются им только пока курсор в пределах окна сервера.
Во вложении архив "MOUS_USB_ARK_S.ZIP" в нём:
сервер "virt_mous_a.exe", модификация для тестирования с arkanod4.rom
игра ARKANOID - "arkanod4.rom"
конфиг для эмулятора emu "Vector06c_vm.cfg"
и краткая инструкция "virt_mous_a.txt"
Аналогичная сборка игры с сервером, для тестирования мыши с эмулятором emu, для "Collines".
Для этой игры, используются регистры контроллера 0, 6, 7 - смещения мыши, соответственно сервер растягивать по ширине и высоте, так как перемещения мыши фиксируются только пока курсор в пределах окна сервера.
Во вложении архив "MOUS_USB_COL_S.ZIP" в нём:
сервер "virt_mous_c.exe", модификация для тестирования с collind4.rom
игра COLLINES - "collind4.rom"
конфиг для эмулятора emu "Vector06c_vm.cfg"
и краткая инструкция "collind4.txt"
За качество адаптации не уверен, в программу очень много самомодификации, но вроде как работает.
При тестировании, редко были замечены срывы синхронизации потока данных от "сервера" через сокеты, причина не ясна.
Не нашел у себя usb-мышь с которой max3421 данные колеса передаёт, взял и прикрутил к "контроллеру" ещё и протокол ps/2.
У этих мышей нет проблем с колесом прокрутки. ;)
И "медленная" ps/2-мышь, жрущая ресурсы (при подключении к "ПУ"), стала очень даже юзабельной через регистры контроллера.
Пока подключал ps/2-мышь, вспомнил про аналоговые (пропорциональные) джойстики (два резистора и кнопки). В принципе, данные у них должны быть совместимы с первыми тремя регистрами "контроллера мыши", для реала, не должно быть проблем подключить такой джойстик через "контроллер мыши", был-бы софт, которому нужен такой джойстик.
был-бы софт, которому нужен такой джойстик
Аналоговый джойстик вроде бы и прикольная штука, но я почти не знаю игр, которые бы хорошо его использовали. Если это не джойстик, а крутилки, то Понг однозначно от аналоговой крутилочности выигрывает.
Кстати, мышка на коммодоре передает движение через хаку в опросе аналоговых крутилок.
Аналоговый джойстик вроде бы и прикольная штука, но я почти не знаю игр, которые бы хорошо его использовали. Если это не джойстик, а крутилки, то Понг однозначно от аналоговой крутилочности выигрывает.
На РС я видел и слышал только о всевозможных симуляторах, использующих именно аналоговые джойстики.
Сам подключал резюки вместо джойстика (в начале нулевых), гоняли в "формула-1", с пропорциональным управлением руля было прикольнее, чем кнопками рулить.
Но для Вектора Понг, или что-то подобное, скорее всего, будет пределом использования аналогового (пропорционального) управления.
Кстати, мышка на коммодоре передает движение через хаку в опросе аналоговых крутилок.
Я не в теме, даже не понял, что это означает.
Аналоговая крутилка еще подходит для арканоидов.
Аналоговая крутилка еще подходит для арканоидов.
В Арканоиде спиннер на манер мышки. Крутится как крутилка, но суть мышиная -- https://www.youtube.com/watch?v=Y1e8tsOBgY4
В любом случае, на Векторе нет программ, в которых внедрение мышки было бы простым, все в той или иной степени адаптированы к кнопкам. Но если преодолеть эти сложности, то мышка тогда не превратиться в унылый эмулятор джойстика/клавиатуры.Не правда. Есть. :)
Сам такие писал в 90-ее. Для крысы от ЕС-1840, которую я в те времена где-то надыбал и приколхозил к своему Вектору. ;)
Improver
09.09.2024, 16:30
Не правда. Есть. :)
Сам такие писал в 90-ее. Для крысы от ЕС-1840, которую я в те времена где-то надыбал и приколхозил к своему Вектору. ;)Поделитесь ими? Интересно было бы взглянуть, и схему Вашего подключения мышки к Вектору.
Поделитесь ими? Интересно было бы взглянуть, и схему Вашего подключения мышки к Вектору.Я бы с радостью, но схемы утеряны во тьме веков десятилетий.
Писал я графический редактор. С визуальным графическим интерфейсом (всякими динамическими кнопочками, как в современной винде). Который как раз и работал с моей крыской и ещё квазидиском на 256КБ. Тоже - собственной схемы. Поэтому ни то ни другое существующими эмуляторами не поддерживается, к сожалению. :frown:
Сейчас пишу собственный эмуль, в который и добавлю их поддержку. Как руки дойдут. Для этого надо будет по отрывочным воспоминаниям и коду драйверов восстановить схемы. Тогда и выложу. Сейчас - бессмысленно.
По мыши конкретно: Помню, что в оригинальной крысе EC-1840 была самая кондовая схема - без контроллера внутри (видимо он находился в самом ПК). Там 2 пары квадратурных сигналов (X + Y), идущих прямо от оптических датчиков в шнур. Естественно - к Вектору такое напрямую не приколхозить было (без доработки схемы самого ПК). Но лезть в ПК не хотелось - хотелось подключить её ко внешнему разъёму "ПУ". И чтобы мышь опрашивать можно было как клаву - в прерываниях 50Гц. Поэтому ваял свой собственный контроллер мыши. Внутри её корпуса. Ваял из того, что было под рукой. Благо - крыса была довольно большая и внутри места было много. Даже для DIP-корпусов. А были под рукой К155ИЕ7 (4-разрядные двоичные реверсивные) + К155КП2 + всякая логика/триггеры. Повесил на каждый канал (X/Y) по одному К155ИЕ7 с инкрементом или декрементом в зависимости от направления вращения. И со схемой ограничения счёта в обе стороны (чтобы не было переполнений). А данные с ИЕ7 - через К155КП2 уже читал в 4 приёма в комп.
Естественно - с такой схемой нельзя было мышу двигать очень быстро - иначе движение сходилось с диагональному. Но для граф.редактора это было приемлемо.
Квазидиск у меня был тоже был сделан по собственной доморощенной схеме. Самим и придуманной и воплощённой. На 8-ми шт. КР565РУ7 + 4-х чипах логики/триггеров. Подключался к разъёму "ВУ" (хоть стоял внутри корпуса ПК - припаян был к нему). Я его поместил в вертикальную "ножку" корпуса Вектора - там было пустое место как раз для небольшой платки. Для работы мой квазидиск использовал один из недокументированных кодов системы команд (вроде код 8, если не изменяет склероз). При обнаружении кода 8 в потоке команд (который CPU исполнял как NOP), взводился бит в триггере К155ТМ2 и, если потом за кодом 8 шла команда, обращающаяся к памяти через регистр M или одна из LDAX/STAX, то такое обращение перехватывалось и перенаправлялось в одну из страниц квазидиска. Номер нужной 64КБ-ной страницы выбирался двумя разрядами штатной КР580ВВ55, на плате Вектора. Но работали только косвенные обращения через однобайтные команды. Никакие команды с прямой адресацией (LDA/STA/LHLD/SHLD) с моим квазидиском не работали. Также не работали двухбайтные PUSH/POP.
Improver
10.09.2024, 13:20
rst, здорово, интересные разработки. А самого железа не сохранилось? Хотя бы на фотки взглянуть...
rst, здорово, интересные разработки. А самого железа не сохранилось? Хотя бы на фотки взглянуть...Какое там! Я с тех времён поменял 3 страны и ещё больше городов. Всё железо давно кануло в Лету. :( Хорошо хоть программы сохранил.
Какое там! ... Всё железо давно кануло в Лету. :( Хорошо хоть программы сохранил.
А действительно, было-бы интересно узнать, как "крыса" (или "колобок") от ЕС-1840 подключалась к Вектору, она ведь вроде к СОМ-порту подключалась.
- - - Добавлено - - -
В Арканоиде спиннер на манер мышки. Крутится как крутилка, но суть мышиная -- https://www.youtube.com/watch?v=Y1e8tsOBgY4
"Крутилка" - натуральная механика мыши, значит и данные от неё идут цифровые (скорее всего) в формате мыши, с учётом, что там только одна "ось" - 1 байт данных.
А действительно, было-бы интересно узнать, как "крыса" (или "колобок") от ЕС-1840 подключалась к Вектору, она ведь вроде к СОМ-порту подключалась.Может у меня была не именно ЕС-1840, а от какой-то другой ЕС. Но в моей никаких COM-портов не было. А были два квадратурных сигнала.
Т.е. очень просто и кондово: оптопары -> формирователи импульсов (вроде на инверторах или повторителях из K561 - не суть) -> шнур в ПК.
PS: Вот нашёл в сети - как самая первая мыша по этой ссылке: https://red-innovations.su/index/photos_c/mice.html
И такого же цвета с коричневыми кнопками. Там написано "ЕС-1842". Возможно именно от ЕС-1842 и у меня была.
Может у меня была не именно ЕС-1840, а от какой-то другой ЕС. Но в моей никаких COM-портов не было. А были два квадратурных сигнала.
Т.е. очень просто и кондово: оптопары -> формирователи импульсов (вроде на инверторах или повторителях из K561 - не суть) -> шнур в ПК.
PS: Вот нашёл в сети - как самая первая мыша по этой ссылке: https://red-innovations.su/index/photos_c/mice.html
И такого же цвета с коричневыми кнопками. Там написано "ЕС-1842". Возможно именно от ЕС-1842 и у меня была.
Судя по схеме подключения, обычный аналог джойстика, направления и кнопки.
Судя по схеме подключения, обычный аналог джойстика, направления и кнопки.Сомневаюсь. Разве существуют джойстики из которых выходят квадратурные сигналы? Зачем они им?
Сомневаюсь. Разве существуют джойстики из которых выходят квадратурные сигналы? Зачем они им?
Не знаю на счёт квадратутных сигналов, но в схеме распиновки:
1 - "Y" (вверх)
2 - "X" (вправо)
3 - "-Y" (вниз)
4 - "-X" (влево)
PS Ясно, по ссылке приведена схема подключения УВК для БК0010.
Я подключаю к FPGA, но проблема та же. Текущий план использовать для этого Pi Pico (в моем случае rp2040-zero, но разницы нет). ...
Разглядывал rp2040-zero. При подключении к FPGA по напругам вроде проблем нет, оба 3-ёх вольтовые, а вот к Вектору, без сопряжения уже сложнее подцепить.
В этом плане stm32f1 оказалась предпочтительнее, так как большинство её выводов терпят 5В на входе.
к Вектору, без сопряжения уже сложнее подцепить
Диоды внутри есть, если ток ограничить и убедиться, что питание всегда подано на пипико -- чтобы не получилось фантомного питания 5-ю вольтами -- то может быть оно и нормально.
Вот тут длинная дискуссия. Много пылких теоретиков, кого-то вынесли на вилах как обычно, но есть и практики и даже кто-то вообще утверждает что чуть ли не прямо 5В втыкает и все-то у него хорошо. Я бы не верил так прямо, конечно, не имея запасного пипико в ящике. https://forums.raspberrypi.com/viewtopic.php?t=349017
- - - Добавлено - - -
P.S. Я сейчас USB-клавиатуру подключаю через TinyUSB к Пипико, а Пипико к fpga одним проводом по UART-у. Но это конечно совсем другая ситуация.
Вместо SIDа втыкают (https://github.com/frntc/SIDKick-pico), есть пара видео с примерами работы.
Вместо SIDа втыкают (https://github.com/frntc/SIDKick-pico), есть пара видео с примерами работы.
Вот тут я особенно не уверен, потому что там на плате стоят две штуки 74CBTD3384CDGVRG4, а это левел шифтеры. Схемы я не нашел, но в BOM их видно.
Если нужно втыкать именно без левел шифтеров, тогда извините.
Принесли мне глючную мышь глянуть. В первый раз такое увидел.
На верху, по центру, есть кнопка для переключения dpi. Прямо на ходу жамкая пимпочку, можно менять dpi-скорость-чувствительность мыши 800/1200/1600/2400.
С такой мышой и настройки скорости в контроллере не нужны. Можно на ходу переключить на "удобный" dpi.
В первый раз такое увидел.
На верху, по центру, есть кнопка для переключения dpi. Прямо на ходу жамкая пимпочку, можно менять dpi-скорость-чувствительность мыши 800/1200/1600/2400.Вы где спали последние 20 лет? ;) Сейчас подобные кнопы у половины мышей есть. А если считать только приличные - у всех.
Вы где спали последние 20 лет? ;) Сейчас подобные кнопы у половины мышей есть. А если считать только приличные - у всех.
Просто не вижу смысла менять работающую клаву и мышь, они у меня ещё ps/2.
Соответственно "новинками" не интересовался.
В офис берут самое дешевое железо, там так-же ни чего интересного.
Improver
25.09.2024, 13:48
Сейчас подобные кнопы у половины мышей есть.Я бы уточнил, "у половины игровых мышей", или небюджетных -- обычные, как правило, их не имеют. Да и наличие такой кнопки ещё не значит, что она будет не программная, часто переключение dpi выполнено через драйвер, что делает её бесполезной в любой системе, отличной от винды.
Я бы уточнил, "у половины игровых мышей", или небюджетных -- обычные, как правило, их не имеют.Играми никогда не увлекался и, соответственно - игровыми мышами никогда не интересовался. Но все мои мыши, как дома (3 шт.) так и на работе (2 шт.) - с такими кнопками. Даже самая старая, купленная ещё где-то в начале 2010-хх (та аж с двумя = + и -).
Последннюю свою мышь покупал в обычном супермаркете, где она валялась рядом с полками с мясом и молоком. Вроде за что-то около ~7 евро. Если это не обычная офисная мышь, то тогда я наверное ничего в них не понимаю. ;)
Насчёт "бюджетности" - одну из мышек покупал в FixPrice за что-то вроде 2 или 3 евро. На сдачу. Если это не бюджетная мышь, то что тогда - бюджетная?
Да и наличие такой кнопки ещё не значит, что она будет не программная, часто переключение dpi выполнено через драйвер, что делает её бесполезной в любой системе, отличной от винды.Почему это? Что мешает любой системе переключить разрешение по её нажатию?
PS: Насчёт:
Сейчас подобные кнопы у половины мышей есть.был неправ. Сейчас вспоминал-вспоминал и.... не смог вспомнить ни одной такой мыши. Без кнопки переключения DPI. Вроде и не видел таких вообще в последние годы.
- - - Добавлено - - -
В офис берут самое дешевое железо, там так-же ни чего интересного.В нашем офисе вроде у всех мышки с такими кнопками.
Improver
25.09.2024, 16:01
Почему это? Что мешает любой системе переключить разрешение по её нажатию?Отсутствие определённого стандарта на эти функции и родных драйверов, соответсвенно.
Сейчас вспоминал-вспоминал и.... не смог вспомнить ни одной такой мыши. Без кнопки переключения DPI. Вроде и не видел таких вообще в последние годы.Из хороших могу назвать Logitech (M100, M110, B100...), A4Tech (OP-330, OP-720, N-530...), брендовые DELL и множество подобных не имеют кнопок dpi -- не китайский ширпотреб.
В нашем офисе вроде у всех мышки с такими кнопками.А у нас на три сотни рабочих мест ни одной такой нет -- всё зависит от закупщика. :)
А так, вообще да -- глянул на сайте одного магазина компьютерной техники, там из 1285 представленных моделей мышек 797 имеют кнопки dpi/cpi, т.е. больше половины.
Если нужно втыкать именно без левел шифтеров, тогда извините.
Вот проект -- DVI выход для Apple 2 (с шифтерами)
https://github.com/rallepalaveev/A2DVI/tree/main/v2.0
Я люблю так смотреть
https://kicanvas.org/?github=https://github.com/rallepalaveev/A2DVI/tree/main/v2.0
Adrian's Digital Basement про нее https://www.youtube.com/watch?v=rrM6bPCk8DM
В комментариях к видео прояснили ситуацию, что в августе обновили даташиты и убрали 5В толерантность.
В даташите на RP2350 (https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf) пока держится про 5.5В на FT-пинах, но не всегда. Лучше шифтеры.
Там и про это писали, собственно два комментария:
owenvogelgesang7314
The newer RP2350 is officially 5V tolerant, I believe, but yeah the RP2040 is not.
coreykirkpatrick4392
Actually the 5v tolerance was removed as of Aug data sheet update.... there is now a caveat that 5v is only tolerant if the IOVDD is powered by 3V3, thus you still need level shifters.
...Текущий план использовать для этого Pi Pico (в моем случае rp2040-zero, но разницы нет). Пока только смотрел примеры от TinyUSB. ...
Попытался посмотреть, как реализован usb-хост в TinyUSB для rp2040...
Вообще ни чего не понял... :( файлов куча, привычных для меня "проектов" не увидел. Даже не понял для какой среды разработки всё это накручено.
Единственное, что увидел, это то, что реализован он "аппаратно" с использованием max3421, и видимо программно, но с подключением мыши к usb-разъёму или выводам портов, тоже не понял. Эта "кроссплатформенность" напоминает свалку всего в одну кучу... :(
Читал про rp2040, что для него "микропитон" заточили, думал и в TinyUSB будет, что-то подобное, а там код на Си... В общем - тёмный лес... :(
TinyUSB надо проинициализировать и дать ей колбеки, в принципе и все. Дальше остается только реагировать на колбеки. В стандартных примерах есть один простой, который умеет слушать мышь, клавиатуру и масс стораж и печатает информацию в консоль. Еще есть реализация хоста через родной USB разъем на пипико, есть на пинах через PIO. При чем тут max3421 я, честно говоря, не понял. На схеме Пико такого чипа нет.
Проекты для rp2040 обычно не для IDE, а для SDK -- то есть компилятор + библиотеки + все, что нужно, чтобы это запускалось. Конфигурация проекта задается в файле CMakeLists.txt.
Наверное хорошая отправная точка про то, как начать, здесь: https://www.raspberrypi.com/documentation/microcontrollers/c_sdk.html
По крайней мере год назад из под обычной винды настраивать SDK было можно, но как-то очень занудно. Я ни разу этого не делал. Сам пользуюсь виндой с WSL2, и там все просто.
... При чем тут max3421 я, честно говоря, не понял. На схеме Пико такого чипа нет.
В файлах настройки, если выбран вариант с max3421, то идёт инит spi. Т.е. к Пико по spi подключается плата с max3421.
Проекты для rp2040 обычно не для IDE, а для SDK -- то есть компилятор + библиотеки + все, что нужно, чтобы это запускалось. Конфигурация проекта задается в файле CMakeLists.txt.
Наверное хорошая отправная точка про то, как начать, здесь: https://www.raspberrypi.com/documentation/microcontrollers/c_sdk.html
По крайней мере год назад из под обычной винды настраивать SDK было можно, но как-то очень занудно. Я ни разу этого не делал. Сам пользуюсь виндой с WSL2, и там все просто.
Ясно.
Кстати в среде Ардуино, уже добавлена библиотека TinyUSB, и плата rp2040. Пытался там посмотреть, но это ещё хуже, в среде Ардуино вообще всё спрятано, а в примерах нашел только что-то типа hid-info типа просмотра дескриптора подключенного устройства.
В файлах настройки, если выбран вариант с max3421, то идёт инит spi. Т.е. к Пико по spi подключается плата с max3421.
Я вижу MAX3421 в списке драйверов TinyUSB. Наверное библиотека позволяет подключить к Пико MAX3421 по SPI, но мне ничего про это неизвестно. Пико имеет два драйвера: rp2040 и pio_usb. У меня клавиатура воткнута в USB-разъем на плате RP2040-Zero через USBOTG адаптер.
Кстати в среде Ардуино, уже добавлена библиотека TinyUSB, и плата rp2040. Пытался там посмотреть, но это ещё хуже, в среде Ардуино вообще всё спрятано
В самой среде Ардуино легко полистать примеры, познакомиться с тем, что дают. А потом уже можно настроить проект в platfromio, можно в VSCode. Там лучше понятно куда что ложится: или в сам проект, или если это фреймворк в %USERPROFILE%/.platformio. И доступна более гибкая настройка всех параметров проекта.
Я вижу MAX3421 в списке драйверов TinyUSB. Наверное библиотека позволяет подключить к Пико MAX3421 по SPI, но мне ничего про это неизвестно. Пико имеет два драйвера: rp2040 и pio_usb. У меня клавиатура воткнута в USB-разъем на плате RP2040-Zero через USBOTG адаптер.
... А потом уже можно настроить проект в platfromio, можно в VSCode. ...
Установил VSCode, пример usb-хоста для rp2040 запустился с настройками "по умолчанию", мышь на usb-разъёме сразу определилась и данные с "колеса прокрутки" поступают.
Правда переключить на работу с max3421 с ходу не получилось, при компиляции VSCode сообщает, что нет файлов "spi.h", собственно пока и фиг с ним.
Модуль rp2040 в 2 раза дешевле отдельной платки с чипом max3421.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot