Что такое составное usb устройство
Составное устройство USB на STM32. Часть 4: Два-в-одном
В заключительной части публикации о составном устройстве USB я расскажу о том, как заставил заработать составное устройство USB, а также поделюсь некоторыми неочевидными нюансами этого процесса.
Работа составных частей устройства была описана во второй и третьей частях публикации.
Ответы на вопрос, зачем это всё было затеяно, даются в начале первой части и в конце четвёртой.
Исходные коды публикуемой реализации составного устройства USB, состоящего из виртуального COM-порта и дуплексной звуковой карты находятся здесь.
Создаём Composite Device Class
Файлы драйвера составного устройства usbd_comp.c и usbd_comp.h расположены в папках Core/Scr и Core/Inc соответственно.
Структура класса составного устройства аналогична структуре класса звукового устройства и содержит подобный набор функций-обработчиков событий.
Основная функция драйвера составного устройства заключается в том, чтобы определить, драйвер какого устройства нужно подключить для обработки события. При обработке запросов (Requests) это определяется по номеру интерфейса в случае Standard Requests или атрибутам запроса в случае Class-Specific Requests. При обработке пакетов данных переключение производится, как правило, по номеру конечной точки (EP).
Запросы Communication Device Class-Specific Requests подробно описаны на стр.18 – 30 документа [4], а Audio Device Class-Specific Requests, соответственно, на стр.74 – 85 документа [3].
Читаем дескриптор
Дескриптор описанного в публикации составного устройства USB состоит из девяти байтов раздела Configuration Descriptor, восьми байтов раздела Interface Association Descriptor (IAD) для двух интерфейсов виртуального COM-порта, 58 байтов дескриптора виртуального COM-порта, восьми байтов раздела IAD для трёх интерфейсов звукового устройства и 183 байтов дескриптора звукового устройства USB.
Виртуальный COM-порт использует интерфейсы 0 и 1, а также конечные точки 1 и 2. Дуплексное звуковое устройство использует интерфейсы 2, 3 и 4, а также конечную точку 3.
Разбираем работу устройства
Рассмотрим доработанный файл usb_device.c, расположенный в папке USB_DEVICE/App:
Сначала создаётся переменная hUsbDeviceFS. Тип USBD_HandleTypeDef объявлен в usbd_def.h.
Функция MX_USB_DEVICE_Init вызывается из main.c.
Вызовом функции USBD_Init задаются начальные значения переменной hUsbDeviceFS.
Затем вызовом функций HAL_PCDEx_SetTxFiFo производится настройка буфера USB для каждой конечной точки составного устройства.
Неочевидный нюанс 1: по умолчанию настройка буфера USB производится при исполнении функции USBD_LL_Init, размещённой в файле usbd_conf.c. В теле этой функции области, помеченной как USER CODE, нет. Т.е. при каждой генерации кода STM32CubeMX будет удалять настройки буфера для конечных точек 2 и 3. Именно поэтому окончательная настройка буфера USB производится уже после того, как функция USBD_LL_Init отработала.
Вызовом функции USBD_RegisterClass в hUsbDeviceFS.pClass размещается указатель на созданную в usbd_comp.c переменную USBD_COMP, содержащую указатели на обработчики событий, относящихся к классу устройства. Тип USBD_ClassTypeDef объявлен в usbd_def.h.
Вызовом функции USBD_RegisterInterface в hUsbDeviceFS.pUserData размещается указатель на созданную в usbd_comp.h пустую переменную USBD_COMP_fops_FS.
В дальнейшем обработчики событий составного устройства USB будут вызывать обработчики событий нужного устройства, входящего в составное, а также подключать нужный интерфейс связи с оконечными устройствами.
Вызовом функции USBD_Start производится запуск устройства USB.
Неочевидный нюанс 2: составное устройство будет упорно определяться как виртуальный COM-порт, если не поменять значения трёх байтов в стандартном дескрипторе устройства USB (USB standard device descriptor), размещённом в файле usbd_desc.c, причём при каждой генерации кода STM32CubeMX эти изменения будет удалять:
Неочевидный нюанс 3: виртуальный COM-порт в данном решении работает корректно только в случае, когда номер используемой им конечной точки меньше, чем номер конечной точки звукового устройства.
Неочевидный нюанс 4: виртуальный COM-порт в данном решении работает корректно только в случае, когда при инициализации в его буфер прописываются параметры порта (см. USBD_COMP_Init). Без этой записи программы терминалов к COM-порту могут и не подключиться.
Проверка работоспособности драйвера составного устройства USB
Неочевидный нюанс 5: при проверке работоспособности «эхо» через COM-порт возвращается, когда составное устройство уже «переключено на COM-порт». В реальном применении устройства передача может начаться, когда подключено звуковое устройство. Чтобы избежать подобной ситуации, перед началом передачи производится вызов функции COMP_CDC_Transmit_FS для подключения драйвера виртуального COM-порта:
Выводы
Автору удалось реализовать составное устройство USB, состоящее из виртуального COM-порта и дуплексной звуковой карты, на ресурсах платы NUCLEO-F446ZE.
Решение оформлено в виде проекта в среде разработки STM32CubeIDE. После генерации кода STM32CubeMX для восстановления работоспособности решения необходимо вручную изменить значения трёх байтов в стандартном дескрипторе устройства USB (USB standard device descriptor), размещённом в файле usbd_desc.c.
От автора
Данный цикл публикаций подводит черту, фиксирует результат проекта, которой мне удалось достичь в одиночку.
Хочу поблагодарить своих читателей за доброжелательность и тёплый приём. Я никогда не был и никогда уже не буду профессиональным разработчиком ПО для микроконтроллеров. И это моя первая публикация про разработку программного обеспечения.
Благодарю Георгия (RX9CIM) за моральную поддержку при запуске проекта.
Отдельная благодарность romanetz_omsk, без которого я бы забросил проект ещё два года назад.
По логике дальнейшего развития MVP нужно приступать к написанию DSP, а это уже достаточно сложная для меня математика. Как это осилить в одиночку, ума не приложу…
Русские Блоги
Составное устройство в USB-HID устройстве
Недавно компания разработала libusb под Linux и многого достигла. Среди них великие боги компании дали мне более глубокое понимание составных устройств HID, так что отлаживает ли он USB-HOST для Android, USB или Linux для Windows Libusb очень удобен и имеет более глубокое понимание некоторых из предыдущих проблем и использования некоторых функций. Поэтому эту статью необходимо записать, чтобы не забыть ее в будущем. Вы можете вернуться и посмотреть еще раз, или вы можете Удобно для других чиновников. 
На этот раз я также обобщил и разобрал некоторые разрозненные знания. Эта статья будет включать связанные API-интерфейсы для нескольких платформ, поэтому она немного сложна, но, пожалуйста, проявите терпение, чтобы прочитать ее, она может быть вам полезна.
2. Композитное оборудование HID
Этот великий бог очень хорошо резюмировал в своем блогеСоставное USB-устройство (запоминающее устройство и спрятанное), Также позвольте мне получить немного.
Клавиатура + пользовательский HID (HID-клавиатура + пользовательское устройство интерфейса пользователя), как показано на рисунке ниже, вы можете увидеть его в диспетчере устройств
Первоначально эти две вещи обычно существуют на двух HID-устройствах отдельно и делятся на два аппаратных средства, таких как USB-клавиатура и USB-мышь, но теперь они существуют на одном и том же оборудовании. Картинка выше должна быть очень интуитивно понятной.
Заимствуя оригинальные слова великого бога,
Прежде всего следует сказать, что, поскольку это составное устройство, существует несколько интерфейсов. Здесь два устройства. Затем требуются два интерфейса. Требуются несколько дескрипторов устройств. Достаточно одного.
Что касается дескриптора настройки, нужен только один. Сколько дескрипторов конечных точек нужно. Ну, я не знаю (шучу, вы резюмируете, что не знаете). Вы должны поговорить о нескольких типах USB. передача инфекции
Этот отрывок из Великого Бога не ошибочен: для HID-устройства достаточно только одного дескриптора устройства и одного HID-дескриптора. Но как насчет дескриптора интерфейса, дескриптора интерфейса? Для одного устройства вам нужно только одно, но для составного устройства вам нужно два дескриптора интерфейса, каждый интерфейс представляет функцию, поддерживаемую устройством HID, как показано на рисунке ниже, составное устройство нашей компании может использовать UsbTreeView Очень интуитивно понятно
Более того, великий бог нашей компании произвел на меня большое впечатление. В протоколе hid, будь то отдельное устройство или составное устройство, операционная система будет считать его независимым в соответствии с дескриптором интерфейсного устройства устройства, а именно:
Поэтому при программировании необходимо обращать внимание на номер устройства, с которым будет работать, при получении интерфейса устройства.
Три, дескриптор конечной точки
В исходных словах Бога, приведенных выше, количество дескрипторов конечных точек не указано четко.Количество дескрипторов конечных точек обычно связано с требованиями.
Для одного устройства обычно существует только один дескриптор устройства, если это одностороннее устройство (например, клавиатура), существует только одна конечная точка ввода (IN), как показано ниже:
Для одного устройства обычно существует только один дескриптор устройства. Для двустороннего устройства (такого как пользовательский HID) есть две конечные точки, IN и OUT, как показано ниже:
Конечно, для составных устройств, таких как клавиатура нашей компании + пользовательский HID (HID Keyboard + custom Human Interface Device)
Есть два дескриптора интерфейса и три дескриптора конечной точки.
В-четвертых, подведение итогов развития композитного оборудования.
4.1 В программировании Windows при поиске USB-устройств:
Я начал связываться с HID только сейчас, и в моем проекте было одно устройство, поэтому при поиске устройства нужны только VID и PID устройства.
Однако когда у компании был проект 915 МГц, она столкнулась с композитным оборудованием. Что ж, результатом является проблема, устройство может быть найдено, но каждый раз, когда оно читается и записывается, программное обеспечение вылетает. После многих отладок обнаруживается, что это проблема с составным устройством, потому что составное устройство в системе имеет общий PID и VID, поэтому при поиске PID и VID он открывается напрямую, и не оценивается, является ли это двусторонним устройством. В результате он завершается, что приводит к сбою программного обеспечения.
Следовательно, при оконном программировании, когда встречаются одинаковые VID и PID, необходимо судить, и необходимо найти двустороннее устройство (то есть устройство, которое может быть прочитано и записано).
Код, как показано ниже:
4.2 В программировании под Linux ищите оборудование и используйте bulktansfer () и функции, чтобы обратить внимание на проблемы
Среди нескольких вышеперечисленных функций необходимо обратить внимание на то, что входные параметры отличаются при использовании одного устройства и составного устройства.
а. Для одного устройства:
libusb_claim_interface () и libusb_release_interface () и libusb_kernel_driver_active ()
И libusb_detach_kernel_driver () Параметры этих функций interface_number равны 0,
Поскольку обычно существует только один интерфейсный интерфейс, а нумерация начинается с 0, interface_number = 0;
Для функции libusb_bulk_transfer () значения edpoint и length: IN endpoint = 0, OUT endpoint = 1, а длина равна 64.
б. Для комбинированного оборудования, если используется указанное выше значение, оно может быть неправильным, например:
Композитное оборудование нашей компании, использование вышеуказанных параметров абсолютно неправильно, правильные параметры должны быть
interface_number = 1， IN endpoint = 1, OUT endpoint = 2.
Как это может быть универсальным? Может ли это быть единое устройство или составное устройство?
Это необходимо сделать. При поиске устройств при использовании API необходимо сохранить информацию о дескрипторе интерфейса и дескрипторе конечной точки отдельного устройства или составного устройства.
Для составных устройств есть два дескриптора интерфейса, вам необходимо отфильтровать, сохранить информацию об интерфейсе и конечной точке с двумя конечными точками, чтобы вы могли передавать параметры
Чтобы быть универсальным, моя отладка такая, код следующий:
При подаче заявки на интерфейс:
Его можно менять под разные устройства, что удобно.
4.3 В программировании хоста Android обратите внимание при использовании
В Android эти методы требуют внимания:
В Android большая часть информации в Интернете не объясняет различия между отдельными устройствами и составными устройствами.
Большинство материалов, которые я прочитал, основаны на фильтрации PID и VID устройства для получения объекта UsbDevice с последующим непосредственным управлением устройством.
Приведенный выше код может быть правильным для одного устройства, потому что существует только один интерфейс для одного устройства, поэтому getInterface (0) верен.
Для составных устройств это слишком просто. Существует несколько интерфейсов, и общие операции по-прежнему необходимы. Такая гибкость кода также очень хороша.
Можно обнаружить, что различные методы Android знакомы с параметрами одноименной функции libusb в Linux.Поэтому видно, что нижним слоем USB Android должен быть libusb.
Следовательно, при поиске упомянутого выше составного устройства оно сможет читать и писать, и объект дескриптора интерфейса и объект дескриптора конечной точки двух конечных точек будут сохранены.
Конкретный код выглядит следующим образом:
Как было сказано выше, это все записи, относящиеся к композитному оборудованию HID. Надеюсь, вы поможете.
Композитное USB-устройство не может должным образом работать с USB 3.0 [решено]
Что вас может беспокоить…
Попробуйте эти исправления:
Решение 1. Обновите драйвер USB-контроллера
Если ваш драйвер USB-контроллера поврежден, устарел или отсутствует, вероятно, возникает ошибка.
Вы можете обновить драйвер контроллера USB вручную или автоматически.
Вариант 1 — Вы можете перейти на веб-сайт производителя своего фирменного компьютера или USB-контроллера, а затем выполнить поиск последней версии USB-контроллера, соответствующей вашей конкретной версии Windows (например, Windows 64 bit) и загрузите драйвер вручную.
После того, как вы загрузили правильные драйверы для вашей системы, дважды щелкните загруженный файл и следуйте инструкциям на экране, чтобы установить d river.
Driver Easy автоматически распознает вашу систему и найдет для нее правильные драйверы. Вам не нужно точно знать, в какой системе работает ваш компьютер, вам не нужно рисковать загрузкой и установкой неправильного драйвера, и вам не нужно беспокоиться об ошибке при установке.
Загрузить и установите Driver Easy.
После обновления драйвера USB-контроллера до последней версии перезагрузите компьютер, чтобы проверить, успешно ли подключен принтер.
Решение 2: Обновите драйвер принтера
Решение 3. Отрегулируйте настройки BIOS
Для включения поддержки устаревших USB выполните следующие действия:
Вот и все. Возможно, теперь вы сможете использовать свой принтер с компьютером под управлением Windows. Не стесняйтесь комментировать ниже, если у вас есть какие-либо вопросы.
Помогаем компьютеру, если он не смог опознать USB устройство
Бывает, что при подключении USB 3.0 устройства, оно работает в режиме USB 2.0. Этим грешат, в частности, некоторые WiFi адаптеры с интерфейсом USB. Как решить данную проблему и заставить коварный гаджет перейти в скоростной режим USB 3.0, путем внесения изменений системный в реестр, я подробно написал здесь, поэтому повторяться не буду. Единственное, что могу добавить, если в роли «тормоза» выступает не сетевой адаптер, а внешний USB 3.0 диск, идентифицируемый как скази (SCSI) накопитель, попробуйте поковырять его настройки в этой ветке реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class<4d36e97b-e325-11ce-bfc1-08002be10318>\00xx.
реклама
Казалось бы, ну разве может быть что-нибудь еще хуже, чем замедленная работа устройства на порту USB? Еще как может! Новехонькое устройство, воткнутое в USB порт, может не заработать вообще.
Самое удивительное, что на самом деле, это вовсе не страшно. Я как раз на днях столкнулся с подобным случаем, поэтому поделюсь впечатлениями…
Итак, воткнув только что купленный USB гаджет в свободный USB порт своего компьютера, пользователь может получить на экране сообщение:
реклама
Это сообщение свидетельствует о неработоспособности подключенного USB-устройства.
Вынув это устройство, и вставив в тот же USB-порт другое, заведомо исправное USB-устройство (мышь там, или флэшку) – пользователь получает на экран точно такое же сообщение об ошибке, а исправное устройство на порту также не работает.
Через некоторое время вышеприведенное сообщение об ошибке с рабочего стола исчезает, но в диспетчере устройств системы можно лицезреть неприглядную картину:
реклама
Некоторые пользователи, столкнувшись с такой проблемой, склонны впадать в панику, решив, что подключаемое USB устройство неисправно, и его нужно возвращать/менять по гарантии/ремонтировать, плюс «по пути» этот зловредный гаджет еще и «унес на тот свет» как минимум USB-порт на материнской плате, к которому его подключали. На самом деле нет! Все не так грустно, как кажется, и торопиться с выводами тут не стоит.
Справедливости ради уточню, что в очень редких случаях подключаемый USВ девайс действительно может оказаться неисправен. Но вероятность этого крайне низка.
С очень высокой вероятностью и само подключаемое USB устройство, и USB порт на плате исправны и абсолютно рабочие. Так почему же возникла ошибка, целенаправленно убивающая нервные клетки и добавляющая пользователям седых волос?
Причина появления данной ошибки в том, что при быстром последовательном подключении/отключении USB устройства несколько раз подряд в системе происходит сбой USB контроллера. Причина череды подключений/отключений гаджета может быть разной: вы намеренно подключили/отключили устройство несколько раз подряд; у вас просто «дрогнула рука» и при подключении в «расшатанный» порт устройство само быстро переподключилось непроизвольно; наконец вы могли совать штекер USB-кабеля в сильно запыленный USB-порт и скопившаяся в порту грязь (а также возможная коррозия на контактах разъема) привела к быстрому повторному переподключению USB-устройства. В любом случае USB контроллер воспринял этот процесс неадекватно и произошел сбой в его функционировании. Только и всего. Чтобы устранить возникшую проблему зачастую (хотя не всегда) достаточно реинициализировать (отключить и снова включить) соответствующий контроллер в диспетчере задач Windows.
реклама
Но! Обычный пользователь не всегда знает, какой именно контролер нужно реинициализировать. Скажу больше, многие даже не знают, где этот контроллер искать вообще. Поэтому побороть данную проблему лучше универсальным и наиболее надежным методом: нужно перезагрузить компьютер, чтобы произошла аппаратная реинициализация USB контроллера. А лучше выключите компьютер, выньте устройство/шнур из USB порта, очистите штекер и сам разъем USB от грязи, снова плотно вставьте USB устройство или шнур от него в порт на материнской плате и затем включите компьютер.
Составное USB устройство на STM32F4
После реализации USB audio, захотелось прикрутить к проекту еще и ком-порт. Естественно, через USB CDC. Тема в интернете освещена многократно, но, в основном, по форумам производителей МК. Ближе всего подходит к моему случаю аппнота NXP AN11115 (http://www.nxp.com/documents/application_note/AN11115.zip) в которой разбирается составное устройство UAC+CDC.
Виртуальный ком-порт можно реализовать множеством способов. Например, Prolific в своих микросхемах PL2303 объявляет устройство как Vendor-specific class, один интерфейс с двумя конечными точками. То есть, сама по себе эта микросхема никакого отношения к CDC не имеет, вся необходимая логика реализуется в драйвере. Драйвер копирует данные в/из виртуального порта в конечные точки USB устройства путем программирования соответствующих URB (USB request block — запрос на передачу по USB).
Я выбрал другой путь — использование драйвера ком-порта операционной системы. Пример USB CDC есть от ST вместе с USB-стеком и драйвером COM-порта на сайте.
Объединение двух устройств сводится к редактированию дескриптора конфигурации
Вносим в инициализацию также открытие конечных точек CDC:
Деинициализация банальна и закрывает все конечные точки.
Разбор SETUP-пакетов становится немного сложнее. Нужно учесть, что теперь приходят class-specific запросы для разных классов.
Поскольку запросы «на запись» состоят из двух частей (запрос и данные), дорабатываем и разбор данных запроса
Дорабатываем обработчики чтения и записи в конечные точки данных
Обработчик начала кадра тоже чуть-чуть меняется (добавляем код по «разбору завалов» для CDC)
Обработчики незавершенных транзакций IN, OUT не трогаем. Также копируем все функции работы с VCP (virtual COM port) из usb_cdc_vcp.
ОЧЕНЬ ВАЖНО. Поскольку задействуются все конечные точки IN (0x81 — обратная связь UAC, 0x82 — данные CDC, 0x83 — запрос статуса CDC — реально она не используется), нужно определить TXFIFO под них. 1111