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

[VladislavS]

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

Последний раз редактировалось VladislavS Вт апр 04, 2023 13:40:14, всего редактировалось 1 раз.

[azhel12]

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

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

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

[VladislavS]

azhel12 писал(а):

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

Это непринципиально что из чего вы формируете. Главное, что это 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 быть записанными), так что даже какого-то значимого оверхеда быть не должно.

Да что там того оверхеда, пара сотен байт. У вас таблица векторов небось больше весит.

VladislavS писал(а):

Ну и дескрипторы это константные данные, они во фллэшь лежат. Я вроде давал вам ссылку как они на плюсах формируются.

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

[VladislavS]

azhel12 писал(а):

а как пользователь потом задает обработчики для OUT-транзакций?

Я обработчики из дескрипторов не формирую. У меня обработчики это методы USB-класса. Я для них делаю список типов TIRQHandlers с номерами конечных точек и привязанными к ним указателями на методы-обработчики. Как-то так.

Спойлер

111.png

(92.57 KiB) Скачиваний: 30

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

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

Спойлер

222.png

(115.86 KiB) Скачиваний: 20

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

Спойлер

333.png

(98.16 KiB) Скачиваний: 18

azhel12 писал(а):

Если правильно понимаю, все остальное можно родить из такого глобального дескриптора.

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

Добавлено after 1 hour 3 minutes 19 seconds:

COKPOWEHEU писал(а):

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

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

COKPOWEHEU писал(а):

А дескрипторы даже на мракосах Си прекрасно пишутся, не то что на плюсовых шаблонах.

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

Последний раз редактировалось VladislavS Вт апр 04, 2023 18:01:33, всего редактировалось 1 раз.

[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]

НАПАЛМ писал(а):

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

Не поможет. Лучше из контроллера логи обмена тянуть. Писать все запросы/ответы и сразу увидите на какой не ответили.

[azhel12]

VladislavS писал(а):

Не поможет.

Мне помогало. Понятно, что 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]

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