что такое составное 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
Составное устройство USB на STM32. Часть 1: Предпосылки
История эта началась три года назад, когда я осознал, что мне скоро исполнится 50 лет, что я погряз в бумажной работе, и что мне хочется чего-то нового. Работу поменять в моём возрасте уже проблематично, поэтому я решил начать pet-проект.
Первое, что приходит в таких случаях на ум старому радиолюбителю: новая радиостанция. Стопроцентно аппаратные решения остались в далёком прошлом. Сейчас гораздо более актуальны SDR-трансиверы: решение это программно-аппаратное, есть опубликованные примеры реализации, к некоторым из них даже выложены исходные коды прошивок.
Основная проблема в разработке заключалась в том, что несложные SDR-радиостанции, работающие в связке со звуковой картой, требуют наличия у компьютера, к которому они подключены, двухканальных линейных входа и выхода для работы приёмо-передающего тракта, а также COM-порта для работы CAT-интерфейса. В современных же ноутбуках аудиовход обычно предназначен для подключения микрофона гарнитуры и бывает только монофоническим.
Решением проблемы стала реализация составного устройства USB, состоящего из виртуального COM-порта и дуплексной звуковой карты. Кому интересно, как я с этим справился, не имея опыта программирования, милости прошу под cut.
TL/DR: Как я с этим справился, не имея опыта программирования? Просто начал программировать на C, а остальное приложилось само: MVP проекта реализован, а исходные коды публикуемой реализации составного устройства USB, состоящего из виртуального COM-порта и дуплексной звуковой карты находятся здесь: http://github.com/dmitrii-rudnev/selenite-habr
… и опыт, сын ошибок трудных.
И опыт и навыки формируются практикой. Для их формирования необходимо:
Язык C разрабатывался инженерами и для инженеров. Использование языка программирования C дало мне возможность абстрагироваться от ассемблера и машинных кодов с одной стороны, но в тоже время обращаться напрямую к регистрам или к памяти.
Нелюбимый многими STM32CubeMX с библиотекой HAL значительно облегчил мне процесс разработки хотя бы тем, что не надо было за каждой мелочью заглядывать в Reference Manual.
Кроме того, я очень многому научился, разбирая сгенерированный STM32CubeMX код:
В силу того, что я не мог гарантировать результат своей программистской деятельности, пришлось вводить градации по функционалу MVP проекта от простого к сложному.
Минимальный функционал MVP подразумевал подключение приёмной части радиостанции к линейному входу звуковой карты компьютера и приём на фиксированной частоте.
Следующим шагом планировалась реализация перестройки частоты через CAT-интерфейс, подключение приёмного и передающего трактов радиостанции к линейным входу и выходу звуковой карты и приём-передача на любительских диапазонах.
И только после этого планировалось подключение SDR-трансивера к компьютеру как звукового устройства USB с управлением по CAT-интерфейсу.
Такой подход сразу дал плоды: уже к началу 2019 года, всего через шесть месяцев после установки на мой компьютер STM32CubeMX, был реализован минимальный MVP проекта: функциональный аналог SDR-приёмника Softrock Lite II RX уверенно принимал сигналы точного времени на частоте 9996 кГц.
В настоящее время MVP проекта является функциональным аналогом SDR-трансивера Peaberry SDR V2 и работает как на приём, так и на передачу.
Структура приёмопередающего тракта SDR-трансивера
Описываемое в публикации составное устройство USB работает в составе SDR-трансивера. Структура приёмопередающего тракта разрабатываемого SDR-трансивера включает в себя пока только самый необходимый минимум и представлена на рисунке ниже:
При приёме радиосигнал поступает из антенны через полосовой фильтр (BPF) в квадратурный детектор (QSD). Полученный в результате квадратурный сигнал (IQ) через двухканальный вход дуплексного звукового устройства USB поступает в компьютер для дальнейшей обработки.
При передаче сформированный в компьютере квадратурный сигнал (IQ) через двухканальный выход дуплексного звукового устройства USB поступает в квадратурный возбудитель (QSE).
Полученный в результате радиосигнал подаётся через полосовой фильтр (BPF) в антенну.
Обработка сигналов на стороне компьютера осуществляется программой HDSDR.
Частота приёма и передачи задаётся настройками генератора плавного диапазона (VFO). Управление VFO и режимом работы (приём-передача) осуществляется из программы HDSDR через CAT-интерфейс, подключенный к виртуальному COM-порту.
Связь HDSDR с виртуальным COM-портом осуществляется посредством программы OmniRig, созданной канадским радиолюбителем Alex Shovkoplyas (VE3NEA).
CAT-интерфейс трансивера использует ограниченный набор команд популярного во всём мире трансивера Yaesu FT-817.
Виртуальный COM-порт и дуплексное звуковое устройство объединены в составное устройство USB, работа которого и будет разобрана в данной публикации. Для облегчения проверки работоспособности публикуемого решения на входные и выходные потоки устройств установлены шлейфы.
Вся необходимая для разработки описанного в публикации составного устройства USB документация была найдена поиском по сайту usb.org.
Техническое решение разрабатывалось на основе анализа созданной немецким радиолюбителем Andreas Richter (DF8OE) open source прошивки для трансивера mcHF M0NKA и его клонов. Ряд нюансов был проработан при попытках разобраться в кодах дуплексного звукового устройства USB на базе расширения X-CUBE-AUDIO для STM32CubeMХ.
Структура составного устройства USB
Описываемое в публикации составное устройство USB состоит из виртуального COM-порта и дуплексного звукового устройства USB 16 бит 48 кГц. Публикуемое решение реализовано на микроконтроллере STM32F446ZET6 из состава платы NUCLEO-F446ZE.
Упрощенная структура дескриптора представлена на рисунке ниже:
Дескриптор составного устройства USB создан по рекомендациям, содержащимся в документе:
Хотел бы заострить внимание на том, что в структуре дескриптора составного устройства USB важен порядок описания интерфейсов: сначала идёт описание интерфейса 0, затем интерфейса 1 и т.д. Номера используемых интерфейсами конечных точек (EP) могут идти не по порядку.
При генерации кода STM32CubeMX размещает дескриптор устройства (Device Descriptor) в файле usbd_desc.c. Нужно отметить, что STM32CubeMX при последующей генерации кода не сохранит изменения, вручную внесённые в дескриптор, т.к. они не находятся в области, помеченной как USER CODE.
Дескрипторы конфигурации и классов устройств размещаются в файлах usbd_cdc.c и usbd_audio.c, размещённых в папках директории Middlewares/ST/Class. Важно помнить, что STM32CubeMX даёт выбрать за раз только один класс устройств. Если ранее был выбран другой класс, при генерации кода файлы с драйверами этого класса из проекта будут удалены.
От автора
В следующей части публикации будет разобрана:
Помогаем компьютеру, если он не смог опознать 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 на 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 хост и составное USB устройство
Не так давно, была опубликована статья «Пастильда — открытый аппаратный менеджер паролей». Так как данный проект является открытым, то мы решили, что будет интересно, если мы будем писать небольшие заметки о процессе проектирования, о задачах, которые перед нами стоят и о трудностях, с которыми мы сталкиваемся.
Реализация USB хоста
Итак, во-первых мне нужно было реализовать на устройстве USB хост, чтобы оно могло распознавать и общаться с подключенной к нему клавиатурой. Так как в работе я использую связку Eclipse + GNU ARM Eclipse + libopencm3, то очень хотелось найти уже что-то готовое и желательно написанное с использованием библиотеки libopencm3. Желание мое было очень жирным, до последнего момента не верила, что мои поиски увенчаются успехом. Однако под конец рабочего дня, проскролив интернет до самого дна, я вдруг наткнулась вот на это. libusbhost? Серьезно? И это был не просто написанный на основе libopencm3 usb хост, он еще и был написан под STM32F4, под тот самый, который мы решили использовать в проекте. В общем, звезды сошлись и радости моей не было предела. Кстати, оказалось, что этот проект создавался как часть libopencm3, однако его так и не добавили в библиотеку.
Как библиотеку, libusbhost я не собирала, просто взяла необходимые мне исходники, написала драйвер для клавиатуры и, в общем-то все, погнали! Но обо всем по-порядку.
По аналогии с usbh_driver_hid_mouse.[ch], я написала драйвер для клавиатуры (usbh_driver_hid_kbd.[ch]).
Далее был реализован простенький класс, для работы с хостом:
Реализация составного USB устройства
Далее мне нужно было сделать так, чтобы наше устройство отображалось в диспетчере устройств и как клавиатура, и как дисковый накопитель. Тут вся магия в дескрипторах=) В этом документе, в главе 9, подробно описан USB Device Framework. Эту главу нужно очень внимательно прочитать и в соответствии с ней описать дескрипторы устройства. В моем случае получилось следующее:
Для работы с составным устройством был написан класс USB_composite, представленный ниже.
Как правило, функции control_request и set_config должны быть явно описаны для каждого устройства. Однако из этого правила есть исключение: Mass Storage Device. Итак, разберемся с конструктором класса USB_Composite.
Во-первых, мы инициализируем ноги USB OTG FS:
Во-вторых, нам нужно проинициализировать наше составное устройство, зарегистрировать USB_set_config_callback, о котором шла речь выше, и разрешить прерывание:
Так вот. Теперь, когда конструктор класса USB_Composite дописан, можно собрать проект, прошить устройство и увидеть, что «Запоминающее устройство для USB» больше не помечено предупреждением, а во вкладке «Дисковые устройства» можно обнаружить «ThirdPin Pastilda USB Device». И, казалось бы, все хорошо. Но нет=) Проблем стало больше:
1. Зайти на диск невозможно. При попытке сделать это все виснет, умирает, компьютеру очень плохо.
2. Распознавание устройства как дискового занимает более 2-х минут.
Об этих проблемах и о том, как их решить без вреда для здоровья написано здесь: USB mass storage device и libopencm3.
И, о, чудо! Никаких пятен=) Теперь все работает. У нас есть USB хост и составное USB устройство. Осталось только объединить их работу.
Объединение хоста и составного устройства
, Пастильда должна перехватить управление и отправить сообщение в ПК как клавиатура, после чего мы возвращаемся в режим трансляции и снова ожидаем комбинацию.
Код, реализующий все это, простой как палка:
, мы будем попадать в однострочное меню, а во флеше будет храниться наша зашифрованная база данных паролей.
Буду рада любым комментариям и пожеланиям.
И, конечно же, ссылка на github.