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

[KTSerg]

16550 это и есть UART с буфером. Я на всякий случай уточню -- что идея подключения компортовской мышки не столько ради упрощения, сколько ради обобщения. Если есть компорт, который Вектор может полноценно использовать, то к нему можно подключить мышь, а можно модем или терминал, или другой Вектор.
...

Погуглил про СОМ-мыши.
Подключать СОМ-мышь к Вектору не имеет ни какого смысла.
Если ps/2-мышь можно настроить, чтобы сообщала смещение только по запросу, то СОМ-мышь тупо шлёт данные при перемещении, не интересуясь, принимают эти данные или нет. Не нашел инфы, про интервалы между пакетами. Не понятно, как часто СОМ-мышь отправляет данные. Но подозреваю, что Вектор задолбается разгребать спам от СОМ-мыши.

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

Получается, что в случаях, когда программа не критична, что мышь ест 30% времени, подойдёт и простая в подключении ps/2.
На Арканоид я очень удачно наткнулся там ресурсы тратятся фактически только на перемещение каретки и шарика.

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

[Advertiser]

[svofski]

Не понятно, как часто СОМ-мышь отправляет данные. Но подозреваю, что Вектор задолбается разгребать спам от СОМ-мыши.

Что ж тут непонятного. 1200 7N1: 1200/9/50, значит за прерывание может прийти максимум 3 байта и это верхняя оценка с запасом.

Микрософтовский протокол шлет обновления примерно 40 раз в секунду по три байта за посылку. Кнопки + два байта со знаком + битик синхронизации. Вот тут нарисована картиночка: https://roborooter.com/post/serial-mice/

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

[KTSerg]

Что ж тут непонятного. 1200 7N1: 1200/9/50, значит за прерывание может прийти максимум 3 байта и это верхняя оценка с запасом.

У меня складывается впечатление, что за одно прерывание, 3 байта не успеют полностью приняться.
Поскольку нет синхронизации в виде запрос/ответ, то должен быть дополнительный буфер принятых данных, из которого будут вылавливаться пакеты.

Микрософтовский протокол шлет обновления примерно 40 раз в секунду по три байта за посылку. Кнопки + два байта со знаком + битик синхронизации. Вот тут нарисована картиночка: https://roborooter.com/post/serial-mice/
Это как раз то, что самодельный контроллер все равно пришлось бы заставить делать, только уже сделано за нас.

Почему-то не вдохновляет.
Делать СОМ-мышь из usb или ps/2-мыши, что-бы потом маяться со спамом данных, которые валятся без запроса.
Для интеграции мыши в игры, это слишком заморочисто.
Делать/использовать два контроллера для мыши, что-бы получить данные, на интерпретацию которых нужно дополнительно тратить ресурсы... мне кажется это перебор.

[svofski]

У меня складывается впечатление, что за одно прерывание, 3 байта не успеют полностью приняться.
Поскольку нет синхронизации в виде запрос/ответ, то должен быть дополнительный буфер принятых данных, из которого будут вылавливаться пакеты.

Разумеется нужен буфер. Я говорю с первого сообщения про буфер и в каждом сообщении повторно привожу его характеристики в расчетах.

Я пожалуй сдаюсь. Разочаровался в своей способности излагать мысли.

[KTSerg]

Разумеется нужен буфер. Я говорю с первого сообщения про буфер и в каждом сообщении повторно привожу его характеристики в расчетах. ...

А я то думал, что речь шла о fifo внутри 16550.
Но его не достаточно, чтобы корректно принять данные от мыши. И я сказал, что дополнительно к fifo в 16550, нужен ещё один кольцевой fifo для корректного вылавливания пакетов.

[svofski]

А я то думал, что речь шла о fifo внутри 16550.
Но его не достаточно, чтобы корректно принять данные от мыши. И я сказал, что дополнительно к fifo в 16550, нужен ещё один кольцевой fifo для корректного вылавливания пакетов.

Я именно о нем и говорю. Ты можешь объяснить почему его недостаточно для того, чтобы принять три байта? Тебя смущает то, что три байта будут приходить необязательно все вместе и их нужно складывать в программный буфер? Это тривиальная задача.

[KTSerg]

Я именно о нем и говорю. Ты можешь объяснить почему его недостаточно для того, чтобы принять три байта? Тебя смущает то, что три байта будут приходить необязательно все вместе и их нужно складывать в программный буфер? Это тривиальная задача.

Да, я предвзято отношусь у потоку данных СОМ-портов.
Меня нервирует, что отправленный блок данных, может приходить кусками разной длины, а два отдельно отправленных блока данных, могут объединяться в приёмном буфере в непрерывную цепочку данных.
Это конечно не касается конкретно мыши, где блок всего 3 байта. Хотя и с ней будет точно так-же.
Но принимать даже эти несчастные 3 байта кусками в разных прерываниях, это тоже не фонтан.
Я понимаю, что вылавливать их не такая уж сложная задача. В конце концов, приняв 5 байт, мы гарантированно имеем один целый пакет, и его уже можно анализировать.
Просто не вижу в этом особого смысла. Зачем собирать два контроллера и потом возиться с дикой мышью, когда можно сделать сразу то, что нужно Вектору, что-бы освободить его от лишних хлопот, и получать от контроллера мышиные данные в нужном виде.

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