STM32 и USB (практика)

[VladislavS]

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

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

[Eddy_Em]

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

[COKPOWEHEU]

Категоричное ОБЩЕИЗВЕСТНЫЙ ФАКТ ничего общего не имеющее с действительностью.

То есть для вас одно из старейших соглашений является откровением. Уж извините, но настолько агрессивного оппонента я учить что-то не хочу.
Когда успокоитесь, почитайте про историю Си, про раздельную компиляцию и подобные вещи. В частности зачем разделяют *.c и *.h файлы, почему библиотеки обычно используются в скомпилированном виде.

Все ошибаются, про 8 байт в ep0 вы же поправились.

В смысле? Я два раза написал одно и то же, только во второй раз чуть более развернуто.

Откуда вы это взяли? Вы готовы доказать, что 50% + 1 хостов так делают?

Из личных наблюдений.
Какую еще гарантию вы хотите на неопределенное "обычно"?!

Я бы в своей реализации хоста в случае неизвестного размера дескриптора просил бы выслать 256 байт

Ну, доберетесь до реализации хоста (а я очень надеюсь что доберетесь - надо же мне будет у кого-то списывать!), выставите более разумную длину.
Вообще-то я тоже не знаю почему компьютер использует такой скромный размер. Может, ограничения аппаратного модуля? Но ведь ему потом все равно принимать пакеты до 65535 байт.
А может опять для защиты от кривых устройств, чтобы не ждать полторы вечности когда выйдет таймаут. Хотя ума не приложу как именно устройство должно быть сломано оно так проявилось.

[VladislavS]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4011032#p4011032"]Когда успокоитесь, почитайте про историю Си[/uquote]Перестаньте с упорством барана догматы из Си переносить на С++. Мои прошивки и библиотеки сделаны на С++, именно о них шла речь.

Добавлено after 4 minutes 29 seconds:
[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4011032#p4011032"]Какую еще гарантию вы хотите на неопределенное "обычно"?![/uquote]Ну я, например, нашёл описание как делает самая массовая ОС.

[COKPOWEHEU]

Перестаньте с упорством барана догматы из Си переносить на С++.

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

Ну я, например, нашёл описание как делает самая массовая ОС.

Ради чего? Чтобы проиллюстрировать никому не нужный факт.
Нет, оно конечно интересно, спасибо вам за ссылку. Подобные рассказы помогают запомнить или уложить в голове какую-то информацию. Но, как бы вам сказать... не самую ценную информацию вы решили иллюстрировать.

[Eddy_Em]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4011032#p4011032"]Ну, доберетесь до реализации хоста (а я очень надеюсь что доберетесь - надо же мне будет у кого-то списывать!), выставите более разумную длину.[/uquote]
У меня пока вообще никаких идей нет, зачем может понадобиться на микроконтроллере организовать хост. Мышу или клавиатуру туда воткнуть? И поддерживать эти 100500 вариантов HID? Какой же "толщины" прошивка в этом случае получится?

[VladislavS]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4011058#p4011058"]Так для чего введено разделение *.c/*.h и *.cpp/*.hpp? Что такое раздельная компиляция? Почему библиотеки хранятся в скомпилированном виде?[/uquote]Предлагаю вам ознакомиться с этим самостоятельно. Применительно к С++. Я уже устал объяснять, да и оффтопик это тут.

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4011058#p4011058"]Ради чего?[/uquote]Чтобы показать, что первый запрос Device Descriptor размером в 8 байт не имеет ничего общего со словом "обычно". Да и просто полезная информация для разработчиков устройств, чтобы понимать что же хост ждёт от устройства. Официальная спецификация не столь понятно написана, к сожалению.

[COKPOWEHEU]

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4011079#p4011079"]У меня пока вообще никаких идей нет, зачем может понадобиться на микроконтроллере организовать хост.[/uquote]
Например.
Еще в общих чертах могу представить зачем подключать флешку. Хотя конкретных применений тоже с ходу не придумаю.
Или где-то натыкался на такой оригинальный способ вывода звука - через usb-host и внешнюю usb-звуковуху. Хотя у звуковух еще более мозговыносящие дескрипторы, чем у HID.
[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4011079#p4011079"]Мышу или клавиатуру туда воткнуть? И поддерживать эти 100500 вариантов HID? Какой же "толщины" прошивка в этом случае получится?[/uquote]
У HID все же есть структура, можно выловить какие байты отвечают за кнопки и координаты. Да банально найти usage_page(generic_desktop) + usage(keyboard) а потом считать Input'ы...
Да... все просто... всего-то пара лет работы...

Предлагаю вам ознакомиться с этим самостоятельно.

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

Чтобы показать, что первый запрос Device Descriptor размером в 8 байт не имеет ничего общего со словом "обычно"

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

Официальная спецификация не столь понятно написана, к сожалению.

Вы имеете в виду что в ней нет требования к хосту запрашивать именно 8 байт? А зачем оно там?
А даже если бы было - зачем это устройству? Я уже два раза писал, что устройство обязано поддерживать разбиение пакета на кусочки по размеру ep0. И обязано отправлять не больше данных, чем хост хочет принять (хотя нормальные ОС все же допускают некоторые косяки).

[VladislavS]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4011131#p4011131"]То есть вместо ответа и дальнейшей конструктивной дискуссии всего лишь попытка перевести стрелки.[/uquote]Опыт предыдущего хода дискуссии показал, что вы не воспринимаете то что вам говорят и соответсвенно дальнейшая дискуссия не имеет перспектив. Это называют "как об стенку горохом". Обучать вас насильно мне не доставляет удовольствия. Так что, самостоятельно.

Добавлено after 6 minutes 58 seconds:
[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4011131#p4011131"]

Официальная спецификация не столь понятно написана, к сожалению.

Вы имеете в виду что в ней нет требования к хосту запрашивать именно 8 байт?[/uquote]Нет, я не это имел в виду, а ровно то что написал. Не надо за меня домысливать.

[Wladimir_TS]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4008413#p4008413"]

Аппаратный с внешним контролером на шине внешней памяти данных ATMEGA128

Это предложение не понял. То есть у вас к m128 прикручен преобразователь чего-то в usb?[/uquote]

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

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4008413#p4008413"]

Задача работа в WimXP, другая система - неможно и точка.

Нет, тестирование работоспособности в экзотических системах это само собой. Но при разработке-то зачем себя мучить?[/uquote]

Так надо.

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4008413#p4008413"]

Именно начинается обмен проходят первые приветствия идет запрос конечных точек и все облом.

Что значит "запрос конечных точек"? Если ConfigurationDescriptor передался, то хоть как-то в системе опознаться должно. Хотя в winXP не уверен...[/uquote]

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

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4008413#p4008413"]Вы какое устройство вообще эмулируете?[/uquote]

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

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4008413#p4008413"]

они в XP-то идут со скрипом ибо под DOS писаны.

Виртуальная машина или DOSBox не помогают?[/uquote]

Не не идут .

Добавлено after 5 minutes 6 seconds:
[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4008565#p4008565"]Если руки не из задницы, то ничего не мешает переписать все на современный лад![/uquote]

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

Добавлено after 7 minutes 31 second:
[uquote="VladislavS",url="/forum/viewtopic.php?p=4010837#p4010837"][uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4010814#p4010814"]Обычно сначала запршивает 8 байТ[/uquote]Вот даже думать об этом не хочу. Сколько хостов - столько реализаций. Хоть один пусть спрашивает.

Добавлено after 58 minutes 27 seconds:
Насчёт 8 байт. Это вы моему ноуту расскажите. Лог обмена под спойлером.[/uquote]

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


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

[COKPOWEHEU]

[uquote="VladislavS",url="/forum/viewtopic.php?p=4011148#p4011148"]Опыт предыдущего хода дискуссии показал, что вы не воспринимаете то что вам говорят и соответсвенно дальнейшая дискуссия не имеет перспектив. Это называют "как об стенку горохом". Обучать вас насильно мне не доставляет удовольствия. Так что, самостоятельно.[/uquote]
Вторая попытка перевода темы замечена и проигнорирована.
Я не просто так задал вопросы. И не потому что не знаю ответы на них. Мне хочется услышать вашу версию.
Хотя бы потому что в отличие от вас мне интересно не цепляться к словам и формулировкам, а обсуждать внутреннее устройство, логику и иногда философию.
[uquote="VladislavS",url="/forum/viewtopic.php?p=4011148#p4011148"]Нет, я не это имел в виду, а ровно то что написал. Не надо за меня домысливать.[/uquote]
Раз видите что я вас понял неправильно, сформулируйте свою мысль по-другому. Или это очередная попытка демагогии - высказаться максимально мутно чтобы на любые возражения отвечать "вы меня неправильно поняли, я такого не говорил"?
Ну так методы борьбы с демагогами давно известны: задавать конкретные вопросы и нудно добиваться ответов.

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

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

Я точно не помню - надо уточнить - но доходит до запроса от хоста описания уже рабочих конечных точек

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

Не не идут .

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

Добавлено after 7 minutes 40 seconds:
[uquote="Wladimir_TS",url="/forum/viewtopic.php?p=4011198#p4011198"]А чем лог снимался ?[/uquote]
Скорее всего выводился контроллером на UART, а оттуда переходником на компьютер. По крайней мере это стандартная практика. Иногда можно еще отладчиком смотреть напрямую в памяти, но это сложнее.
[uquote="Wladimir_TS",url="/forum/viewtopic.php?p=4011198#p4011198"]Кстати есть ограничение на время ответа после запроса по конечной точке 0 ?[/uquote]
Какие-то таймауты, конечно, есть, но разумные, порядка единиц - сотен секунд. Вряд ли ваш контроллер так долго готовит ответ.
Нет, VladislavS, это не из документации данные, а из опыта, можете не тратить силы на требование доказательств: искать подобную мелочь мне лень.

[VladislavS]

[uquote="Wladimir_TS",url="/forum/viewtopic.php?p=4011198#p4011198"]А чем лог снимался ?[/uquote]Segger RTT. Я недавно в этой ветке несколько проектов выкладывал, там это есть.

[Wladimir_TS]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4011209#p4011209"]

Я точно не помню - надо уточнить - но доходит до запроса от хоста описания уже рабочих конечных точек

Все равно не понимаю. Описания всех конечных точек (кроме ep0) находятся в ConfigurationDescriptor'е. Пока хост его не прочитает, он к точкам обращаться не будет.[/uquote]

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

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4011209#p4011209"]Кстати, вы не пробовали сначала более простое устройство сделать, без дополнительных точек и с максимально короткими дескрипторами? Я там раньше кидал ссылку на свою статью по USB на stm32, если не ошибаюсь, у первого устройства, которое CustomHID, все дескрипторы меньше 32 байт, то есть не требуют разбиения по размеру буфера. Вдруг у вас проблема все-таки в нем.[/uquote]

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

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4011209#p4011209"]

Не не идут .

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

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

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4011209#p4011209"]Какие-то таймауты, конечно, есть, но разумные, порядка единиц - сотен секунд. Вряд ли ваш контроллер так долго готовит ответ.[/uquote]

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

Добавлено after 2 minutes 29 seconds:
[uquote="VladislavS",url="/forum/viewtopic.php?p=4011308#p4011308"][uquote="Wladimir_TS",url="/forum/viewtopic.php?p=4011198#p4011198"]А чем лог снимался ?[/uquote]Segger RTT. Я недавно в этой ветке несколько проектов выкладывал, там это есть.[/uquote]

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

[VladislavS]

[uquote="Wladimir_TS",url="/forum/viewtopic.php?p=4011309#p4011309"]Это к AVR не прикрутить,.[/uquote]Судя по вашим вопросам, вам для завершения разработки жизненно необходимо нормальную отладку заиметь. Не знаю возможно ли это на данном этапе вашей разработки, но раз уж вы в теме STM32 пишете, то рискну посоветовать их и применить. Примеров реализации USB на них в сети вагон и тележка. Вероятность получить помощь сейчас сильно выше, чем по AVR. На худой конец в том же кубе натыкать можно.

[uquote="Wladimir_TS",url="/forum/viewtopic.php?p=4011309#p4011309"]да и вопрос со стороны компа.[/uquote]На компе любой терминал, подключаемый по IP откуда угодно. Это лог из контроллера. Лог обмена со стороны компа WireShark можно снять. Но куда полезней видеть что внутри контроллера происходит, вы же его отлаживаете, а не комп.

[COKPOWEHEU]

[uquote="Wladimir_TS",url="/forum/viewtopic.php?p=4011309#p4011309"]Пакеты небольшие - порядка 20-30 байт, добиваются, как требует стандарт до 64 нулями.[/uquote]
Но стандарт этого не требует. Наоборот, требует передавать именно столько, сколько запрошено / реальный размер.
[uquote="Wladimir_TS",url="/forum/viewtopic.php?p=4011309#p4011309"]Можно ссылочку ?[/uquote]
https://habr.com/ru/post/548150/
[uquote="Wladimir_TS",url="/forum/viewtopic.php?p=4011309#p4011309"]Там ПО очень непростое сильно завязанное на тайминги[/uquote]
Мое дело предупредить. Насколько я помню, ISA шину на современных материнках не разводят, а запчасти тех времен найти все сложнее.
[uquote="Wladimir_TS",url="/forum/viewtopic.php?p=4011309#p4011309"]Сталкивался - что за время сброса содержимого буфера через UART на 115200 компьютер давал отлуп. А сбрасывалось-то 64 байта.[/uquote]А вы что, без буферизации сбрасываете? Ну в смысле обычно для UART создают очередь передачи, откуда в прерываниях байты передаются по одному. Соответственно и задержек особых не добавляется.

[azhel12]

Всех приветствую, попробую оживить тему, уже убил уйму времени, но проблему решить не удаётся. Пытаюсь освоить 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 удалось завести), а когда надо слать порциями - сломалось.

[azhel12]

[uquote="azhel12",url="/forum/viewtopic.php?p=4216425#p4216425"]Вдруг кто-то сталкивался, прошу помощи. [/uquote]
Отвечу сам себе. Дело в том, что отличия в модуле USB между f0/f1 и f4 (а точнее между обычным USB и USB_OTG) более чем существенные, и если для первых после приема пакета необходимо сбросить флаг USB_EP_CTR_RX и конечная точка сразу же готова к приему, то в OTG после приема пакета ничего сбрасывать не надо, однако для точки OUT аппаратно устанавливается состояние NAK. В моем случае проблема была в том, что если в процессе нумераций прилетел неизвестный (неподдерживаемый) пакет, то я ничего не отправлял, то есть в IN не записывал, а на успешную отправку стоит callback с разрешение точки OUT. Собственно, проблема решилась принудительным сбросом NAK (разрешением конечной точки) для OUT 0.

[azhel12]

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

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

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

[VladislavS]

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

[azhel12]

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

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

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

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