Endpoint usb что это
USB на регистрах: isochronous endpoint на примере Audio device
Еще более низкий уровень (avr-vusb): habr.com/ru/post/460815
USB на регистрах: STM32L1 / STM32F1
USB на регистрах: bulk endpoint на примере Mass Storage
USB на регистрах: interrupt endpoint на примере HID
Сегодня рассмотрим последний тип конечных точек, изохронный. Он предназначен для передачи данных, критичных к времени доставки, однако не гарантирует ее успешность. Самый классический пример — аудиоустройства: колонки, микрофоны.
Как ни странно, этот тип конечной точки оказался самым мозговыносящим (и это после всего, что я успел повидать с stm’ками!). Тем не менее, сегодня мы сделаем аудиоустройство и заодно чуть-чуть допилим ядро библиотеки USB. Как обычно, исходные коды доступны:
github.com/COKPOWEHEU/usb/tree/main/4.Audio_L1
github.com/COKPOWEHEU/usb/tree/main/4.Audio_F1
Доработка ядра
Допиливать ядро нужно потому, что у STM изохронные точки могут быть только с двойной буферизацией, то есть, грубо говоря, нельзя сделать 0x01 изохронной, а 0x81 управляющей. То есть в дескрипторе USB это прописать, конечно, можно, но внутренности контроллера это не изменит, и реальный адрес точки просто будет отличаться от видимого снаружи. Что, естественно, повысит риск ошибок, поэтому в эту сторону извращаться не будем.
Стоит отметить, что двойная буферизация бывает не только у изохронных точек, но и у bulk, причем включается и работает она иначе. Если изохронные точки включают буферизацию автоматически, просто потому что не умеют по-другому, то для соответствующей настройки bulk приходится использовать специальный бит USB_EP_KIND, который нужно установить вместе с собственно настройкой типа точки.
Сама по себе буферизация означает, что если раньше одной точке соответствовал один буфер на передачу и один на прием, то теперь оба буфера будут работать либо на передачу, либо на прием, причем работать они будут только вместе. Как результат, настройка буферизованной точки сильно отличается от обычной, ведь нужно настроить не один буфер, а два. Поэтому не будем лепить лишние условия в обычную инициализацию, а создадим на ее основе отдельную функцию usb_ep_init_double().
Прием и передача пакетов отличается не так сильно, хотя и отняла гораздо больше времени сначала на попытки понять как же она должна работать по логике ST, потом на подгонку заклинания из интернета чтобы все-таки заработало. Как говорилось раньше, если для обычной точки два буфера независимы и отличаются направлением обмена, то для буферизованной они одинаковы и отличаются только смещением. Так что немножко изменим функции usb_ep_write и usb_ep_read чтобы они принимали не номер точки, а номер смещения. То есть если раньше эти функции предполагали существование восьми сдвоенных точек, то теперь — 16 одинарных. Соответственно, номер новой «полуточки» на запись равен всего лишь номеру обычной, умноженному на два, а для usb_ep_read надо еще добавить единицу (см. распределение буферов в PMA). Собственно, это и делается инлайн-функциями usb_ep_write и usb_ep_read для обычных точек. А вот логику буферизованных рассмотрим чуть подробнее.
Согласно документации, один буфер такой точки доступен для железа, второй для софта. Потом они переключаются и снова не мешают друг другу. Для OUT точки флагом со стороны железа является бит USB_EP_DTOG_RX, который нужно прочитать чтобы понять в какой из буферов только что закончилась запись и откуда соответственно софт может читать. Когда он прочитал свой буфер, нужно дернуть бит USB_EP_DTOG_TX, что собственно переключит буферы. Не уверен, что подразумевалось именно это, но оно, по крайней мере, работает.
Симметричная ситуация должны была быть с IN точками. Но на практике оказалось, что и проверять, и дергать надо USB_EP_DTOG_RX. Почему не TX я так и не понял… Спасибо пользователю kuzulis за ссылку на github.com/dmitrystu/libusb_stm32/edit/master/src/usbd_stm32f103_devfs.c
За счет инлайна функций особого оверхеда не добавилось, не считая инициализации. Но ее можно при желании выкинуть флагами линковщика. А можно и не выкидывать: не так много места занимает, да и вызывается только при инициализации. Это вам не HAL, где функции мало того что тяжелые, но и вызывают друг друга постоянно.
В результате конечные точки научились работать и в буферизованном режиме… если не дышать на них слишком сильно.
Для пользователя разница невелика: вместо usb_ep_init использовать usb_ep_init_double, а вместо usb_ep_write и usb_ep_read — соответственно usb_ep_write_double и usb_ep_read_double.
Устройство AudioDevice
А вот теперь, когда с техническими граблями разобрались, перейдем к самому интересному — настройке аудиоустройства.
Согласно стандарту USB аудиоустройство представляет собой набор сущностей (entity), соединенных друг с другом в некую топологию, по которой и проходит аудиосигнал. Каждая сущность имеет свой уникальный номер (bTerminalID, он же UnitID), по которому к ней могут подключаться другие сущности или конечные точки, по нему же обращается хост, если хочет изменить какие-то параметры. И он же считается единственным выходом данной сущности. А вот входов может вообще не быть (если это входной терминал), а может быть и больше одного (bSourceID). Собственно записью в массив bSourceID номеров сущностей, от которых текущая получает аудиосигнал, мы и описываем всю топологию, которая в результате может получиться весьма резвесистой. Для примера приведу топологию покупной USB-звуковой карты (цифрами показаны bTerminalID / UnitID):
Мы же будем делать нечто более простое (заготовку брал отсюда):
Здесь видно две независимых ветки распространения сигнала: либо от USB через «фичу» к «динамику», либо из «микрофона» через другую «фичу» к USB. Микрофон и динамик не просто так взяты в кавычки: на моей отладочной плате их нет, поэтому вместо собственно звука будем пользоваться кнопками и светодиодами. Впрочем, ничего нового. «Фичи» в моем случае ничего не делают и добавлены скорее для красоты.
Сразу же стоит уточнить, что сигнал в данной модели считается составленным из одного или более логических каналов. То есть если, например, я поменяю монофонический динамик на стереофонический, сама топология останется неизменной, изменится только формат сигнала.
Глубоко в различия сортов «фич» и прочих сущностей я не копал, но пересказать кусок документации не побрезгую.
1. Входной терминал (Input Terminal)
Как следует из названия, именно через него в аудиоустройство попадает звуковой сигнал. Это может быть USB, может быть микрофон обыкновенный, микрофон гарнитурный, даже микрофонный массив.
2. Выходной терминал (Output Terminal)
Тоже вполне очевидно — то, через что звук покидает наше устройство. Это может быть все тот же USB, может быть динамик, гарнитура, динамик в мониторе, динамики различных частот и куча других устройств.
3. Микшер (Mixer Unit)
Берет несколько входных сигналов, усиливает каждый на заданную величину и складывает то, что получилось, в выходной канал. При желании можно задать усиление в ноль раз, что сведет его к следующей сущности.
4. Селектор (Selector Unit)
Берет несколько входных сигналов и перенаправляет один из них на выход.
5. Фильтр (Feature Unit)
Берет единственный входной сигнал, меняет параметры звука (громкость, тембр и т.п.) и выдает на выход. Естественно, все эти параметры одинаковым способом прикладываются ко всему сигналу, без взаимодействия логических каналов внутри него
6. Processing Unit
А вот эта штука уже позволяет проводить манипуляции над отдельными логическими каналами внутри каждого входного. Более того, позволяет сделать количество логических каналов в выходном не равным количеству во входных.
7. Extension Unit
Весь набор нестандартных сущностей, чтобы больной фантазии производителей оборудования было раздолье. Соответственно, и поведение, и настройки будут зависеть от этой самой фантазии.
Некоторые сущности обладают параметрами вроде коэффициента усиления или номера канала, на которые хост может повлиять при помощи setFeature / getFeature запросов по номеру сущности. Но тут, если честно, я не слишком понимаю как это вообще проверить. Наверное, нужен какой-то спецсофт, которого у меня нет. Ну да и ладно, все равно я в это полез только чтобы все типы точек проверить… на свою голову…
Грабли в дескрипторе
В отличие от предыдущих USB-устройств, здесь дескриптор сложный, многоуровневый и склонный пугать виндоусы до BSOD’а. Как мы видели выше, топология у аутиоустройства может быть весьма сложной и развесистой. Под ее описание выделяется целый интерфейс. Очевидно, endpoint’ов он содержать не будет, зато будет содержать список дескрипторов сущностей и описаний к чему подключены их входы. Тут особо описывать смысла не вижу, проще посмотреть в коде и документации. Отмечу только главные грабли: здесь описывается какие интерфейсы с соответствующими конечными точками относятся именно к данному устройству. Скажем, если вы захотите изменить мою конфигурацию и убрать оттуда динамик, придется не просто удалить половину сущностей (слава макросам, хотя бы с подсчетом длины дескриптора проблемы не будет), но и уменьшить поле bInCollection до 1, после чего из следующего за ним массива bInterfaceNr убрать номер лишнего интерфейса.
Дальше находятся интерфейсы, отвечающие за обмен данными. В моем случае 1-й интерфейс отвечает за микрофон, а 2-й за динамик. Здесь стоит обратить внимание в первую очередь на два варианта каждого из этих интерфейсов. Один с bAlternateSetting равным 0, второй с 1. Они отличаются наличием конечной точки. То есть если наше устройство в данный момент не используется, хост просто переключается на тот альтернативный интерфейс, который конечной точкой не оборудован, и уже не тратит на нее пропускную способность шины.
Вторая особенность интерфейсов данных — это формат аудиосигнала. В соответствующем дескрипторе задается тип кодирования, количество каналов, разрешение и частота дискретизации (которая задается 24-битным числом). Вариантов кодирования предусмотрено довольно много, но мы будем использовать самый простой — PCM. По сути это просто последовательность значений мгновенной величины сигнала без какого-либо кодирования, причем величина считается целым числом со знаком. Разрешение сигнала задается в двух местах (зачем — непонятно): в поле bSubFrameSize указывается количество байтов, а в bBitResolution — количество битов. Вероятно, можно указать, что диапазон нашей звуковой карты не доходит до полного диапазона типа данных, скажем, int16_t и составляет всего 10 бит.
Ну и наконец дескриптор собственно конечной точки. Он тоже немного отличается от обычных, поскольку предусматривает во-первых несколько вариантов синхронизации, а во-вторых, номер сущности, с которой эта точка ассоциирована (bTerminalLink). Варианты синхронизации прописываются старшими битами прямо в тип конечной точки (именно поэтому изохронная точка вынесена в ветку default в функции инициализации), но их подробностями я не занимался, поэтому ничего интересного рассказать не смогу. Вместо синхронизации мы воспользуемся обычным таймером контроллера, который будет генерировать прерывания с примерно нужной частотой.
Ах да, чуть не забыл упомянуть очередную пачку BSOD’ов при тестировании неправильных дескрипторов. Еще раз напоминаю: количество интерфейсов данных должно соответствовать числу bInCollection, а их номера — следующему за ним массиву!
Логика работы устройства
А вот с тестированием возникла небольшая проблема: я не нашел простого способа перенаправить сигнал с микрофона на stdin какой-нибудь программы. Вроде бы раньше это делалось просто чтением /dev/dsp, но сейчас что-то поломалось. Впрочем, ничего критичного, ведь есть всякие библиотеки взаимодействия с мультимедией — SDL, SFLM и другие. Собственно на SFML я и написал простенькую утилиту для чтения с микрофона и, если надо, визуализации сигнала.
Особое внимание уделю ограничениям нашего аудиоустройства: насколько я понял, изохронный запрос IN отправляется один раз в миллисекунду (а вот OUT’ов может быть много), что ограничивает частоту дискретизации. Допустим, размер конечной точки у нас 64 байта (учитывая буферизацию, в памяти она занимает 128 байт, но хост об этом не знает), разрешение 16 бит, то есть за раз можно отправить 32 отсчета. Учитывая интервал в 1 мс получаем теоретический предел 32 кГц для одного канала. Самый простой способ это обойти — увеличить размер конечной точки. Но тут надо помнить, что размер общего буфера PMA у нас всего 512 байт. Минус таблица распределения точек, минус ep0, получаем максимум 440 байт, то есть 220 байт на единственную точку с учетом буферизации. И это теоретический предел.
Но то, что хост может за один фрейм послать несколько OUT запросов наводит на мысли, что и устройство тоже так может. Осталось понять как. Возможно, это решается грамотной настройкой синхронизации. Но для меня этот вопрос интереса уже не представляет: изохронные точки работают, буферизованные точки работают, аудиоустройство работает — задача выполнена.
Основы USB устройства
USB-устройство представляет собой очень сложную вещь, как описано в официальной документации USB (доступной на http://www.usb.org). К счастью, ядро Linux предоставляет подсистему, называемую ядром USB, чтобы справляться с большинством сложностей. В этой главе описывается взаимодействие между драйвером и USB ядром. Рисунок 13-2 показывает, как USB-устройства состоят из конфигураций, интерфейсов и оконечных точек и как USB драйверы связаны с интерфейсами USB, а не всего устройства USB.
Рисунок 13-2. Обзор USB устройства
Оконечные точки
Оконечная точка USB может быть одной из четырёх типов, которые описывают, каким образом передаются данные:
Управляющие оконечные точки используются для обеспечения доступа к различным частям устройства USB. Они широко используются для настройки устройства, получения информации об устройстве, посылке команд в устройство, или получения статусных сообщений устройства. Эти оконечные точки, как правило, малы по размеру. Каждое устройство имеет управляющую оконечную точку, называемую «endpoint 0», которая используется ядром USB для настройки устройства во время подключения. Эти передачи гарантируются протоколом USB, чтобы всегда иметь достаточную зарезервированную пропускную способность шины для их передачи на устройство.
Оконечные точки прерывания передают небольшие объёмы данных с фиксированной частотой каждый раз, когда USB хост запрашивает устройство для передачи данных. Эти оконечные точки являются основным транспортным методом для USB клавиатур и мышей. Они также часто используются для передачи данных на USB устройства для управления устройством, но обычно не используются для передачи больших объёмов данных. Эти передачи гарантируются протоколом USB, чтобы всегда иметь достаточную зарезервированную пропускную способность для их передачи.
Поточные оконечные точки передают большие объёмы данных. Эти оконечные точки, как правило, значительно больше (они могут содержать больше символов за один раз), чем оконечные точки прерывания. Они являются обычными для устройств, которые должны передавать любые данные, которые должны пройти через шину, без потери данных. Этим передачам протокол USB не гарантирует выполнения в определённые сроки. Если на шине нет достаточного места, чтобы отправить целый пакет BULK, он распадается на несколько передач в или из устройства. Эти оконечные точки общеприняты на принтерах, устройствах хранения и сетевых устройствах.
Изохронные оконечные точки также передают большие объёмы данных, но этим данным не всегда гарантирована доставка. Эти оконечные точки используются в устройствах, которые могут обрабатывать потери данных, и больше полагаются на сохранение постоянного потока поступающих данных. При сборе данных в реальном времени, таком, как аудио- и видео-устройства, почти всегда используются такие оконечные точки.
Управляющие и поточные оконечные точки используются для асинхронной передачи данных, когда драйвер решает их использовать. Оконечные точки прерывания и изохронные точки являются периодическими. Это означает, что эти оконечные точки созданы для передачи данных непрерывно за фиксированное время, что приводит к тому, что их пропускная способность защищена ядром USB.
Если эта оконечная точка имеет тип прерывания, это значение является установкой интервала для оконечной точки, то есть времени между запросами прерывания для оконечной точки. Это значение представляется в миллисекундах.
Поля этой структуры не имеют «традиционной» для ядра Linux схемы именования. Это происходит потому, что эти поля напрямую соотносятся с именами полей в спецификации USB. Программисты ядра USB посчитали, что было более важно использовать специфицированные имена, чтобы избежать путаницы при чтении спецификации, чем иметь имена переменных, которые выглядят знакомо для программистов Linux.
Интерфейсы
USB интерфейсы могут иметь дополнительные параметры настройки, которые представляют собой разные наборы параметров интерфейса. Первоначальное состояние интерфейса находится в первой настройке под номером 0. Другие параметры могут быть использованы, чтобы управлять отдельными оконечными точками по-разному, например, резервировать разные размеры полосы пропускания USB устройства. Каждое устройство с изохронной оконечной точкой использует дополнительные параметры на том же самом интерфейсе.
struct usb_host_interface *altsetting
struct usb_host_interface *cur_altsetting
Если драйвер USB, связанный с этим интерфейсом, использует старший номер USB, эта переменная содержит младший номер, присвоенный интерфейсу USB ядром. Это справедливо только после успешного вызова usb_register_dev (описываемого далее в этой главе).
В структуре struct usb_interface есть и другие поля, но USB драйверам знания о них не требуются.
Конфигурации
Так что подводя итоги, USB устройства являются довольно сложными и состоят из множества разных логических единиц. Отношения между этими частями можно описать просто следующим образом:
• Устройство обычно имеют одну или более конфигураций.
• Конфигурации часто имеют один или несколько интерфейсов.
• Интерфейсы обычно имеет один или несколько наборов параметров.
• Интерфейсы имеют ноль или более оконечных точек.
Недостаточно ресурсов USB контроллера: причины, что делать?
При подключении внешнего устройства к порту USB система может неожиданно выбросить ошибку «Недостаточно ресурсов USB-контроллера». Во многих случаях ее можно наблюдать при подключении к портам USB 3.0.
Причины ошибки
Как оказалось, ошибка редко связана с пропускной способностью или питанием устройства. Скорее всего, она возникает из-за ограничения конечной точки.
Что такое конечная точка (endpoint) USB?
Это основная форма взаимодействия по USB. Конечная точка передает данные только в одном направлении (от компьютера к устройству или наоборот). Вот почему в интерфейсе используется две конечные точки — одна на прием (IN), вторая на передачу (OUT).
При подключении USB-устройства компьютер создает несколько конечных точек (каналов связи, идущих к оборудованию или от него). Обычно флеш-накопителям достаточно 3-4 конечных точек входа и выхода, тогда как гарнитуры и прочие устройства могут использовать до 10.
Следуя из указанного, есть три основные причины, которые вызывают сообщение «Недостаточно ресурсов USB-контроллера»:
Переключение некоторых устройств на USB 2.0
Если ошибка возникла при подключении к порту USB 3.0, попробуйте обойти ее путем переключения некоторых устройств на классический порт 2.0. Если пытаетесь подключить оборудование, которое использует много конечных точек (VR или 7.1 гарнитура), может возникнуть соблазн использовать концентратор USB 3.0, чтобы воспользоваться всеми преимуществами, поставляющими с новым протоком передачи данных.
Но концентраторы нужно использовать только в ограниченной степени, поскольку довольно быстро превысите лимит в 16 конечных точек, например, при подключении гарнитур VR + 7.1. Но можно легко обойти эту проблему, подключением одного из устройств к обычному порту USB 2.0.
Оставьте оборудование, от которого нужна более высокая скорость передачи данных, на USB-порту 3.0, остальное переключите на 2.0. Таким образом, можно исправить ошибку «Недостаточно ресурсов USB-контроллера».
Использование USB-концентратора с собственным источником питанием
Если сталкиваетесь с проблемой на ноутбуке, скорее всего, она возникает из-за общего количества энергии, извлекаемой из USB-портов,
Если не можете ограничить количество внешних устройств, получающих питание от USB-портов, попробуйте устранить ошибку путем подключения USB-концентратора с собственным источником питания.
Переустановка драйверов
Проблема может вызвана неисправным драйвером контроллера. Для переустановки выполните следующие шаги.
Разверните вкладку контроллеры USB, щелкните правой кнопкой мыши на универсальном хост-контроллере и выберите «Удалить». Если их несколько, удалите все.
Перезагрузите компьютер. В ходе следующей загрузки Windows автоматически переустановит отсутствующие драйвера.
Отключение опции XHCI в настройках BIOS
Если все еще сталкиваетесь с ошибкой «Недостаточно ресурсов USB-контроллера», попробуйте отключить Intel xHCI Mode в настройках BIOS. Это приведет к тому, что все USB-порты 3.0 будут понижены до уровня 2.0.
На вкладке Дополнительно (Advanced) найдите опцию USB EHCI debug в разделе Device Options. Включение этой опции отключит контроллер xHCI. Сохраните изменения, и загрузите компьютер.
Миландр
Ключевым подразделением нашей компании
является Центр Проектирования интегральных микросхем
Часовой пояс: UTC+03:00
USB endpoint
| Начать новую тему Ответить на тему | Страница 1 из 2 | [ 23 сообщения ] | На страницу 1 2 » |
|
| Автор | Сообщение | |||||
|---|---|---|---|---|---|---|
| newstep | ||||||
Зарегистрирован: 2015-авг-28 11:25 | ||||||
Зарегистрирован: 2013-фев-16 18:20 | ||||||
Зарегистрирован: 2015-авг-28 11:25 |
| |||||
Зарегистрирован: 2015-авг-28 11:25 | ||||||
Зарегистрирован: 2011-авг-21 18:55 | ||||||
Зарегистрирован: 2015-авг-28 11:25 |
| |||||
Зарегистрирован: 2010-июл-08 08:50 | ||||||
Зарегистрирован: 2010-июл-08 08:50 |
| |||||
Зарегистрирован: 2015-авг-28 11:25 |
| |||||
Зарегистрирован: 2010-июл-08 08:50 |
| |||||
Зарегистрирован: 2015-авг-28 11:25 | ||||||
Зарегистрирован: 2010-июл-08 08:50 |
| |||||
Зарегистрирован: 2015-авг-28 11:25 |
| |||||
| Вернуться к началу | ||||||
 | ||||||
| Начать новую тему Ответить на тему | Страница 1 из 2 | [ 23 сообщения ] | На страницу 1 2 » |
Часовой пояс: UTC+03:00
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 6 гостей