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

[Improver]

Без буфера по-моему нет смысла пробовать.

Можно сделать буфер на стороне контроллера -- в любом случае сейчас комовских мышей не найдёшь, надо как-то делать преобразование ps2 <-> com, там и добавить буфер.

[KTSerg]

4800 бит/c ~ 480 байт в сек, делим на 50 получается 9.6 байт за прерывание. Получается, что FIFO глубиной 16 символов не будет переполняться, если не пропускать прерывания.

Мышки по-моему работают на 1200.
...

Да я понимаю.
Тоже считал: 50 (прерываний в сек.) * 16 (байт, буфер fifo) * 8 (бит) = 6400 бит/с. Соответственно ближайший меньший стандарт 4800.

Было бы интересно прикинуть, максимально возможную скорость, которую может потянуть Вектор, если подключить 16550 к "ПУ", с учетом всех потерь на управление портом 55-ым.

Я ещё не изучал 16550, не знаю, нужно ли постоянно читать регистр статуса (необходимость постоянно переключать направление порта), чтобы узнать состояние буфера, или достаточно подключить выход "INTRPT" на вход порта "С", тогда часто переключать направление портов не нужно будет.

[svofski]

Можно сделать буфер на стороне контроллера -- в любом случае сейчас комовских мышей не найдёшь, надо как-то делать преобразование ps2 <-> com, там и добавить буфер.

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

Адаптер ps/2 на serial -- задача решенная уже много раз. Ну просто например: https://hackaday.io/project/27575-ps...ouse-converter. Но ps/2 в наше время тоже как-то уже грустно. Если б я сам загорелся идеей, я бы взял rp2040-zero и сделал адаптер USB-мышки и клавиатуры с помощью pico-pio-usb. Но я точно не буду.

[KTSerg]

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

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

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

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

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

[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-мыши, что-бы потом маяться со спамом данных, которые валятся без запроса.
Для интеграции мыши в игры, это слишком заморочисто.
Делать/использовать два контроллера для мыши, что-бы получить данные, на интерпретацию которых нужно дополнительно тратить ресурсы... мне кажется это перебор.

[Advertiser]

[svofski]

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

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

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

[KTSerg]

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

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

[svofski]

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

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

[KTSerg]

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

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

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