Вектор06Ц, клава и мышь PS/2 через "ПУ"

[PPC]

Хотя, кому нужно это приращение, если будем получать готовую координату?

Если я возьму и видео-режим переключу с высокого на низкое разрешение ненадолго. Как теперь координату интерпретировать?

Мыши прирастают, и этим ценны. Absolute mode хорош когда есть touch panel с фиксированным разрешением и пиксел спэйсингом.

Жаль конечно, что идея карты с мульти-фифо отвергается. Мне уже виделось как я настраиваю SPI mode и clock prescaler и пишу в какой-нить SPI flash через ПУ. Ну пусть будет мышь. Только если можно, в relative mode (со смещениями) пожалуйста.

[Advertiser]

[Improver]

Если я возьму и видео-режим переключу с высокого на низкое разрешение ненадолго. Как теперь координату интерпретировать?

В случае разрешений Вектора -- нет никаких проблем. С учётом того, что режим 512х256 -- это просто экранные плоскости со смещением, то можно использовать те же 256 значений, курсор даже не сдвинется при изменении разрешения. А при желании можно добавить "двойную точность", добавить девятый бит по горизонтали в порт С...

Absolute mode хорош когда есть touch panel с фиксированным разрешением и пиксел спэйсингом.

А на Векторе и есть, фактически, фиксированное разрешение.

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

Проблема возникает при долгом (или очень долгом) смещении мыши в одну сторону. С абсолютными возможны два варианта, которые неприемлемы в общем случае (годятся только при управлении курсором в рамках одного экрана): или насыщение или заворот. Думаю понятно, что в общем случае это может привести или к залипанию или к "метаниям".

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

то это можно сравнительно легко повторить и в эмуляторах и в v06cc.

Насчёт эмуляторов соглашусь, сделать там такой контроллер будет сложнее...

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

встречаются контроллеры которым необходима калибровка от центра.

Калибровка мыши "от центра" -- это просто её поднять и перенести в другое, более удобное место на коврике.

[PPC]

курсор даже не сдвинется при изменении разрешения

Тогда это будет не очень приятно при высоком разрешении. Вроде, мышь двинули, а курсор стоит. И всяко 512 отсчётов в байт невпихуемо. Значит, старший бит придётся читать каждый раз для режима высокой точности (пусть хоть и из другого порта). А с относительные смещения можно ограничить диапазоном +-127

У вектора пикселы в высоком и низком разрешении имеют разный спейсинг. Если смещения относительные, чувствительность можно рихтовать программно, и добиться более-менее естественной гармонии между хуманом и девайсом в соответствии с конкретным софтом. Так мне верится, может зря. Но абсолютный режим - это железный дровосек-автоматон. Он приходит c безоговорочной координатой. Намаемся, боюсь (даже не учитывая залипы).

[Improver]

Тогда это будет не очень приятно при высоком разрешении.

Это будет незаметно на Векторе, как незаметно переключение из 256х256 на 512х256 в "Тесте устройств". Но если нужна двойная точность, то я бы предложил добавлять бит не в старший разряд, а в младший -- так будет проще, не потребуется пересчёт координат в экранной плоскости при изменении разрешения. Т.е. девятый бит =0, то пишем в нечётные плоскости, а если =1 -- то в чётные, по тем же координатам.

А насчёт "намаемся" и "гармонии" могу сказать, что любом случае, всё, что не будет сделано в контроллере, потребуется делать в Векторе, а там уж намаяться можно в разы больше.

[ivagor]

Все эти проблемы легко решаемы в контроллере

Совершенно не согласен.

[Improver]

Совершенно не согласен.

Почему? По сути, есть физические перемещения мышки, которые надо переделать в перемещения курсора по экрану. Кто будет заниматься какой частью этих преобразований не важно -- драйвер на Векторе, или контроллер, но их нужно выполнить, с отработкой всех коллизий (типа заворотов и метаний), это неизбежно. Можно, конечно, всё сделать в Векторе, но любая ардуина с этой задачей справится влёт, так почему бы и нет? Да и написать и отладить скетч легче, чем сделать то же самое на Векторе, при отсутствии эмуляции этой новой железки. Конечно, без драйвера для Вектора не обойтись, но чем он будет проще, тем проще получится разработка всего устройства. Разве нет?

[PPC]

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

Ещё как важно! Этим absolute addressing мы сразу убиваем возможность выставить mouse курсор в произвольное место по желанию (софта), или, скажем ограничить зону действия мыши некоей областью. Я так понимаю, курсор нам отрисовывать тоже давать не планируется...

В общем, с точки зрения софта, работа в absolute mode будет мукой. Это если мы примем, что контроллер разрулит все указанные выше проблемы (большинства из которых просто нет в relative mode по определению)

ЗЫ. И это ещё при том, что для нормальной точности в режиме высокого разрешения придётся дважды лазить в порт зачем-то. 512x256 и так тяжел а тут ещё и лишние чтения.

[Improver]

Ещё как важно! Этим absolute addressing мы сразу убиваем возможность выставить mouse курсор в произвольное место по желанию (софта), или, скажем ограничить зону действия мыши некоей областью.

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

В общем, с точки зрения софта, работа в absolute mode будет мукой. Это если мы примем, что контроллер разрулит все указанные выше проблемы (большинства из которых просто нет в relative mode по определению)

Разрулит, даже не сомневайтесь. Самая простая ардуинка сейчас мощнее Вектора, так почему бы это не использовать? А будет ли это мукой или спасением -- только практика покажет.

ЗЫ. И это ещё при том, что для нормальной точности в режиме высокого разрешения придётся дважды лазить в порт зачем-то.

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

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

Согласен, поэтому и предлагаю обойтись минимальной обработкой в контроллере.

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

[ivagor]

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

Тут уже надо переходить к конкретным цифрам, которых у меня в полном виде нет. Грубые прикидки такие:
1. Текущий вариант KTSerga - в районе 5000+ тактов на опрос. Очень много (можно ускорить), поэтому контроллер хотелось бы, но я согласен даже на такой вариант, т.к. он уже реализован в железе и работает.
2. Вариант с параллельной передачей от контроллера. Тут смотря как считать и что считать, но пусть будет 200-300 тактов. Разница между абсолютным и относительным (вектор сам будет считать абсолютные) - ну тактов 100, ну пусть даже 200, зато можно использовать для любых задач.

[ivagor]

Почему?

Потому что это не общее решение, пример когда оно не применимо я приводил и могу еще привести (и PPC еще привел), но даже одного неподходящего примера достаточно.

чем он будет проще, тем проще получится разработка всего устройства

Согласен, поэтому и предлагаю обойтись минимальной обработкой в контроллере.