USB to COM mouse converter (Продолжаем адаптировать интерфейсы)

[EJSanYo]

Продолжаем адаптировать интерфейсы

Немало времени прошло в тех пор, как я сделал активный конвертер интерфейсов дабы иметь возможность подключить к старенькому компу чуть более современную и удобную мышь, чем поддерживают изначально возможности COM-порта. Вскоре после этого была начата проработка возможности адаптировать аналогичным образом и новые USB устройства для подключения через COM и PS/2. Не только мыши, но и клавиатуры. Однако, увы, значительно более высокая сложность протокола и отсутствие опыта работы с USB помешали эффективно продвигаться в данном направлении. Тем не менее, кое-какие наработки есть, и настало время поделиться ими.



Была изготовлена макетная плата на основе чипа AT90USB647, который выглядел неплохим решением для создания относительно дешёвого и простого USB хоста. Изначально планировалось создать универсальное устройство, поддерживающее COM и PS/2 выход, а также ряд дополнительных функций. Однако на данном этапе реализован лишь USB вход и COM выход.
Прошивка сделана на основе демо-примера из проекта LUFA USB Library и функций COM-мыши, используемых в предыдущих конвертерах.
На данном этапе прошивка работает лишь с самыми простыми стандартными мышами, поддерживающими т.н. boot-протокол. Составные устройства, вроде беспроводных комплектов клава+мышь, а также "навороченные" и "геймерские" мыши, имеющие дополнительные кнопки и "over 10500 dpi", работать не будут. Поддержки подключения через USB хабы также нет. Но на безрыбье, как говорится...
Контроллеры AT90USB647 продаются с уже прошитым в них заводским бут-загрузчиком, позволяющим перепрошивать их прямо через USB без программатора. Однако из того же LUFA был адаптирован сторонний загрузчик как более удобный в применении. Для его прошивки, разумеется, уже потребуется отдельный программатор.

Файлы проекта:

Аппаратная версия 1.0
v.1.0 alpha

В архиве файлы самой прошивки, бутлоадера, пакет исходников LUFA (необходим для компилирования кода), а также схема конвертера в том виде, в каком она существует сейчас ("лишние" элементы убраны). Для компиляции также потребуется WinAVR GCC. Если не планируется правка кода, можно просто подобрать hex-файлы в соответствующих папках и прошить их.

Некоторые пояснения по схемотехнике:

Предусмотрено наличие двух USB разъёмов. XS2 используется для перепрошивки устройства, XS1 - для мыши. В режиме прошивки подавать внешнее питание не обязательно, схема запитается от компа через XS2. Поскольку XS1 и XS2 фактически соединяются параллельно, на время прошивки мышь необходимо отключать.
Из кнопок в настоящее время используется лишь SB2 ("-") для активации прилагаемого к проекту бутлоадера. При этом конвертер следует подключать к компу через XS2 с зажатой кнопкой SB2. В остальном кнопки - задел на (вероятное) будущее.

Пояснения по работе конвертера:

Пока мышь не подключена, светодиоды отображают состояние "не готов" (горит один красный светодиод). Сразу после подключения USB устройства происходит его энумерация (горят оба светодиода), а далее в случае успешной инициализации мыши зажигается зелёный светодиод. В случае, если что-то пошло не так, конвертер вернётся к состоянию "не готов". При работе мыши красный светодиод короткими вспышками отображает приходящие от мыши пакеты данных.
Выходная часть конвертера (COM-порт) работает независимо от готовности USB и детектируется драйвером компа как мышь сразу после подключения и подачи питания.
Мышь можно подключать и отключать на ходу, не обесточивая конвертер. Цикл энумерации производится при каждом подключении USB устройства.

Напоследок следует заметить, что, как показала практика, качество реализации boot-протокола у различных моделей мышей разное и даже не коррелирует явно с ценой и производителем гаджета! В boot-режиме скроллер мыши не поддерживается, хотя мышь при вращении колёсика обычно и шлёт пакеты (они пустые). По крайней мере все три стандартные кнопки в протоколе поддерживаются (конвертером в том числе).

[EJSanYo]

Известно, что протокол обмена USB сложен уже сам по себе. Однако в случае клавиатур, мышей и пр. поверх него накладывается ещё один слой, под названием USB HID. Если в двух словах, в чём его особенность - в данном случае при работе гаджета уже речь не идёт о том, что это явно "клавиатура на 105 клавишей", или "мышь стандартная трёхкнопочная". В большей степени говорится о том, что "есть некое устройство, у него есть одна функция, сообщающая положение определённого количества координатных крутилок, в качестве которых могут быть координаты мыши, или колёсико скроллера, или регулятор громкости...да что угодно, на самом деле. И ещё другая функция, сообщающая состояние такого-то количества кнопок". Для каждого из передаваемых параметров девайс должен рассказать хосту о формате передаваемых данных, возможном диапазоне изменения этих данных (например, "крутилка №1 меняет своё положение от -32767 до 32767"), даже о характере их изменения (например, по линейной или логарифмической кривой) и много чего другое. И для девайсов это замечательно, поскольку не нужно привязываться к функциональным ограничениям, заложенным когда-то давным давно, когда даже 300 DPI для мыши считалось шикарно. Не нужно городить новые расширения протокола и прочие "костыли" чтобы ввести поддержку новых функций (как примерно это было с курсорными клавишами и колёсиком на PS/2 интерфейсе). Но для хоста вся эта универсальность...вырастает в сущий ад! Поскольку если по-честному, хост должен уметь как минимум всё это развёрнутое описание принять, адекватно интерпретировать и принять данные именно в таком виде, в каком этого желает неведомый разработчик конкретно подключенной модели мыши.
Впрочем, составители протокола прекрасно понимали, что в определённых ситуациях это может стать серьёзной проблемой. В частности, для производителей BIOS, когда они захотят добавить поддержку USB клавиатуры в свой продукт. До эпохи "4K видео" и навороченных графических UEFI-менюшек почти с операционную систему размером было ещё далеко, и ёмкости ПЗУ могло элементарно не хватить на всё про всё, даже если бы программисты осилили поддержку. Поэтому специально для клавиатур и мышей ввели в стандарт некий "режим совместимости", в который хост может перевести устройство относительно просто. В данном режиме функционал и формат данных чётко оговорён стандартом. Для мыши, в частности, две координаты 8-битной точности (даже если в "полноценном" режиме мышь умеет точнее) и три кнопки. А раз формат данных оговорён - хост сразу может принимать данные, и код его поддержки значительно упрощается. Именно в этом режиме и работает данный переходник с USB мышью.

[Merchant*RU]

Насколько понимаю, основная задача переходника, это дать возможность компьютерам, класса ХТ..286 или более ранним, работать с USB-периферией. В таком случае, если гипотетическая мышь имеет богатейший функционал, громадную кучу кнопок и адское разрешение - зачем всё это нужно компьютеру класса ХТ?

Или я неправильно истолковал предыдущий пост?

[Гость]

зачем всё это нужно компьютеру класса

цель не такая, Fe. Цель - максимально универсализировать переходник. Чтобы на том же 286 любая многокнопочная и многоколёсиковая мышь работала как МЫШЬ в первую очередь. Что не ясно то?

[Гость]

Мне кажется, будет намного проще сделать такой "конвертер" следующим образом:
-- в качестве основы берём одноплатный компьютер с Линуксом на борту -- что-нибудь на арме или кортексе
-- этот одноплатный компьютер должен иметь ЮСБ хост на борту (хотя бы один хост)
-- также желательно, если у него будет встроенный СОМ-порт (или два), но это уже не обязательно, т.к. СОМ-порты можно использовать юэсбические

Если я правильно понял, это всё в общем то же самое, что написал Топикстартер, но с той лишь разницей, что "конвертер" имеет встроенный Линукс -- что на несколько порядков упрощает подключение к нему разных "новых" юэсбических устройств

Удачи!

[Anonymous1]

xoiss, с одним "но": комп с линуксом не влезает внутрь разъёма, а mcu влезает...

[Гость]

комп с линуксом не влезает внутрь разъёма

http://www.picotux.com/

// правда, конкретно этот без USB

Ну, мой основной посыл состоит в том, что вместо Atmel AT90xxx взять тоже MCU или SoC, но с ядром, для которого есть Линукс.
Конкретно picotux - там ARM7, на который можно поставить только "кастрированный" Линукс. Я его привёл скорее просто как иллюстрацию по поводу "впихуемости невпихуемого".
Лучше взять ARM9 (или аналогичный ему Cortex), ну или MIPS -- главное, чтобы MMU на борту был. По размеру это будет примерно то же, что и picotux.

Удачи!

P.S. Вот ещё как вариант -- посмотрите, как можно:

[EJSanYo]

Merchant*RU задача тривиальна: есть старые компы. Вполне ещё рабочие. А вот устройства ввода, которые к ним возможно подключить, если и остались с "тех" времён, то работают весьма паршиво. Поэтому и изыскиваются способы, как прикрутить несовместимое.
xoiss да, так порой делают. Берётся, скажем, Raspberry, и через GPIO-порты прикручивается практически куда угодно. Выглядит довольно громоздко, но в целом работоспособно. Другое дело, что я в программировании под линуксы, мягко говоря, не силён...а вот arm-ы, это уже другое дело. Присматриваюсь к возможностям STM-овского HAL-а, быть может, оно умеет больше, чем LUFA?

А пока была провдена проверка довольно большого количества мышей. И вот что у нас вышло:
Razer Copperhead, уже весьма старый, но тем не менее вполне геймерский гаджет. boot-протокол не поддерживает и стеком переходника не опознаётся. Ещё пример: комплект Logitech 660 Deluxe, а также пара китайских конвертеров PS/2 клава+мышь -> USB - с аналогичным результатом.
Так или иначе, в подавляющем большинстве мышей boot-протокол был обнаружен. Однако его реализация...в значительной мере напомнила мне ситуацию с поддержкой редко используемых режимов работы в PS/2 мышах (режим "read mode", который задействовался в первом поколении переходников PS/2 -> COM). Стандарт обязывает, чтобы его поддержка была, но не раскрывает, в каком именно виде поддержка должна быть. В результате у подавляющего большинства мышей (например, серия Genius NetScroll и практически весь китайский ноунейм) скорость перемещения в режиме boot-протокола резко падает относительно нормальной - приблизительно до уровня шариковой мыши. Чего впрочем, в досовском экране Norton Commander-а достаточно. Некоторые же мыши скорость не снижают и работают почти так же быстро и хорошо, как в прямом USB подключении к компу. Пример - беспроводная Genius traveller 9000, Logitech-овская RX 250 (к слову, весьма добротное, "олдскульное" изделие на контроллере от Cypress, поддерживающее как USB, так и PS/2 через пассивный адаптер) и...как ни странно, китайский ноунейм за 80р из Aliexpress. В аутсайдерах же у нас Ritmix RMW-110, в обычном режиме нормально работающая, однако в boot-протоколе ползающая лишь по оси X!
И в заключении, как уже упоминалось, при вращении скроллера практически все мыши передают пустые пакеты данных (перемещение по нулям, и кнопки не нажаты), несмотря на то, что в boot-протоколе скроллер не поддерживается. Исключение среди проверенных мышей - уже упоминавшаяся RX 250, которая никаких пустых пакетов не отправляет.