[s_black 0]

Спасибо, GenaSPB. Подскажите ещё, пожалуйста. В какой функции определяется логика посылок, ну, то есть, где определяется, что после получения такого-то дескриптора нужно отправить ту или иную посылку?

[jcxz 197]

11 часов назад, s_black сказал:

не могу нигде в сети найти пример реализации хоста на регистрах. Коллеги, посоветуйте ссылку. Спасибо.

Как уже писал: В IAR имеется неплохой набор примеров по работе с USB на разных МК. В том числе и для host. Всё через регистры, никаких калов с их монструозным стилем.

Например: ARM_NXP_7.80.4_12495.exe\LPC17xx\IAR-LPC-1788-SK\USB_Host  (IAR 7.80.4)

У них всё неплохо оформлено и разбито по уровням абстракции (по разным файлам), разбираться нетрудно. Сужу по своему опыту.

[s_black 0]

Спасибо, jcxz! Буду пробовать все варианты.

[GenaSPB 11]

9 hours ago, s_black said:

логика посылок

Собственно за это и отвечает UAB STACK. Применительно к ST, общее для всех клвссов устройств поведение описывается машиной состояний в usbh_core.c - а по каждому классу в соответствующем файле.

 

Изменено 20 октября, 2022 пользователем GenaSPB

[s_black 0]

Что меня смущает... В документе UM1720 User manual STM32Cube USB host library в п. 4.3.4 HID specific APIs and event callbacks написано, что функции USBH_HID_GetReport и USBH_HID_SetReport не применяются в boot режиме (not used in case of HID boot mouse/keyboard). По логу обмена я вижу, что в дескрипторе конфигурации мышь возвращает "bInterfaceSubClass=0x01 Boot Interface". Получается, что библиотека STM32 допускает ошибку и неправильно отправляет "bRequest=0x01 GET_REPORT (HID class)". Поэтому я и ищу место в коде, где описана логика что за чем и на основании чего отправляется в устройство.

[s_black 0]

Раскуривая исходник дальше нахожу, что GET_REPORT отправляется только из состояния IDLE.  По логу наблюдаю, что "bRequest=0x0A SET_IDLE (HID class)" идёт после получения дескриптора репорта (где расписываются кнопки и координаты в байтах ответа). А по логу обмена ноутбука с этой же мышью, после получения дескриптора репорта идут PID IN. То есть ноутбук не переводит мышь в IDLE и не запрашивает GET_REPORT.

Изменено 21 октября, 2022 пользователем s_black

[s_black 0]

По логу нахожу дальше, что после получения дескриптора репорта, хост устанавливает SET_IDLE, как я уже указал в предыдущем посте. После SET_IDLE отправляется "bRequest=0x0B SET_PROTOCOL (HID class)" в котором вместо полученного от мыши boot устанавливается report mode - "wValue=0x0001 Protocol=Report protocol". Стало понятным, почему далее хост отправляет GET_REPORT. Теперь осталось разобраться почему хост не захотел общаться в boot mode и пытается перестроить на report.

Изменено 21 октября, 2022 пользователем s_black

[s_black 0]

И ещё осталось понять как из состояния IDLE отправляется SET_PROTOCOL... Согласно исходника этого не может быть.

[s_black 0]

Н-да... Оказалось. что этот SET_IDLE совсем не то, что я думал( Эта функция Sets HID polling period. То есть логика правильная. В логе обмена с оптической мышью STM32  отсылает такие же посылки как и для китайской мыши, но оптическая мышь отвечает нормально, а китайская, после GET_REPORT - STALL((( Короче говоря - пока нет результата.

[jcxz 197]

55 минут назад, s_black сказал:

Н-да... Оказалось. что этот SET_IDLE совсем не то, что я думал( Эта функция Sets HID polling period. То есть логика правильная. В логе обмена с оптической мышью STM32  отсылает такие же посылки как и для китайской мыши, но оптическая мышь отвечает нормально, а китайская, после GET_REPORT - STALL((( Короче говоря - пока нет результата.

А виндовый драйвер этот запрос не отправляет китайской мыши? Если да, то почему?

[s_black 0]

Виндовый драйвер после получения дескриптора репорта долбит мышь PID IN-ами 1 раз в 10мс. А почему - я не знаю((( Пытаюсь выяснить.

Изменено 21 октября, 2022 пользователем s_black

[jcxz 197]

13 часов назад, s_black сказал:

Виндовый драйвер после получения дескриптора репорта долбит мышь PID IN-ами 1 раз в 10мс. А почему - я не знаю((( Пытаюсь выяснить.

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

Как версия.

[s_black 0]

Да, я тоже пришёл к такому выводу. Дело в том, что дескриптор мыши возвращает boot mode, а драйвер STM32 принудительно переводит его в repot. Возможно дело в этом. Буду проверять.

[s_black 0]

Не получилось((( Изменил report на boot - в результате логика обмена не поменялась. Наверное нужно изменить порядок запросов на такой, как генерирует винда.

[GenaSPB 11]

18 hours ago, s_black said:

Виндовый драйвер после получения дескриптора репорта долбит мышь PID IN-ами 1 раз в 10мс. А почему - я не знаю((( Пытаюсь выяснить.

 

Где-то в дескрипторе от мышах прописан интеррапт ендпоинт  с таким интервалом

Давно бы аннотиррванный дамп от usblyzer выложили...

Изменено 22 октября, 2022 пользователем GenaSPB