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

[VladislavS]

azhel12, не очень понял про очевидность влияния lto на работу кода. Его в принципе не должно быть. Ну и дескрипторы это константные данные, они во фллэшь лежат. Я вроде давал вам ссылку как они на плюсах формируются. В памяти только указатель и счётчик очереди отправки. И то, только для "классики" в OTG хватает FIFO чтобы практически любой дескриптор за один раз запихнуть.

[azhel12]

VladislavS, lto не должен влиять, но где-то в коде есть UB, который себя так и проявляет.

Про константность согласен, уже в процессе переделки (странно, что раньше не дошел до этого).

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

[VladislavS]

[uquote="azhel12",url="/forum/viewtopic.php?p=4396089#p4396089"]Ссылку не помню, но было, что даже дискуссия некоторая случилась, вы собираете конфигурацию устройства в виде, по сути, дескрипторов, из которых потом разворачивается конфиг, а у меня наоборот, объявляются точки, интерфейсы, конфигурации и из этого генерируются дескрипторы.[/uquote]Это непринципиально что из чего вы формируете. Главное, что это constexpr контекст. А дальше только ваши джедайские навыки что из чего во флэшь утоптать.

USB Descriptors C++

[azhel12]

Кстати, перетащил к себе списки типов, спасибо, код стал как минимум гораздо понятнее без этой шаблонной ужасающей рекурсии. Еще для экономии нажатия кнопок еще такое сделал:

Код: Выделить всё

struct DummyTypeBoxBase {};

template <typename T, typename Enabler = void>
constexpr bool is_complete_v = false;

template <typename T>
constexpr bool is_complete_v<T, std::void_t<decltype(sizeof(T) != 0)>> = true;

template<typename T>
struct TypeBox : public std::conditional_t<std::is_class_v<T> && is_complete_v<T>, T, DummyTypeBoxBase>
{
    using type = T;
};

Добавлено after 22 minutes 10 seconds:
VladislavS, если я верно понял, этот репозиторий - часть какого-то проекта, а как пользователь потом задает обработчики для OUT-транзакций? Если правильно понимаю, все остальное можно родить из такого глобального дескриптора.

[COKPOWEHEU]

Согласен, сейчас прикинул, все равно ведь все эти данные где-то во Flash итак лежали (чтобы потом в RAM быть записанными), так что даже какого-то значимого оверхеда быть не должно.

Да что там того оверхеда, пара сотен байт. У вас таблица векторов небось больше весит.
[uquote="VladislavS",url="/forum/viewtopic.php?p=4396078#p4396078"]Ну и дескрипторы это константные данные, они во фллэшь лежат. Я вроде давал вам ссылку как они на плюсах формируются.[/uquote]
Справедливости ради, можно придумать как усложнить себе жизнь. Например, выбирать какие модули в устройстве будут использоваться в этот раз - будет ли оно флешкой, или мышкой, или переходником, или комбинацией всего этого. Извращение, конечно, еще то, но вдруг.
А дескрипторы даже на мракосах Си прекрасно пишутся, не то что на плюсовых шаблонах.

[VladislavS]

[uquote="azhel12",url="/forum/viewtopic.php?p=4396108#p4396108"]а как пользователь потом задает обработчики для OUT-транзакций?[/uquote]
Я обработчики из дескрипторов не формирую. У меня обработчики это методы USB-класса. Я для них делаю список типов TIRQHandlers с номерами конечных точек и привязанными к ним указателями на методы-обработчики. Как-то так.

Спойлер

111.png

(92.57 КБ) 124 скачивания

С вашим подходом подобный список из конечных точек сформировать тоже не составит труда.

В обработчике прерывание это используется вот так

Спойлер

222.png

(115.86 КБ) 120 скачиваний

Или для OTG с двумя интерфейсасм (HS и FS)

Спойлер

333.png

(98.16 КБ) 122 скачивания

[uquote="azhel12",url="/forum/viewtopic.php?p=4396108#p4396108"]Если правильно понимаю, все остальное можно родить из такого глобального дескриптора.[/uquote]
Я не гонюсь за тем чтобы всё из всего генерилось. В дескрипторах дурацкая работа по заполнению есть - автоматизирую. А несколько обработчиков прописать для класса можно и вручную. Заодно и приоритет обработки (скорость реакции прерывания) можно выбрать.

Добавлено after 1 hour 3 minutes 19 seconds:
[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4396160#p4396160"]Справедливости ради, можно придумать как усложнить себе жизнь. Например, выбирать какие модули в устройстве будут использоваться в этот раз - будет ли оно флешкой, или мышкой, или переходником, или комбинацией всего этого. Извращение, конечно, еще то, но вдруг.[/uquote]Ну и пусть себе лежат все дружно во флэшь. Выбрать по обстоятельствам какой из них скормить хотсу не составляет труда.

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4396160#p4396160"]А дескрипторы даже на мракосах Си прекрасно пишутся, не то что на плюсовых шаблонах.[/uquote]Да они даже просто мэджикнамберами пишутся. А вот автоматизировать на плюсах можно лучше, чем макросами. Мы это уже разбирали на примере HID Report Descriptor, не надо на следующий круг заходить.

[COKPOWEHEU]

Ну и пусть себе лежат все дружно во флэшь. Выбрать по обстоятельствам какой из них скормить хотсу не составляет труда.

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

Да они даже просто мэджикнамберами пишутся. А вот автоматизировать на плюсах можно лучше, чем макросами. Мы это уже разбирали на примере HID Report Descriptor, не надо на следующий круг заходить.

Мэджикнамберами замучаешься размеры править, да и читать такое неприятно.
А вот макросы по удобству неписания дескрипторов от шаблонов почти не отличаются. Что не удалось мне - поле 1-2-3-4 байта в HID и, кажется, была подобная штука в аудио. Тут без фанатизма: мне привычнее Си, и изучать С++ я не хочу. А что возможности шаблнов выше, и сам говорю.

[НАПАЛМ]

Всем привет!
Хочу еще одной радостью поделиться, таки удалось девайс с юсб cdc acm на cmsis запустить с машиной на убунте, перекинулся пару байтиками с девайсом с компа - радости куча
Еще несколько вопросов: тот же девайс на винде определился в диспетчере как последовательный usb (com), но с ошибкой 10 - операция не может быть выполнена, куда копать?
По поводу baud rate у виртуального com порта - он вообще хоть на что-нибудь влияет? С учетом того, что хост может сколько угодно конечную точку девайся ждать, не обижаясь на нак.

[COKPOWEHEU]

Еще несколько вопросов: тот же девайс на винде определился в диспетчере как последовательный usb (com), но с ошибкой 10 - операция не может быть выполнена, куда копать?

Запускаете анализатор трафика, например, wireshark, и смотрите какую команду ваше устройство не сумело обработать.

По поводу baud rate у виртуального com порта - он вообще хоть на что-нибудь влияет? С учетом того, что хост может сколько угодно конечную точку девайся ждать, не обижаясь на нак.

Это важно скорее для переходника USB-UART, на стороне UART вам ведь надо выставлять настройки.

хост может сколько угодно конечную точку девайся ждать, не обижаясь на нак.

Так может, именно это винде и не по нраву? Хоть бы ACK отвечали.

[НАПАЛМ]

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

[VladislavS]

[uquote="НАПАЛМ",url="/forum/viewtopic.php?p=4403983#p4403983"]Спасибо за наводку, попробую wireshark использовать, надеюсь поможет в этом нелегком деле [/uquote]Не поможет. Лучше из контроллера логи обмена тянуть. Писать все запросы/ответы и сразу увидите на какой не ответили.

[azhel12]

[uquote="VladislavS",url="/forum/viewtopic.php?p=4404003#p4404003"]Не поможет.[/uquote]Мне помогало. Понятно, что Wireshark что-то показывает только после прохождения нумерации, но тем не менее какие-то проблемы анализировать получалось. Так что, мне кажется, Wireshark и логи друг друга неплохо дополняют.

Вообще сильно не хватало какого-то анализатора, китайский клон saleae с USB, разумеется, не справлялся, хотя было бы крайне полезно.

P.S. Например, ловил UB, но с логированием в UART всё начинало работать. Складывать логи в буфер не пробовал, но, думаю, тоже бы сломалась воспроизводимость ошибки.

[COKPOWEHEU]

Ну про нак это я так, к слову, что хост не должен обижаться на ожидание данных от конечной точки

Так он и не обижается, просто признает устройство неисправным, если данные должны идти, а их нет.

Спасибо за наводку, попробую wireshark использовать, надеюсь поможет в этом нелегком деле

Не поможет.

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

[НАПАЛМ]

Да, действительно wireshark не помог - просто не видит мой девайс. Что ж, придется по-старинке юарт-ловушки расставлять

[COKPOWEHEU]

Это как так? Система видит, а Акула - нет?! Уж запрос дескрипторов-то должен отображаться. А другие устройства оно видит?
Еще. Я, когда с MSD под винду разбирался, wireshark запускал на хостовой системе, а не в виртуалке. Кто их знает, может и правда винда не позволяет часть пакетов отлавливать. Хотя это было бы странно.

[НАПАЛМ]

Да, другие юсб он видит

[VladislavS]

Лог запросов при подключения CDC к Win10.

Спойлер

Код: Выделить всё

Int_USBRST
Int_SUSPEND
Int_WKUP
Int_USBRST
GET_Device_Descriptor 64 bytes
Int_USBRST
SET_ADDRESS 24
GET_Device_Descriptor 18 bytes
GET_Configuration_Descriptor 255 bytes
GET_String_Descriptor 0x3 255 bytes
GET_String_Descriptor 0x0 255 bytes
GET_String_Descriptor 0x2 255 bytes
GET_Device_Qualifier_Descriptor 10 bytes
GET_Device_Descriptor 18 bytes
GET_String_Descriptor 0x0 255 bytes
GET_String_Descriptor 0x3 255 bytes
GET_String_Descriptor 0x1 255 bytes
GET_String_Descriptor 0x2 255 bytes
GET_Device_Descriptor 18 bytes
GET_Configuration_Descriptor 9 bytes
GET_Configuration_Descriptor 67 bytes
GET_Configuration_Descriptor 265 bytes
SET_CONFIGURATION 1
GET_LINE_CODING
SET_CONTROL_LINE_STATE 0
SET_LINE_CODING
SET_LINE_CODING DATA 0 0 0 0
GET_LINE_CODING
GET_String_Descriptor 0x0 255 bytes
GET_String_Descriptor 0x1 255 bytes
GET_String_Descriptor 0x2 255 bytes
SET_CONTROL_LINE_STATE 0
GET_LINE_CODING
SET_CONTROL_LINE_STATE 0
GET_LINE_CODING
SET_LINE_CODING
SET_LINE_CODING DATA 256000 0 0 8
GET_LINE_CODING
SET_CONTROL_LINE_STATE 0

Открытие порта

Спойлер

Код: Выделить всё

SET_CONTROL_LINE_STATE 0
GET_LINE_CODING
SET_LINE_CODING
SET_LINE_CODING DATA 2000000 0 0 8
GET_LINE_CODING
SET_CONTROL_LINE_STATE 1
SET_LINE_CODING
SET_LINE_CODING DATA 2000000 0 1 8
GET_LINE_CODING

На всё это устройство должно уметь отвечать. Хорошо ещё выводить что вы отвечаете на каждый запрос.

[НАПАЛМ]

Благодарю, будем копать

[COKPOWEHEU]

Да никто не спорит, можно и в таком стиле отлаживать: https://habr.com/ru/articles/460815/
Но когда устройство уже прошло энумерацию, анализаторы все же удобнее.

[VladislavS]

Отлаживать нужно там где проблема, а не где удобнее.