А чего не 65535 сразу?

Добавлено after 1 hour 12 minutes 5 seconds:
Предлагаю ознакомиться с How does USB stack enumerate a device от программиста USB-стека Windows 7. Предполагаю, что в Windows 10, судя по логам, ничего не изменилось. То есть, более 80% всех компьютеров действуют по этому алгоритму. Вот это можно назвать обычно.

На компе-то? Да хоть мегабайт! Я при обработке изображений иной раз вообще буферы в гигабайт выделяю для вспомогательных целей…
P.S. А как игровые приставки энумерацию производят, мне глубоко наплевать! Я еще не скатился до такого маразма, чтобы игровые приставки для работы использовать.

То есть для вас одно из старейших соглашений является откровением. Уж извините, но настолько агрессивного оппонента я учить что-то не хочу.
Когда успокоитесь, почитайте про историю Си, про раздельную компиляцию и подобные вещи. В частности зачем разделяют *.c и *.h файлы, почему библиотеки обычно используются в скомпилированном виде.
В смысле? Я два раза написал одно и то же, только во второй раз чуть более развернуто.
Из личных наблюдений.
Какую еще гарантию вы хотите на неопределенное "обычно"?!
Ну, доберетесь до реализации хоста (а я очень надеюсь что доберетесь - надо же мне будет у кого-то списывать!), выставите более разумную длину.
Вообще-то я тоже не знаю почему компьютер использует такой скромный размер. Может, ограничения аппаратного модуля? Но ведь ему потом все равно принимать пакеты до 65535 байт.
А может опять для защиты от кривых устройств, чтобы не ждать полторы вечности когда выйдет таймаут. Хотя ума не приложу как именно устройство должно быть сломано оно так проявилось.

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Перестаньте с упорством барана догматы из Си переносить на С++. Мои прошивки и библиотеки сделаны на С++, именно о них шла речь.

Добавлено after 4 minutes 29 seconds:
Ну я, например, нашёл описание как делает самая массовая ОС.

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

То есть вы утверждаете что с матчастью ознакомились. Хорошо.
Так для чего введено разделение *.c/*.h и *.cpp/*.hpp? Что такое раздельная компиляция? Почему библиотеки хранятся в скомпилированном виде?
Ради чего? Чтобы проиллюстрировать никому не нужный факт.
Нет, оно конечно интересно, спасибо вам за ссылку. Подобные рассказы помогают запомнить или уложить в голове какую-то информацию. Но, как бы вам сказать... не самую ценную информацию вы решили иллюстрировать.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

У меня пока вообще никаких идей нет, зачем может понадобиться на микроконтроллере организовать хост. Мышу или клавиатуру туда воткнуть? И поддерживать эти 100500 вариантов HID? Какой же "толщины" прошивка в этом случае получится?

Предлагаю вам ознакомиться с этим самостоятельно. Применительно к С++. Я уже устал объяснять, да и оффтопик это тут.

Чтобы показать, что первый запрос Device Descriptor размером в 8 байт не имеет ничего общего со словом "обычно". Да и просто полезная информация для разработчиков устройств, чтобы понимать что же хост ждёт от устройства. Официальная спецификация не столь понятно написана, к сожалению.

Например.
Еще в общих чертах могу представить зачем подключать флешку. Хотя конкретных применений тоже с ходу не придумаю.
Или где-то натыкался на такой оригинальный способ вывода звука - через usb-host и внешнюю usb-звуковуху. Хотя у звуковух еще более мозговыносящие дескрипторы, чем у HID.

У HID все же есть структура, можно выловить какие байты отвечают за кнопки и координаты. Да банально найти usage_page(generic_desktop) + usage(keyboard) а потом считать Input'ы...
Да... все просто... всего-то пара лет работы...

То есть вместо ответа и дальнейшей конструктивной дискуссии всего лишь попытка перевести стрелки. И почему я не удивлен...

Во-первых, ваша ссылка это не доказывает. Собственно, доказать или опровергнуть размытое "обычно" довольно сложно. А главное - даром никому не надо. Если, конечно, цель не попытаться цепляться к словам, как у вас.
А во-вторых, наблюдаемое поведение нескольких операционных систем (что мной, что вами, что автором той статьи) в любом случае не может быть руководством к написанию софта. Руководством является документация.
И ничего не помешает, скажем, Eddy_Em, написать свою реализацию хоста, которая в зависимости от фазы луны будет запрашивать от 1 до 9000 байт. Ну, кроме здравого смысла.
Потому что объективной причины запрашивать именно 8 байт, а не 18, я не вижу. Кроме поддержки каких-нибудь кривулек, не умеющих следовать стандарту.
Вы имеете в виду что в ней нет требования к хосту запрашивать именно 8 байт? А зачем оно там?
А даже если бы было - зачем это устройству? Я уже два раза писал, что устройство обязано поддерживать разбиение пакета на кусочки по размеру ep0. И обязано отправлять не больше данных, чем хост хочет принять (хотя нормальные ОС все же допускают некоторые косяки).

Опыт предыдущего хода дискуссии показал, что вы не воспринимаете то что вам говорят и соответсвенно дальнейшая дискуссия не имеет перспектив. Это называют "как об стенку горохом". Обучать вас насильно мне не доставляет удовольствия. Так что, самостоятельно.

Добавлено after 6 minutes 58 seconds:
Нет, я не это имел в виду, а ровно то что написал. Не надо за меня домысливать.

Аппаратный контролер на параллельной шине. Тип завтра могу сообщить.



Так надо.



Я точно не помню - надо уточнить - но доходит до запроса от хоста описания уже рабочих конечных точек (вид и пид принимается, но не отображается в системе устройство (точнее отображается по резистору на линию данных)) после отдачи выполняется перезапрос а потом пакет по которому , согласно спецификации, устройство должно отключится.



Специфическое. Есть кое какие заготовки драйвера со стороны компа. В общем это не моя проблема - надо-б по хорошему довести железо.



Не не идут .

Добавлено after 5 minutes 6 seconds:


Там мегабайты ассемблерного текста. Вы предсталяете объем работы, а переферия в виде ISA и PCI нестандартных плат, есть даже железо подключаемое вместо дисководов, чей контролер используется как высокоскоростной асинхронный приемопередатчик. Во времена ХТ было актуально. Вот одно из изделий переводим с ISA на USB. Еще одно с ISA на Ethernet - но не идет - уже второй программист уволился не сдюжив.

Добавлено after 7 minutes 31 second:


А чем лог снимался ?


Кстати есть ограничение на время ответа после запроса по конечной точке 0 ?

Вторая попытка перевода темы замечена и проигнорирована.
Я не просто так задал вопросы. И не потому что не знаю ответы на них. Мне хочется услышать вашу версию.
Хотя бы потому что в отличие от вас мне интересно не цепляться к словам и формулировкам, а обсуждать внутреннее устройство, логику и иногда философию.

Раз видите что я вас понял неправильно, сформулируйте свою мысль по-другому. Или это очередная попытка демагогии - высказаться максимально мутно чтобы на любые возражения отвечать "вы меня неправильно поняли, я такого не говорил"?
Ну так методы борьбы с демагогами давно известны: задавать конкретные вопросы и нудно добиваться ответов.

Мне достаточно информации что это внешний модуль, спасибо. Пользоваться подобным я вряд ли буду, раньше тоже не интересовался, поэтому и подсказать именно по нему не смогу. Максимум - по устройству самого USB, к железу не привязанному.
Все равно не понимаю. Описания всех конечных точек (кроме ep0) находятся в ConfigurationDescriptor'е. Пока хост его не прочитает, он к точкам обращаться не будет.
Кстати, вы не пробовали сначала более простое устройство сделать, без дополнительных точек и с максимально короткими дескрипторами? Я там раньше кидал ссылку на свою статью по USB на stm32, если не ошибаюсь, у первого устройства, которое CustomHID, все дескрипторы меньше 32 байт, то есть не требуют разбиения по размеру буфера. Вдруг у вас проблема все-таки в нем.

Сочувствую, что тут еще сказать.
Но на счет перехода на современные системы все-таки подумайте и начальство попинайте. Рано или поздно компьютер с winXP сломается, а на новый может не найтись дров. То же с внешним железом: если оно времен DOS'а, то тоже рано или поздно сломается, придется покупать новое, а оно уже на XP не факт что заведется.

Добавлено after 7 minutes 40 seconds:

Скорее всего выводился контроллером на UART, а оттуда переходником на компьютер. По крайней мере это стандартная практика. Иногда можно еще отладчиком смотреть напрямую в памяти, но это сложнее.

Какие-то таймауты, конечно, есть, но разумные, порядка единиц - сотен секунд. Вряд ли ваш контроллер так долго готовит ответ.
Нет, VladislavS, это не из документации данные, а из опыта, можете не тратить силы на требование доказательств: искать подобную мелочь мне лень.

Segger RTT. Я недавно в этой ветке несколько проектов выкладывал, там это есть.

Запросов там много разных, таблица большая была - просто сейчас уже мало что помню, надо вспоминать - 2 года назад ковырялся. Пакеты небольшие - порядка 20-30 байт, добиваются, как требует стандарт до 64 нулями. CRC контролер считает сам. В общем первые запросы отрабатываются, в том числе передача VID и PID? потом идет запрос конечных точек - говорю 2 штука. Запрос описания конечных точек, отправляю описание и тут что-то не то, идет повторный запрос, после чего отлуп.



Можно ссылочку ?



Там ПО очень непростое сильно завязанное на тайминги к тому-же работающее с уникальными ISA и PCI платами сделанными под заказ еще в 90х Документации по устройству тех плат нет. конторы, что их делала - тоже давно нет. Исходники ПО есть - ассемблер с минимумом комментариев.



Сталкивался - что за время сброса содержимого буфера через UART на 115200 компьютер давал отлуп. А сбрасывалось-то 64 байта.

Добавлено after 2 minutes 29 seconds:


Это к AVR не прикрутить, да и вопрос со стороны компа.

Судя по вашим вопросам, вам для завершения разработки жизненно необходимо нормальную отладку заиметь. Не знаю возможно ли это на данном этапе вашей разработки, но раз уж вы в теме STM32 пишете, то рискну посоветовать их и применить. Примеров реализации USB на них в сети вагон и тележка. Вероятность получить помощь сейчас сильно выше, чем по AVR. На худой конец в том же кубе натыкать можно.

На компе любой терминал, подключаемый по IP откуда угодно. Это лог из контроллера. Лог обмена со стороны компа WireShark можно снять. Но куда полезней видеть что внутри контроллера происходит, вы же его отлаживаете, а не комп.

Но стандарт этого не требует. Наоборот, требует передавать именно столько, сколько запрошено / реальный размер.

https://habr.com/ru/post/548150/

Мое дело предупредить. Насколько я помню, ISA шину на современных материнках не разводят, а запчасти тех времен найти все сложнее.
А вы что, без буферизации сбрасываете? Ну в смысле обычно для UART создают очередь передачи, откуда в прерываниях байты передаются по одному. Соответственно и задержек особых не добавляется.

Всех приветствую, попробую оживить тему, уже убил уйму времени, но проблему решить не удаётся. Пытаюсь освоить USB на контроллерах с OTG и не могу победить отправку. Делаю следующим образом:
1. Заполняю регистр DIEPTSIZ (PKTCNT = размер посылки / макс.размер пакета с округлением вверх, XFRSIZ = общий размер посылки).
2. Разрешаю прерывание по пустому буферу (устанавливаю бит в DIEPEMPMSK)
3. Устанавливаю биты CNAK и EPENA в регистре DIEPCTL.
4. Отправляю первую порцию данных (записью в TXFIFO).

В обработчике прерываний ловлю событие TXFE, в котором дописываю в TXFIFO следующую порцию данных (размер определяю по значению DTXFSTS), вроде все нормально, НО не случается события XFRC (то есть окончания передачи). Для отладки в событии TXFE логировал значение DIEPTSIZ, почему-то поле XFRSIZ декрементируется (причем правильно, каждый раз уменьшается на макс. размер пакета), а вот PKTCNT почему-то не уменьшается. Судя по RM этот регистр, вообще говоря, читать нельзя, пока бит EPENA в регистре DIEPCTL не сброшен, возможно, PKTCNT неявно и уменьшается, но тогда вопрос, почему не приходит событие окончания передачи.

Вдруг кто-то сталкивался, прошу помощи.

UPD: с конечными точками с большим макс.размером пакета, когда всё укладывается в одну посылку, всё работает нормально (и HID, и CDC удалось завести), а когда надо слать порциями - сломалось.

Отвечу сам себе. Дело в том, что отличия в модуле USB между f0/f1 и f4 (а точнее между обычным USB и USB_OTG) более чем существенные, и если для первых после приема пакета необходимо сбросить флаг USB_EP_CTR_RX и конечная точка сразу же готова к приему, то в OTG после приема пакета ничего сбрасывать не надо, однако для точки OUT аппаратно устанавливается состояние NAK. В моем случае проблема была в том, что если в процессе нумераций прилетел неизвестный (неподдерживаемый) пакет, то я ничего не отправлял, то есть в IN не записывал, а на успешную отправку стоит callback с разрешение точки OUT. Собственно, проблема решилась принудительным сбросом NAK (разрешением конечной точки) для OUT 0.

Всем привет, продолжаю побеждать OTG, все работает, но сейчас отправка реализована так, что посылаю по одному пакету макс.размера (то есть ловлю XFRC, заново настраиваю DIEPTSIZ и DIEPTCTL и так пока данные не закончатся).

Решил переделать на более правильный вариант, который подразумевает, что в регистре DIEPTSIZ XFRSIZ нужно положить общий размер в байтах, а в PKTCNT количество пакетов (которое равно размеру, поделенному на макс. размер пакета с округлением вверх).

Собственно, какую странность обнаружил: все работает отлично, если макс. размер пакета больше 8 байтов, НО если макс. размер конечной точки данных равен 8 байтам, то посылки в 64 байта и выше не отправляются. То есть отправить 64 / 8 не получается (а 56 / 8 работает), но стоит изменить макс. размер пакета хотя бы на 16, все снова работает нормально (например, 512 байтов отправить получается).
Такое ощущение, что конечная точка с макс. размером пакета в 8 байтов ломает весь USB. Может, кто-нибудь сталкивался с таким поведением?

Что-то припоминаю, были какие-то проблемы с 8 байтами. Забил вроде, ибо никакого смысла на FS иметь точку 8 байт нет.

Согласен, приемлемо, я так и сделаю скорее всего, однако эксперименты меня всё больше удивляют, опишу их результаты, вдруг кому-то пригодится:

1. В обработчике пустого буфера FIFO решил проверить значение DTXFSTS и XFRSIZ, для чего пишу их в Uart.
2. Первая особенность: первым всегда прилетает пара <размер_буфера>/<0>. Я не понял, почему.
3. Вторая особенность: с записью этих значений в Uart проблема решилась, то есть точка с размером пакета в 8 байтов заработала, что я связываю с какой-то гонкой.

И еще один эксперимент: поменял макс.размер пакета для точки на 16 байтов, а также глубину FIFO буфера увеличил вдвое, и получил ровно такую же проблему. Появилась гипотеза, что слишком большой буфер (пока порог одинаковый - в 4 раза больше макс.размера пакета) таким образом ломает передачу.

Думаю, что просто оставлю пока как есть или откажусь от 8-байтовых точек (что, правда, не гарантирует положительный результат), но эффект интересный и непонятный.