usb hid что это
USB HID интерфейс для STM32 в STM32IDE
Ряд микроконтроллеров STM32 имеют на борту USB интерфейс для связи с компьютерами. Как правило, удобнее всего использовать предоставляемый компаний ST Microelectronics драйвер класса CDC (Communication Device Class ). Он позволяет использовать на стороне компьютера UART через USB и не требует установки драйверов. Со стороны STM32 при этом требуется только поменять операции вывода данных, остальное делается самостоятельно. Причём скорость такого соединения может быть практически любой, поддерживаемой компьютером.
Однако ряд разработок, особенно, когда приходишь в другую компанию, где используется HID Class (Human Interface Device), в случае разработки новой версии устройства требуется поддерживать ранее выбранный интерфейс. Что, собственно, и случилось. Примеры проектов от самой ST, которые они дают при загрузке STM32 Cube MX и IDE, как обычно, дали только минимальное понимание, но не раскрыли, что и как надо делать. Я когда-то разбирался с USB, даже писал собственный драйвер, но это было так давно… Остались только общие воспоминания. Посему пришлось искать дополнительную информацию, чтобы получить стартовую точку.
Первое найденное было видеороликом на youtube в стиле HID за 5 минут 🙂 Автор даёт доступ к своему коду на GitHub. Всё, типа круто, красиво, просто вставляйте к себе и всё будет чудесно. Судя по отзывам под роликом, некоторым этого хватило. Изучив исходники понял, что минимального прозрения не наступило, да и уровень полученной информации мал для того, чтобы решить поставленную задачу. Но закомство с этим материалом было явно полезным. Решение вопроса с использованием кубика (STM32Cube MX) мне лично импонирует больше, чем другие подходы, поскольку позволяет отвлечься от ряда низкоуровневых операций и генерация проекта всегда происходит в одном стиле. Соответственно, изучение этого примера показало, на какие файлы надо обратить внимание, где и что надо поменять или добавить, какие функции использовать для получения и отправки данных именно для нашей выбранной среды программирования.
Следующий поиск оказался весьма удачным. Хабр — известный сайт, на котором можно найти много полезного по разной электронной тематике. Нашлась там и статья STM32 и USB-HID — это просто. Я не являюсь постоянным клиентом Хабра и не знаю автора этой статьи RaJa, но на мой взгляд это очень хорошая статья, описывающая основные положения работы HID интерфейся. Без её прочтения читать дальше здесь бессмысленно, поскольку далее будут, в основном, комментарии для адаптации кода к среде разработки STM32IDE/STM32CubeMX + Atollic TrueStudio. (Далее STM32IDE). Да и столь популярный в 2014 году и реально очень неплохой проект EmBlocks, увы, умер.
Первое, что необходимо решить — как тестировать вновь создаваемое устройство. Лет… дцать назад я использовал для этого анализатор и синтезатор трафика USB — очень полезные, но дорогие игрушки 🙂 Сейчас у меня такой возможности нет, да и должен же быть более простой путь. Тем более для простого стандартного интерфейса без написания собственного драйвера. Авторы обоих рассмотренных выше проектов пошли самы простым для них путём — написание простой программы на известных им языках. Но автор статьи на Хабре сделал очень правильный шаг — он написал свой проект, совместимый с программой ST HID Demonstrator (ссылка есть в статье), позволяющей поуправлять нашим устройством, как графически, так и послать свои данные и посмотреть, что пришло от нашего устройства. Фактически программа может использоваться и в дальнейшем для отладки будущей программы на выбранном микроконтроллере.
Своё ознакомление с проектом для HID я осуществлял с платой STM32L476 Discovery. Плата, вообще говоря, может быть любой, где USB интерфейс микроконтроллера физически подключён к отдельному разъёму USB. Есть у меня и Nucleo 32 с STM32L4, но там один разъём USB тспользуется и для программирования/отладки, и для связи с хостом, что добавляет интриги в интерфейс и может служить источником дополнительных непоняток. Оно нам надо?
Итак, комментарии и дополнения к статье по привязке HID к STM32IDE примерно по тем же шагам, как и в хабровской статье.
Структура проекта
В STM32IDE структура всех проектов задаётся при генерации проекта из среды назначения функциональности пинов и пользователю о том заботиться не надо. В частности, в кубике (что отдельном STM32Cube MX, что в встроенном в STM32IDE) активируем USB, как Device, и добавляем Middleware USB Custom HID.
Заходим в Clock Configuration. Вполне вероятно, что могут быть проблемы с системными частотами, которые маркируются малиновым цветом.
Если так, нажимаем Resolve Clock Issues и, скорее всего, всё будет настроено на максимальные частоты. Главное — USB Clock будет выставлен на 48 МГц. Надо заметить, что в семействе STM32L4 генератор на 48МГц имеет автоподстройку по SOF (Start Of Frame), что позволяет создавать USB устройства без внешнего кварца/генератора. Если, конечно, остальной дизайн допускает использование некварцованных генераторов. Для других семейств не проверял, поскольку для моего текущего проекта был выбран именно L4. Только надо отметить, что при использовании USB есть некоторая минимальная частота работы микроконтроллера. Я делал прикидку для другого проекта, где надо общаться с хостом и при этом потреблять минимум тока. Задачи простые, не требуют большой скорости и я хотел запустить МК на 8МГц. Оказалось, что меньше 14МГц при подключении USB ставить не могу, RCC не позволяет. Пришлось остановиться на следующем круглом значении 16МГц.
Собственно, настройка аппаратной части USB и выбор файлов, отвечающих за базовую функциональность этого интерфейса на на этом закончены. Вся остальная периферия, находящаяся на выбранной плате настраивается автоматически при её выборе на старте проекта. Сохраняем, генерим проект и переходим к «программированию» в сравнении с описанным на Хабре проектом.
Это страшное слово Descriptor
Стандартные массивы данных для передачи информации хосту, с чем он будет иметь дело. Для интереса можно посмотреть дескрипторы устройства и конфигурации. Сейчас их можно оставить такими, как получились, но в дальнейшем они наверняка потребуют редактирования. Впрочем, не исключено, что они будут генериться по тем параметрам, что ставятся в кубике. Что не может не радовать. А вот Report Descriptor стоит изучить получше — это фактически основное, что придётся в дальнейшем править ручками. Не знаю, откуда RaJa взял его дескрипторы, в нашём случае они генерируются кубиком и располагаются в следующих файлах проекта:
| Дескриптор от Raja | Дескриптор от ST | Файл в проекте |
| RHID_DeviceDescriptor | USBD_FS_DeviceDesc | usbd_desc.c |
| RHID_ConfigDescriptor | USBD_CUSTOM_HID_CfgFSDesc | usbd_customhid.c |
| RHID_ReportDescriptor | CUSTOM_HID_ReportDesc_FS | usbd_custom_hid_if.c |
Поскольку для простоты сейчас будем работать только с ST HID Demonstrator, то не мудрствуя лукаво я просто скопировал содержимое RHID_ReportDescriptor в соответствующее место моего проекта. Только подставил свои константы на место длины. Надо отметить, что надо точно посчитать количество байтов в этом дескрипторе (в этом проекте 79) и убедиться, что именно это значение стоит в Class Parameters. Не больше и не меньше. Иначе хост не опознает подключённое устройство. Проверено 🙂
Далее заходим в файл usbd_customhid.h и меняем значения CUSTOM_HID_EPIN_SIZE и CUSTOM_HID_EPOUT_SIZE на 0x40U. Честно говоря, немного напрягает то, что ST не даёт альтернатив смене значения по умолчанию 2 на другое значение и далее в коде с использованием этих констант стоит комментарий, что не более 2х байт. Но, с другой стороны, это было рекомендовано в первом найденном описании и, вообще говоря, установка такого значения выглядит достаточно логично. Иначе в чём отличие CustomHID от обычного? Проблема в том, что при регенерации проекта из кубика, что на этапе первичного кода происходит довольно часто, это значение не сохраняется и его надо восстанавливать ручками. Для этого я себе в main вывел строку warning, чтобы не забывать проверить эти константы. Возможно я ошибаюсь, и в дальнейшем всё окажется проще. Но в такой конфигурации работает 🙂
Цикл обмена (пишем/читаем)
Для выдачи данных на хост всё достаточно аналогично описанию на Хабре. Только название функции другое: USBD_CUSTOM_HID_SendReport(). Все остальные реомендации из той статьи подходят по полной программе.
А вот чтение здесь интереснее, чем на Хабре. И на самом деле несколько проще. Обработка принятого массива происходит в usbd_custom_hid_if.c / static int8_t CUSTOM_HID_OutEvent_FS(uint8_t event_idx, uint8_t state).
В этом тестовом проекте я не заморачивался с обработкой входных параметров и следуя своей обычной практике минимальности времени обработки прерываний, просто копирую полученные данные в заранее определённый массив и устанавливаю флаг готовности данных от USB
Ну, а собственно «сбор данных» (нажатие кнопок джойстика) и реакция на полученные от хоста данные в этом прото проекте делаю внутри бесконечного цикла в main.c Всё просто 🙂 В этом прото проекте нет разделения реакции на SET_FEATURE и SET_REPORT, с этим надо будет разобраться далее, в реальном проекте. Компилируем, запускаем, подключаем к хосту и там должен появиться новый CustomHID от STMicroelectronics.
Звпускаем на хосте USB HID Demonstrator. На плате, с которой я запускал этот проект, не имеет органов для работы с Variable Inputs/Outputs, поэтому в разделе Graphic customization были убраны соответствующие назначениями, оставлено 5 кнопок и назначены ID, определённые в проекте: 1, 2 для Output report (входные данные для ST) и 4 для Input Report (выход от ST).
Моей задачей для этого проекта было управлять парой светодиодов на плате, что стало работать сразу, как эта программа обнаружила подключенную плату, и включать «лампочки» этой платы при нажатии различных кнопок джойстика на плате, а вот здесь сразу не получилось. При указанных настройках все пять лампочек одновременно зажигались при нажатии на центр джойстика. Остальные кнопки не отображались. При этом, если перейти на Input/Otput transfer, то данные были вполне ожидаемы. Т.е. сам интерфейс работает, но отображение в программе на хосте не отвечает моим запросам. Слава богу ST предоставляетс исходники, а в соседнем кубике сидит программист нашей группы, пишущий в том числе и софт для компьютеров. В общем, он подправил одну функцию и сгенерил исполняемую программу. Всё стало работать, как хотелось. Конечно, можно было бы на каждую кнопку создать свой report с уникальным номером, что исходно и предусмотрено. В этом случае было бы достаточно посылать по одному байту для каждой кнопки, но мой проект предусматривает многобайтный отчёт. Исходник подправленной функции и подправленный исполняемый файл можно скачать по ссылке ниже.
На этом, пожалуй, всё. Если у Вас есть такая же плата 32L476GDISCOVERY, то для начала можно просто скачать мой прото проект, адаптированный для него демонстратор и исходник изменённой функции по этой ссылке. Исходный USB HID Demonstrator скачивается с сайта STM, инсталлируется и его исполняемый файл заменяется моим. Импортируете в STM32IDE мой проект, компилируете и должны получить работающую базу для своих проектов. Если у Вас другая плата, то адаптируете «сбор информации» и включение светодиодов под свою плату.
Для дальнейшей работы обязательно прочтите указанную статью RaJa с Хабра. Она даст понимание того, что и как должно быть сделано для других проектов с USB HID интерфейсом. А ещё лучше начать с неё 🙂
У меня изучение статей и адаптация под мои хотелки заняло три дня. Описание заняло больше 🙂 Надеюсь, что у тех, кто воспользуется этой статьёй, аналогичный процесс займёт не более одного дня. Комментируйте, спрашивайте. Что смогу — отвечу. Что не смогу, вместе поищем решение.
Русские Блоги
Устройство HID для анализа протокола USB
1. Краткое описание
Одним из преимуществ устройств USB HID является то, что операционная система поставляется с драйверами HID, и пользователям не нужно разрабатывать драйверы, если они используют системные вызовы API для завершения взаимодействия.
Он содержит две наиболее важные инструкции:
1. 《Device Class Definition for human interface device (HID)》
2. 《Universal Serial Bus HID Usage Tables》
Документ 1 описывает базовый состав и формат HID, а документ 2 является дополнением к документу 1, в котором перечислены основные компоненты различных устройств HID.
2. Протокол HID
Основываясь на введении базового протокола USB в предыдущей главе, в этой главе основное внимание уделяется классам взаимодействия человека и компьютера HID. (Базовый протокол USB-связи доступен по умолчанию)
2.1 Канал связи USB HID устройства
Все устройства HID связываются с хостом через канал управления USB (канал по умолчанию, конечная точка 0) и канал прерывания (конечная точка 1 или конечная точка 2).
Описание запроса конвейера
Элемент управления (конечная точка 0) должен передавать дескриптор USB, код запроса класса и данные сообщения для запроса
Вход прерывания должен передавать входные данные с устройства на хост
Выход прерывания Дополнительно Передача выходных данных с хоста на устройство
Конвейер управления в основном используется в следующих трех аспектах
Конвейер прерывания в основном используется в следующих двух аспектах
Передача выходных данных прерывания от USB-хоста к USB-устройству является необязательной.Когда выходные данные прерывания не поддерживаются, USB-хост передает данные на USB-устройство через канал управления.
2.2 Дескрипторы, относящиеся к USB HID устройствам
В дополнение к пяти стандартным дескрипторам USB (дескриптор устройства, дескриптор конфигурации, дескриптор интерфейса, дескриптор конечной точки, строковый дескриптор), дескрипторы устройства HID также включают три дескриптора, зависящих от класса устройства HID: Дескриптор HID, дескриптор отчета (Отчет), дескриптор объекта (Физический) 。
Иерархическая взаимосвязь между ними показана на рисунке:
Можно видеть, что на уровне Interface desc указано HID desc.
В дополнение к трем конкретным дескрипторам HID, которые составляют интерпретацию устройств HID, к устройствам HID относятся пять стандартных дескрипторов:
1 — Boot Interface SubClass
2.2.1 Дескриптор HID
Дескриптор HID связан с дескриптором интерфейса, поэтому, если устройство имеет только один дескриптор интерфейса, независимо от того, сколько дескрипторов конечных точек оно имеет, устройство HID имеет только один дескриптор HID. Дескриптор устройства HID в основном описывает номер версии спецификации HID, дополнительные дескрипторы, используемые при обмене данными HID, и длину дескриптора отчета. В следующей таблице показана структура дескриптора HID.
| Смещение | площадь | Размер (байт) | ценность | описание |
| 0 | bLength | 1 | цифровой | Длина этого дескриптора в байтах |
| 1 | bDescriptorType | 1 | постоянный | Тип дескриптора (здесь 0x21 Категория HID) |
| 2 | bcdHID | 2 | цифровой | Номер версии спецификации HID (код BCD) с использованием 4-х шестнадцатеричных кодов формата BCD |
| 4 | bCountryCode | 1 | цифровой | Идентификационный код страны назначения оборудования |
| 5 | bNumDescriptors | 1 | цифровой | Количество поддерживаемых вспомогательных дескрипторов |
| 6 | bDescriptorType | 1 | постоянный | Типы дескрипторов, связанных с HID, см. В таблице ниже |
| 7 | wDescriptorLength | 2 | цифровой | Сообщите общую длину дескриптора |
| 9 | bDescriptorType | 1 | постоянный | Константа, используемая для определения типа дескриптора, используйте устройство с более чем одним дескриптором |
| 10 | wDescriptorLength | 2 | цифровой | Общая длина дескриптора, используемого в устройствах с более чем одним дескриптором. |
| Значение типа дескриптора | |
|---|---|
| 0x22 | Дескриптор отчета |
| 0x23 | Дескриптор объекта |
В стандартном запросе USB, когда используется дескриптор конфигурации get, он будет возвращен в следующем порядке, то есть дескриптор HID также будет возвращен.
Дескриптор HID также содержит тип и длину присоединенного к нему дескриптора (например, дескриптора отчета), а затем хост запрашивает соответствующий дескриптор на основе информации в дескрипторе HID. Другими словами, хост знает, что устройство является HID-устройством, получая дескриптор.
Обычно в процессе запроса дескрипторов конфигурации и получения всех дескрипторов выбирают » Class 0x01 ”：
2.2.2 Дескриптор отчета
Дескриптор отчета является наиболее сложным из всех описаний USB, потому что он отличается от других и не имеет фиксированной длины и таблицы. Это переменный и разнообразный дескриптор.
Дескриптор отчета фактически сообщает хосту, какие биты или байты представляют значение данных, передаваемых через конечную точку прерывания. Таким образом, он может быть более абстрактным, но после прочтения следующего описания он станет более ясным в ретроспективе.
Чтобы понять дескриптор отчета, необходимы два официальных USB HID-данных:
《Device Class Definition for human interface device (HID)》
《Universal Serial Bus HID Usage Tables》
Дескриптор отчета состоит из одного элемента. Элемент делится на два типа. Имеются следующие форматы:
1. Short Item
2. Long Item
Из вышеперечисленного здесь в основном речь идет оShort Item, Наиболее используемым является Short Item 。
Короче говоря, первый 1 байт представляет цель этого элемента:
bSize: представляет следующие данные размером до 4 байтов.
bType: показывает, какой тип элемента является данным элементом. Существует три основных типа: основной (0x00), глобальный (0x01) и локальный (0x02).
bTag: представляет более подробную классификацию по соответствующему элементу.
| —— Основное разделено на: ввод, вывод, функция, коллекция, конечная коллекция.
| —— Глобальное разделение на: страницу использования, логический минимум, логический максимум и т. Д.
| —— Локальное разделение на: использование, минимум использования, максимум использования, строку и т. Д.
ДляbSize + bType + bTag Комбинация из 1 байта показана в таблице ниже:
В таблице перечислены все взаимодействия. Знак «?» Представляет значение младших 4 битов. Например, короткий элемент:
0x05 =》 0000 01 01 Можно разбить:bSize = 1；bType = 1（Global）；bTag = 0（Usage Page）
Приведенная выше интерпретация исходит из 《Device Class Definition for human interface device (HID)》 Файл, следующий за 0x01 Это 1 байт данных. Необходимо выяснить конкретное значение этих данных:《Universal Serial Bus HID Usage Tables》 Может быть найдено в, что означает: Generic Desktop 。
То есть согласно [bSize + bType + bTag】 Информация знает конкретное значение тега. Комбинируя таблицу таблицы и конкретный тег, найдите соответствующее значение следующих данных, чтобы достичь цели интерпретации дескриптора отчета.
Разберем функцию и значение нескольких важных тегов.
Main
| —— Ввод: указывает режим ввода данных о работе устройства на хост. Этот формат данных формирует входной отчет.Хотя входной отчет может быть передан конвейером управляющего типа с получением отчета (входом), он обычно передается входным конвейером типа прерывания, чтобы гарантировать, что обновленный входной отчет может быть передан в каждый фиксированный период. Передайте хосту.
| —— Вывод: представляет формат данных, выводимых хостом для операции устройства. Этот формат данных формирует выходной отчет. Выходной отчет обычно не отправляется на устройство путем опроса, но выходной отчет должен быть отправлен прикладным программным обеспечением в соответствии с фактическими потребностями, поэтому большинство конвейеров контрольного типа используются для отправки отчета на устройство с установить команду отчета (вывода). Конечно, вы также можете использовать прерванный выходной конвейер для передачи, но обычно это не рекомендуется.
| —— Функция: указывает формат данных конфигурации, требуемых хостом для отправки на устройство. Этот образец данных формирует характерный отчет. Отчет о функциях может использовать конвейер управления только для получения и установки значения функции устройства с помощью команд получить отчет (функция) и установить отчет (функция) соответственно.
Main （ Формат данных и смысл Три тега (Вход, Выход и Функция), которые создают формат данных отчета в), имеют общие определения данных. Эти данные:
Данные / константа: данные основного элемента представляют собой значение переменной (установленное на Data) или фиксированное неизменяемое значение (установлено на Constant). Константы используются в отчете Feature или используются для заполнения, поэтому длина отчета указывается в байтах.
Массив / переменная: каждое поле данных основного элемента может указывать, что запускается одна из нескольких различных операций (установлено значение «Массив»), или каждое поле указывает только одну операцию (установлено значение «Переменная»). Если это переменная, значение данных Report Count равно количеству полей данных отчета. Если это массив, значение данных Report Count указывает максимальное количество операций, которые могут быть запущены одновременно.
Абсолютный / Относительный: данные основного элемента предоставляют абсолютные значения относительно фиксированной контрольной точки (установленной на Абсолютный) или предоставляют относительные значения относительно предыдущего отчета (установленный на Относительный).
Без переноса / переноса: когда значение данных основного элемента достигает экстремального значения, оно переключается на чрезвычайно низкое значение, и наоборот, что называется намоткой (установлено значение Wrap). Например, поворотную ручку можно повернуть на 360 °, а выходное значение находится в диапазоне от 0 до 10. Если установлено значение Wrap, значение достигает 10, а значение становится 0, если она вращается в том же направлении. В противном случае, если он достигнет 0, поверните его снова, чтобы получить 10.
Линейный / Нелинейный: данные основного элемента и шкалы операций являются линейными (для параметра «Линейный») или нелинейными (для параметра «Нелинейный»).
Предпочтительное состояние / Нет предпочтений: операция, соответствующая основному элементу, автоматически вернется в исходное состояние (установленное на Предпочтительное состояние), когда она не запущена, или она не вернется в исходное состояние (установлено на Нет предпочтительного). Например, клавиши клавиатуры и самоцентрирующиеся джойстики являются предпочтительными состояниями.
Нет нулевой позиции / нулевое состояние: операция, соответствующая основному элементу, имеет состояние, при котором значимые данные не будут отправляться, то есть данные не будут находиться между логическим минимумом и логическим максимумом. Этот вид манипуляции должен быть отмечен как нулевой. Состояние, иначе это не нулевая позиция. Например, если имеется несколько клавиш, но в столбце Использование не указано, что ни одна клавиша не нажата, вы можете установить нулевое состояние в данных основного элемента, чтобы исключить состояние отсутствия нажатой клавиши из логического элемента. Минимальный и логический максимальный диапазон, см.Universal Serial Bus HID Usage Tables Пример в Приложении A.3 документа.
Non Volatile / Volatile: Данные основного элемента Feature не могут быть изменены хостом (установлен на Non Volatile) или разрешены для изменения хостом (установлен на Volatile). Обратите внимание на основные пункты Input и Output, эта установка метки бессмысленна, поэтому код бита 7 должен быть 0.
Битовое поле / буферизованные байты: формат данных основного элемента должен быть в байтах.Если этого недостаточно для формирования байтов, он будет автоматически заполнен байтами, затем установите буферизованные байты.