Usb enumeration delay что это
When the EP0 size (bMaxPacketSize0 in descriptor) is 16 or 8 in Linux there is a delay of about 7s before enumeration and enumeration fails on Windows 10, device manages says that the device descriptor is invalid.
I'm testing the cdcacm example in the stm32-h103 folder and a similar program in a stm32f105 device.
The text was updated successfully, but these errors were encountered:
FabianInostroza commented Sep 20, 2018
I don't have OSX to test.
karlp commented Sep 24, 2018
Same thing happens on an F4 device with dwc_otg.
zyp commented Sep 25, 2018
I've looked into this a bit and to me it seems like it's caused by deliberate non-specified behavior on the host, designed to deal with certain devices that also doesn't comply with the spec.
Here's a trace I did last night with MPS set to 16:
First capture is with macos. Here we see the host is first requesting the first 8 bytes, learns the MPS from it and then correctly reads the whole descriptor split into 16 byte chunks.
Second capture is with linux. Here we see linux sends a SETUP packet for a 64-byte read and device replies with the first 16-byte chunk. While device is waiting to send the second chunk, host believes the data stage is over and tries to send the status OUT packet, so neither gets accepted by the other side and the control request times out after five seconds. Even though the request partially timed out, linux appears to have learned the MPS from it and subsequently enumerates the device correctly.
Somebody in the IRC channel linked this article, which suggests that Windows is doing more or less the same and offers some insight into why. I'll try to make a trace of enumeration on Windows tonight to see if I can figure out why it fails.
I suspect that this issue might have been exacerbated by the flow control improvements that got merged recently. Before the change, I guess that the status OUT packet would have been accepted even when it was unexpected.
I'm not sure what we should do about this issue. If it was only about the timeout, it would have been fair enough to say that you'll have to live with it when you insist on using a less common MPS, but since it makes enumeration fail completely on Windows, we should probably do something.
The cleanest solution from an outside perspective would be just accepting the status OUT stage after the first chunk, but this is something which we would only want to do for this particular request and that introduces a bunch of special casing in the control state machine.
The simplest workaround from a code perspective would be to always only send one chunk when the host requests 64 bytes, since hosts appears to request the exact 18 bytes when they want the whole thing. I.e. if the host requests 64 bytes and MPS is 16, we can just assume the host wanted 16 bytes. This breaks if the assumption is untrue though. To get around that, we could do this only for the first device descriptor request after each reset.
Итак, нам осталось разобраться с процессом обработки стандартных запросов USB и с дескрипторами. Давайте сначала разберемся с теорией, а потом подробно разберем пример обработки конкретного запроса.
Обработка запросов.
Процесс обработки запроса состоит из трех фаз (SETUP, DATA, STATUS), причем фаза DATA является опциональной.
Как мы помним из предыдущей статьи, для передачи запросов хост использует специальный TOKEN пакет — TOKEN SETUP. Собственно говоря, первая фаза состоит из того, что хост посылает TOKEN SETUP, затем посылает пакет данных (8 байт) который содержит запрос. Устройство подтверждает получение запроса ACK пакетом. Структуру запроса мы рассмотрим ниже, пока перейдем к следующей фазе – фазе обмена данными.
Дело в том, что некоторые типы запросов предполагают передачу дополнительных данных, как от хоста к устройству (передача дополнительных параметров запроса) так и от устройства к хосту (получение хостом ответа на запрос). Этот обмен и составляет фазу обмена данными.
Хост, отравив запрос в SETUP фазе, знает тип запроса и, соответственно, знает: нужна ли для данного типа запроса фаза обмена данными и в какую сторону будет происходить обмен.
Если запрос предполагает передачу дополнительных параметров — хост отправляет TOKEN OUT и пакет данных содержащий дополнительные параметры запроса. Устройство подтверждает получение пакета данных, после чего хост может послать следующий пакет данных и т. д.
Соответственно, если запрос предполагает получение ответа от устройства, хост посылает TOKEN IN и ожидает пакет данных от устройства.
Последняя (STATUS) фаза нужна для подтверждения корректности обработки всего запроса. На данной фазе устройство или хост просто посылает пакет данных нулевой длины, что свидетельствует об успешной обработке запроса на логическом уровне. Если запрос предполагал получение ответа от устройства – то данный пакет посылает хост, подтверждая, что ответ получен/обработан. В другом случае – пакет нулевой длины шлет устройство, подтверждая, что запрос (запрос и дополнительные параметры) получены и обработаны.
Если что-то пошло не так (например, мы получили запрос который не умеем обрабатывать), устройство может послать STALL пакет, что свидетельствует об ошибке на логическом уровне. Но хост расценит это как фатальную ошибку т. к. стандартные запросы должны всегда корректно обрабатывается всеми USB устройствами.
Теперь заглянем «внутрь» запроса (8 байт данных полученных устройством в SETUP фазе). Запрос состоит из следующих полей:
bmRequestType — 1 байт
bRequest – 1 байт
wValue – 2 байта, WORD
wIndex – 2 байта, WORD
wLength – 2 байта, WORD
bmRequestType – битовое поле, которое содержит характеристики запроса:
Бит 7: Направление передачи данных в DATA фазе:
0 = от хоста к устройству
1 = от устройства к хосту
Биты 6. 5: Тип запроса
0 = стандартный запрос USB
1 = стандартный запрос для определенного класса устройств USB
2 = пользовательский запрос
3 = зарезервировано
Биты 4. 0: Кому адресован запрос
0 = устройству
1 = интерфейсу
2 = конечной точке
3 = другое
4. 31 = зарезервировано
bRequest – уникальный код запроса (например, 0 = GET_STATUS, 5 = SET_ADDRESS, 6 = GET_DESCRIPTOR и т. д.)
Здесь следует пояснить, зачем нужны биты 4..0 поля bmRequestType. Например, для получения статуса хост посылает запрос GET_STATUS (bRequest = 0). Значение бит 4. 0 поля bmRequestType определяет, статус чего именно хочет получить хост: 0 – статус устройства, 1 – статус интерфейса, 2 – статус контрольной точки и т. д.). Таким образом, «тип запроса» определяется битами 4..0 поля bmRequestType и полем bRequest.
wValue – данное поле может использоваться для передачи параметров запроса. Например, для запроса SET_ADDRESS данное поле содержит адрес, который нужно присвоить устройству. Если параметры запроса не помещаются в 2 байта wValue, то хост их передает в DATA фазе.
wIndex – значение данного поля зависит от типа запроса. Например, для запроса GET_STATUS к конечной точке, данное поле содержит индекс конечной точки, статус которой хост хочет получить.
wLength – данное поле содержит размер данных, которые будут переданы хостом в DATA фазе либо которые хост ожидает получить в DATA фазе.
Для примера, рассмотрим алгоритм обработки запроса GET_DESCRIPTOR.
1. Хост посылает устройству запрос:
bmRequestType = 0x80
bRequest = 6 (GET_DESCRIPTOR)
wValue = 0x100 (тип дескриптора, который хост хочет получить, в данном случае дескриптор устройства)
wIndex = 0 (в данном случае параметр не используется)
wLength = 18 (в ответ хост хочет получить 18 байт)
Из запроса видно, что хост хочет получить дескриптор нашего устройства и что за SETUP фазой предполагается DATA фаза «от устройства к хосту».
2. Устройство посылает хосту 18 байт дескриптора (DATA фаза).
3. Хост подтверждает успешное завершение обработки запроса, отправив устройству пакет данных нулевой длины (STATUS фаза).
Будем считать, что с обработкой запросов мы разобрались. Все запросы подробно разбирать мы не будем, т. к. это очень объемный материал. Детально все типы стандартных запросов описаны в разделе 9.3 официальной спецификации.
Касательно нашего CDC устройства — помимо стандартных запросов USB, для нашего класса устройств предусмотрено несколько дополнительных запросов (SET_LINE_CODING, GET_LINE_CODING, SET_CONTROL_LINE_STATE). Эти запросы предназначены для установки параметров (Baudrate, Stop Bits, Parity, Data bits) нашего виртуального COM-порта. В нашей реализации эти параметры нам не нужны, но обрабатывать эти запросы мы обязаны, поэтому реализуем обработку в виде «заглушек».
Дескрипторы
Теперь поговорим о дескрипторах.
Стандартом определены следующие типы дескрипторов:
— Дескрипторы устройства
— Дескрипторы конфигурации
— Дескрипторы интерфейса
— Дескрипторы конечной точки
— Строковые дескрипторы
Дескриптор устройства всегда один, он содержит базовую информацию об устройстве (код производителя, код устройства, класс устройства и т. д.). Мы позже детально разберем данный дескриптор на примере нашего устройства.
Дескрипторы конфигурации описывают конфигурации нашего устройства.
Здесь остановимся немного подробнее. Дело в том, что устройство может поддерживать несколько альтернативных конфигураций. Например, в конфигурации «1» устройство питается от интерфейса USB, а в конфигурации «2» – от внешнего источника. Или в конфигурации «1» устройство для обмена данными с хостом использует дополнительные контрольные точки типа bulk, а в конфигурации «2» – весь обмен идет через «нулевую конечную точку».
Для каждой из конфигураций устройство хранит свой дескриптор конфигурации. Хост получает по запросу дескрипторы всех конфигураций и выбирает одну из возможных конфигураций (логика выбора «рабочей» конфигурации из возможных заложена в драйвере устройства). После этого, хост назначает устройству номер текущей конфигурации (отправив стандартный запрос SET_CONFIGURATION) и дальнейшая работа устройства происходит в соответствии с выбранной хостом конфигурацией.
Для каждой конфигурации устройства определен один или несколько «интерфейсов». Интерфейс определяет, какие контрольные точки будут использоваться для обмена данными между хостом и устройством. Эта информация и есть «дескриптор интерфейса».
Информация о каждой конечной точке интерфейса называется «дескриптор конечной точки». Для каждой конечной точки дескриптор описывает тип конечной точки, ее параметры (такие как максимальный размер буфера обмена и т. д.)
Каждый дескриптор конфигурации содержит в себе дескрипторы интерфейса, а каждый дескриптор интерфейса содержит дескрипторы конечных точек.
Строковые дескрипторы опциональны, они позволяют получить хосту, в виде UNICODE строки, название устройства, название производителя устройства, серийный номер устройства.
Для примера, рассмотрим «дескриптор устройства», пример которого уже приводился в одной из статей.
Итак, в дескрипторе содержится следующая ключевая информация:
1. Устройство поддерживает версию стандарта 2.0
2. Устройство относится к классу CDC
3. Код производителя 0x03EB (Atmel)
4. Код продукта (в рамках производителя) 0x6127
5. Код ревизии устройства 0x0110
6. Устройство поддерживает одну конфигурацию
Компания Atmel позволяет использовать свой код производителя (VID) при создании USB устройств на базе ее продукции, правда с небольшими оговорками. Остальные параметры (Код продукта, Код ревизии устройства) выбраны «с потолка» :)
Комбинация VID/PID используется ОС для идентификации устройства и поиска «подходящего» драйвера. В некоторых случаях, для поиска драйвера используется информация о классе устройства (например, для HID и MSD устройств).
Описывать «побитно» все дескрипторы мы не будем, эта информация подробно описана в разделе 9.6 спецификации.
Теперь фрагмент кода — реализации данного уровня логики USB.
Эта статья завершает цикл.
Как и обещал – выкладываю исходные коды примера реализации (не стоит забывать, что это лишь пример, реализация очень упрощена). Для демонстрации работы стека в main.c реализована простая эхо-отвечалка, все данные полученные от ПК устройство отправляет обратно :)
Вместе с исходниками лежит файл USBCDC.inf – этот файл нужен ОС Windows для того, чтобы связать VID/PID нашего устройства со стандартным драйвером виртуального USB COM-порта (usbser.sys)
В данном цикле статей будет рассмотрен под разными углами интерфейс USB (USB 2.0) Попробуем разобраться, как он работает и закрепить полученные знания практически. «Копать» мы будем достаточно глубоко, не коснемся только физического уровня передачи данных (вернее коснемся вскользь). Физический уровень возьмет на себя соответствующий периферийный модуль МК.
Все примеры, которые я буду приводить, будут привязаны к линейке МК AT91SAM7S. Так как эта линейка МК не очень популярна в Сообществе, я постараюсь акцентировать внимание на работе самого интерфейса и по минимуму затрону специфические для этого МК особенности реализации.
Примеры будут базироваться на «глубоко модернизированном» и достаточно низкоуровневом примере реализации USB от Atmel. Готовые библиотеки рассматривать не будем. Не по тому, что это плохо, просто наша цель разобраться — как работает интерфейс.
В качестве практического задания – давайте поставим целью создать CDC-ACM устройство. На практике, за сокращением CDC-ACM стоит «обыкновенный» виртуальный СОМ-порт. С терминологией разберемся позже, пока скажем так: на уровне ОС устройство будет автоматически распознаваться как последовательный интерфейс (COM-порт в Win, /dev/ttyS в Linux и т. д.).
Общие сведения.
USB –последовательный интерфейс, используемый для подключения периферийных устройств. Соответственно, существуют понятие «главное устройство» (хост, он управляет обменом данными через интерфейс, выступает инициатором обмена) и «периферийное устройство» (клиент, в процессе обмена данными «подчиняется» хосту).
Логика работы у хоста и клиента принципиально отличается, соответственно нельзя напрямую соединять устройства «хост – хост» и «клиент – клиент».
Есть специальные устройства – хабы, которые подключаются в качестве клиента к одному хосту и, в тоже время, выступают хостом для других периферийных устройств. Хабы используют для «разветвления» шины USB.
Полагаю, изложенные факты общеизвестны, двигаемся далее.
Физический уровень.
Физически интерфейс USB использует 4 провода: «земля (GND)», «+5В (VBUS)», «D+», «D-». Первые два могут использоваться для питания периферийного устройства (максимальный ток 500 мА). Два последних служат для передачи данных (обозначение D+ и D- условны, с электрическими потенциалами это никак не связанно).
Как я уже сказал, физическую передачу данных через D+ и D- нам обеспечит USB модуль МК.
Нам нужно знать следующее:
1. Питание на периферийное устройство подается сразу после подключения к USB разъему хоста. Сам разъем сконструирован таким образом, что первыми входят в «зацепление» контакты «GND» и «VBUS», только потом «D+» и «D-».
2. Подключение устройства к USB разъему хоста не означает, что хост сразу определит подключение нового устройства. Если не вдаваться в подробности, подключение/отключение устройства хост определяет по наличию вешней подтяжки на линиях D+ и D-. Такая формулировка очень упрощена, детально ознакомиться с вопросом можно в разделе 7.1.7.3 официальной спецификации USB 2.0.
В нашем случае, для того чтобы «заявить о себе» нужно подтянуть линию D+ посредством сопротивления 1.5 кОм к напряжению 3.3 вольта. Если мы уберем данную подтяжку – хост определит отключение устройства.
Подтяжку можно сделать постоянной (в таком случае хост будет определять подключение / отключение устройства одновременно с подключением / отключением устройства к разъему USB), либо управлять подтяжкой через ключ, дергая ногой МК (тогда наше устройство сможет самостоятельно подключатся и отключатся от хоста).
Логический уровень
На логическом уровне, обмен данными происходит через некоторые логические, виртуальные каналы внутри одного физического USB интерфейса. Такие каналы называют «Конечными точками» (EndPoints).
Конечные точки (каналы) бывают 4 видов:
Control – данный тип канала используется хостом для управления периферийным устройством. Хотя иногда данный тип канала используется для передачи данных.
Bulk — данный тип канала используется для обмена данными. Гарантирование целостности данных и гарантированная доставка данных для данного типа канала реализована «в железе». Однако скорость передачи данных по такому каналу ограничена.
Isochronous — данный тип канала в основном используется для обмена потоковыми данными. Целостность и доставка данных не контролируются, зато скорость значительно выше чем для Bulk каналов.
Interrupt – используются для реализации подобия «прерываний». Такие «прерывания» являются логическими, и никак напрямую не связанны с аппаратными прерываниями МК или прерываниями ОС.
Минимальная реализация USB устройства требует наличие всего одного Control канала (так называемая «нулевая конечная точка»). Остальные типы каналов, как и их количество определяет разработчик устройства исходя из функций устройства.
Однако, существуют некоторые стандартизированные классы USB устройств. Для каждого такого класса количество каналов, их типы и назначение установлено стандартом для данного класса устройств.
Мы стремимся создать устройство класса CDC (communications device class). Использование стандарта, в данном случае, избавит нас от необходимости писать драйвер для ОС. Как правило, драйвера для стандартных классов устройств уже «вшиты» во все популярные ОС.
Детально ознакомляться с типами каналов будем по ходу реализации нашего устройства. Забегая наперед, скажу, что в нашем устройстве будет 3 канала. Control канал для управления и два Bulk канала для предачи данных по направлению «ПК-МК» и, соответственно «МК-ПК».
Первая — вводная статья получилась слишком теоретической.
В следующей статье мы поговорим о дескрипторах USB устройства и рассмотрим процедуру инициализации устройства (запрос дескрипторов хостом и т. д.). Увы, но опять будет много теории, запаситесь терпением. :) Ничего, нам осталось «пережевать» дескрипторы устройств, после чего появятся примеры кода.
Всё многообразие коннекторов USB версии 2.0 отражено на картинке ниже. Картинка кликабельна.
Название того или иного коннектора снабжается буквенными индексами.
А — активное, питающее устройство (компьютер, хост)
B — пассивное, подключаемое устройство (принтер, сканер)
M (male) — штекер, «папа»
F (female) — гнездо, «мама»
Например: USB micro-BM— штекер (M) для подключения к пассивному устройству (B); размер micro.
Распиновка (распайка) разъема USB (гнёзда и штекеры)
Назначение проводов в USB кабеле таково:
Красный VBUS (+5V, Vcc — Voltage Collector Collector) +5 Вольт постоянного напряжения относительно GND. Максимальный ток — 500 mA
Чёрный GND — общий провод, «земля» , «минус» , 0 Вольт
Разъёмы mini и micro содержат 5 контактов:
ID — в разъёмах «B» не задействован; в разъёмах «A» замкнут с GND для поддержки функции «OTG»
Кроме прочего, в кабеле содержится (правда, не всегда) оголённый провод Shield — корпус, экран, оплётка. Этому проводу номер не присваивается.
Распиновка шнура «мыши»
У некоторых «мышей» цвета в кабеле могут отличаться от стандартных:
Оранжевый VBUS
Во избежание разночтений:
Во всех таблицах вид разъёма дан с его внешней, рабочей стороны (а не со стороны пайки!) .
Изолирующие детали разъёма отмечены светло-серым цветом, металлические части — тёмно-серым, а полости разъёма обозначены белым цветом.
Как распаять USB?
Ну, с обычными USB всё просто — берёте изображение лицевой части коннектора в зеркальном отображении и паяете.
Распайка штекеров USB mini и USB micro приведена на картинке ниже:
Также, вы можете прочесть о подключении «USB OTG» и о зарядке мобильного через USB
Разъёмы mini и micro содержат 5 контактов. В разъёмах типа «B» четвёртый контакт не используется. В разъёмах типа «A» четвёртый контакт замкнут с GND. А самому контакту GND достаётся почётное пятое место.
Если на вашем ПК не работают порты USB, а настройки Windows и обновление драйверов не помогают, возможно, контроллер был отключен в БИОСе. В этом случае вам потребуется зайти в меню конфигураций и включить все назад.
Существует множество различных версий BIOS со своими интерфейсами и тонкостями работы. Также на вашем компьютере может работать более современный комплекс — UEFI, который поддерживает полноценный графический интерфейс. В данной статье рассмотрены дистрибутивы, которые чаще всего устанавливаются на материнские платы.
Чтобы приступить к изменению конфигурации, нужно попасть в соответствующее меню. Его можно открыть во время включения персонального компьютера — до того, как началась загрузка Windows с жесткого диска.
Включите ПК. В случае, если он уже работает: перезагрузите. Дождитесь звукового сигнала спикера: короткий одиночный гудок свидетельствует о том, что все внутренние компоненты, необходимые для работы компьютера, обнаружены.
Теперь необходимо нажать горячую клавишу для вызова конфигурации. Это нужно сделать до смены экрана. Если вы не успели, и началась загрузка Windows — перезагружайтесь. Клавиши зависят от модели установленной материнской платы и версии прошивки BIOS. Узнать ее можно в руководстве пользователя, которое прилагается к материнке, на официальном сайте производителя или посмотреть на экране вашего ПК при его загрузке:
Если вы не знаете модель платы — ничего страшного. Просто попробуйте нажимать следующие клавиши: Tab , Delete , Esc , F1 , F2 , F8 , F10 , F11 , F12 . Одна из них наверняка подойдет.
Необязательно пробовать только 1 вариант за раз. Вы без проблем можете быстро нажать все кнопки из списка. Одна из них подойдет и запустит настройки БИОСа, а остальные будут проигнорированы.
Многие современные компьютеры загружаются так быстро, что попасть методом нажатия клавиш при включении не получится. Также это актуально для ноутбуков. Поэтому последние версии ОС Windows обзавелись новой особенность запуска. Покажем на примере ОС Windows 8.1.
- Проведите мышью сверху-вниз или снизу-вверх по правому краю экрана и в появившемся окне нажмите «Параметры».
- Кликните на надпись «Изменение параметров компьютера»
- Нажмите «Обновление и восстановление».
- Далее: «Восстановление».
- В разделе «Особые варианты загрузки» нажмите кнопку Перезагрузить сейчас .
Ваш компьютер или ноутбук перезагрузится в режиме настройки. После перезагрузки ПК вы также сможете выбрать вариант запуска с USB-накопителя или DVD-диска.
Phoenix AwardBIOS
Другая популярная версия, которую часто можно встретить на современных ноутбуках. Не имеет главной страницы, как AMI, но снабжен удобными тематическими закладками вверху. Перемещаться между разделами можно с помощью стрелок «влево»-«вправо», а между пунктами — с помощью «вверх» и «вниз».
Перейдите в раздел «Advanced» с помощью стрелки «Вправо». В ней найдите категорию «USB configuration». Все пункты этого раздела необходимо перевести в положение «Enabled». В некоторых версиях категория «USB configuration» может находиться во вкладке «Peripherals» а не в «Advanced».
Для завершения работы в меню нажмите F10 и подтвердите выход.
Навигация в меню
Практически все версии БИОС лишены графического интерфейса. Это значит, что вам придется работать только с помощью клавиатуры, как, например, в консоли Windows. Навигация осуществляется с помощью стрелок «вверх-вниз» и «вправо»-«влево». Чтобы открыть какой-либо раздел, используйте клавишу Enter , чтобы вернуться назад – «Escape». Небольшая памятка по используемым клавишам всегда показывается на экране.
Комплекс микропрограмм UEFI устанавливается на самых дорогих и мощных материнских платах. Он поддерживает большее количество драйверов и умеет работать с мышью. Его интерфейс будет привычен пользователям Windows и других современных операционных систем.
Каждая версия обладает собственным интерфейсом и наборами опций. Даже названия одних и тех же параметров могут различаться. Далее в статье описано несколько популярных релизов БИОС.
karlp commented Sep 24, 2018
yeah, I know it's allowed, and it's definitely a bug, I was just curious if there was any reason for it :)
FabianInostroza commented Sep 24, 2018
I pushed a sigrok/pulseview capture during enumeration to the sample repo, there are some errors due to sampling frequency and/or test leads but it shows the problem.
AMI BIOS
Очень распространенный вариант, который можно встретить на многих современных компьютерах. Главное меню разделено на 2 части: список категорий и различные действия, вроде выхода или сохранения. Вы будете работать с левой частью.
Вам необходимо перейти в раздел, который называется «Integrated Peripherals». Русскоязычной версии интерфейса нет, поэтому все команды только на английском. С помощью стрелки «Вниз» выделите данный пункт и нажмите Enter .
Здесь нужно включить (Enabled) 4 опции:
- USB EHCI controller – основной контроллер. Если на материнской плате есть порты версии 3.0, этот пункт будет разделен на 2 части: «Controller» и «Controller 2.0»;
- USB Keyboard Support – поддержка клавиатур;
- USB Mouse Support – поддержка мышек;
- Legacy USB storage detect – работа с внешними хранилищами данных: флешками, дисковыми накопителями, дисками смартфонов и цифровых фотоаппаратов.
В некоторых старых версиях присутствует всего 2 пункта «USB controller» и «Legacy USB storage support».
Когда закончите с настройками, нажмите клавишу F10 , чтобы сохранить внесенные изменения и перезагрузить компьютер.
FabianInostroza commented Sep 20, 2018
I don't have OSX to test.
karlp commented Sep 24, 2018
I confirm there's an issue. On my linux host, with stm32l1, and ep0 of 16:
AMI BIOS for Asus
Версия AMI, используемая на ноутбуках Asus. Внешне очень похожа на Phoenix — аналогичная панель закладок. Настройки USB находятся в разделе «Advanced». Перейдите туда, включите все опции и выйдите с помощью кнопки F10 .
Вопреки распространенному мнению, UEFI — не часть BIOS. Его скорее можно назвать более продвинутым, но менее популярным конкурентом. Существует большое количество различных версий, каждая со своими интерфейсами. Однако здесь управление похоже на привычную Windows, поэтому вы без труда найдете нужные опции.
FabianInostroza commented Sep 20, 2018
Настройки Windows
Если на уровне БИОСа все порты и контроллеры включены, но USB порты все-равно не работают, возможно, проблема в настройках вашей системы Windows.
Во-первых, попробуйте просто отключить и подключить устройство заново. Это вызовет проверку корректности драйверов. Если с ними что-то не так, Windows постарается переустановить их.
Если при переподключении ничего не происходит — попробуйте включить контроллер в реестре Windows. Для этого необходимо сделать следующее:
FabianInostroza commented Sep 24, 2018
From usb specs, 5.5.3 Control Transfer Packet Size Constraints
In order to determine the maximum packet size for the Default Control Pipe, the USB System Software
reads the device descriptor. The host will read the first eight bytes of the device descriptor. The device
always responds with at least these initial bytes in a single packet. After the host reads the initial part of the
device descriptor, it is guaranteed to have read this default pipe’s wMaxPacketSize field (byte 7 of the
device descriptor).
FabianInostroza commented Sep 24, 2018 •
I don't have any reason to use an EP size minor than 32. By chance I found the problem and was trying to fix it for fun and learning.
I have been analyzing the problem and found that after the first reset of the interface the host requests the device descriptor and after the device sends the first packet, the host starts sending out tokens (status stage) but the peripheral is sending NAK and the driver doesn't receive interrupt.
Then the get descriptor request times out after 5s and seems that for linux the first bytes of the descriptor is enough to assign an address and continues the enumeration, issuing other reset and requesting the descriptor again, windows seems to no tolerate this (short descriptor and timeout).
I analyzed the enumeration process of a FT232RL, a FS device with bMaxPacketSize0 = 8 and it ACKs the status stage that the driver in libopencm3 is ignoring/not receiving.
karlp commented Sep 24, 2018
I'd like to diagnose this further, I've asked a friend to see what's happening with a usb analyser.
In the meantime, "stop doing that" :) Do you have any particular reason to use 16 or 8 bytes for EP0? (Other than, "the spec allows it")
Читайте также: