STM32 USB на регистрах

[jcxz]

[uquote="Cliff",url="/forum/viewtopic.php?p=4738777#p4738777"]jcxz, вспоминаю себя в мои 18-25, когда я один умный, а кругом одни д....
конечно же я это всё изучил и прекрасно понимаю, о чём вы. Меня интересует работа с протоколом в связке с аппаратной реализацией в stm32.[/uquote]Я вас и не называл д... Я написал, что в первом вопросе у вас - каша. Трудно понять о чём там речь.
Так как нет никаких setup-запросов. Есть setup-транзакция в начале control-запроса. data-stage этой транзакции всегда имеет одно направление - от хоста. Квитируется (ACK-ается) эта транзакция USB-периферией ведомого автоматически. Программа стека тут ничего не должна делать.
После setup-транзакции control-запроса как правило идёт IN или OUT транзакция (какая именно - в зависимости от bmRequestType.бит7). data-stage этой транзакций имеет направление - или "к хосту" или "от хоста". Возможно эта транзакция может вообще отсутствовать, если длина в setup==0, а может в этом случае быть IN или OUT нулевой длины (тут не уверен, но думаю - зависит от реализации стека хоста). В случае IN-транзакции вы обязаны отправить пакет данных хосту (хотя-бы нулевой длины. В случае OUT-транзакции - никакой пакет данных вы отправить не можете, можете отправить только ACK или NACK. Ну и в любом случае (IN/OUT) можете выставить STALL.

Вот и всё о завершении control-запроса. Из чего совершенно непонятно - о чём идёт речь в вашем 1-м вопросе? data-stage в control-запросе как правило - две штуки. И они могут иметь разное направление. И ни данными ни пустым пакетом вы на OUT-транзакцию ответить не можете (тем более - на setup-транзакцию). Только ACK или NACK. Возможно в том стеке, который вы ковыряли, при вызове функции отправки ZLP-кадра для OUT-транзакции, в реальности отправляется просто ACK. Но (если так) это просто - вариант реализации стека, о которой нам тут ничего не известно, так как вашего кода мы не видим и угадать не можем. Ведь тема-то - о стеке своими руками, а не о какой-то готовой реализации.

Разве я не прав? Поправьте тогда - в чём.

[Cliff]

[uquote="azhel12",url="/forum/viewtopic.php?p=4738822#p4738822"]У уважаемого COKPOWEHEU на хабре есть цикл статей по тем[/uquote]
Это было первое, с чего начал и изучил вдоль и поперёк. Но при всём уважении к этому человеку (искренне, видно, что старался), написано ужасно, особенно код. Рекомендовать бы я не стал. Но при том, что по этой теме в принципе не много статей, то изучаешь подробно всё, что есть. Особенно, когда у тебя у самого не работает.

[COKPOWEHEU]

[uquote="Cliff",url="/forum/viewtopic.php?p=4738949#p4738949"]написано ужасно, особенно код.[/uquote]
Спасибо за отзыв, но можно поподробнее? Ну не знаю, примеры что именно сделано неудачно...

[VladislavS]

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

[COKPOWEHEU]

[uquote="VladislavS",url="/forum/viewtopic.php?p=4738994#p4738994"]Слово "костыль" убрано из кода?[/uquote]
Что ж вас так это слово смущает... Ну хотите, могу исправить комментарий зачем там эта проверка?

И по уровням абстракции побить бы.

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

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

В смысле написать саму реализацию различных классов вроде HID, CDC, MSD и т.п.? Теоретически можно, но проще скопировать соответствующий *.c из другого примера и допилить под новые нужды.
Впрочем, потихоньку и этот процесс идет: вот недавно дескрипторы CDC и MSD в макросы упаковал, библиотеку virfat (эмуляция флешки с fat16) чуть более по-человечески оформил. Но это все мелочи, вряд ли Cliff говорит о подобном.
Я бы скорее предположил, что ему не понравились мои кошмарные мракосы или недостаток комментариев, или куча дефайнов. Не знаю.

[Adrift]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4739012#p4739012"]Я уже довольно много устройств на своей библиотеке сделал[/uquote]
Смотрю у вас там поддержка только для F1/L1 и подобных, типа F3, и если для F0/G4... это фиксится довольно легко, по крайней мере для самого автора, то для более новых G0/H5... уже нужны более серьезные правки. В существующем виде либа для многих бесполезна т.к. не работает со всеми относительно новыми сериями и это я даже не говорю про те где совсем другой OTG-ый USB.

[VladislavS]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4739012#p4739012"]Что ж вас так это слово смущает....[/uquote]Меня не слово смущает, а то что при правильной обработке никаких лишних вызовов не возникает. Впрочем, спорить не намерен, вы же сами просили конкретики.

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4739012#p4739012"]Что там еще сильнее абстрагировать?[/uquote]Чтобы получился именно USB-стек:
1. Код инициализации железа и контрольных точек в контроллере и функции передачи данных. Контроллерозависимый код.
2. Код стандартных функций энумерации.
3. Набор различных классов.

Тогда для любого контроллера комбинируя 1+2+3 можно быстро собирать нужное устройство.

[HardWareMan]

VladislavS, что базовый ST вариант и образует в кубике. Правда, более мудрённым способом, чем он действительно мог быть...

[COKPOWEHEU]

[uquote="Adrift",url="/forum/viewtopic.php?p=4739027#p4739027"]Смотрю у вас там поддержка только для F1/L1 и подобных, типа F3, и если для F0/G4[/uquote]
У меня таких камней нет. Зато есть куча ch32. У серий v203, v208 один из USB точь в точь как в stm32f103. А вот в более интересных v307 есть USB-HS, который совсем другой и вот с которым давно хочу разобраться. А ведь еще на подходе h417, у которого аж USB-3.
В общем, не до stm-ок.

при правильной обработке никаких лишних вызовов не возникает.

Так их и не возникает. Там же суть костыля в return. Впрочем, код этого обработчика все равно придется почитать еще раз, с учетом того, что узнал с тех пор.

1. Код инициализации железа и контрольных точек в контроллере и функции передачи данных. Контроллерозависимый код.

Так у меня весь этот код в usb_lib и есть. Реализация конкретных USB-устройств в регистры напрямую не пишет.
Нет, там, конечно, есть чего еще абстрагировать по мелочи, но это надо освоить еще хотя бы одну-две аппаратных реализации.
Или я не понимаю о чем речь. Где у меня кишки библиотеки торчат наружу?

2. Код стандартных функций энумерации.

В смысле обработка стандартных запросов вроде дескрипторов и строк? Не вижу на что ее перемещение из usb_class в usb_lib может повлиять.

3. Набор различных классов.

Видимо, пока недостаточно с ними работал, потому что не вижу что там можно абстрагировать. Даже при копипасте приходится многое переписывать. Не хватает статистики чтобы выделить общие места.

[VladislavS]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4739200#p4739200"]Там же суть костыля в return.[/uquote]Залететь в обработчик чтобы просто из него выйти. Думаете это правильно? Ну это просто на подумать...

[HardWareMan]

VladislavS, ну, как минимум снять флаг запроса...

[Cliff]

COKPOWEHEU,
нет, дело не в камментах, не в макросах и даже не в отступах.
По этим моментам всегда есть, что сказать, но я давно не заморачиваюсь по таким мелочам, т.к. пересматриваю очень большое число исходников, и тут для меня нет жестко аргументированного "как правильно". На вкус и цвет...

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

Пара примеров:

1.

Спойлер

На мой скромный взгляд, Вы совершили ту же ошибку, что и в модуле от ST, разделив вызов инициализации точек на IN/OUT. В результате пришлось писать внутри usb_ep_init() несколько больших блоков "if(dir_in)". При этом, какой-то код вообще дважды выполняется.

Поясню свои трудности:
Мне непонятно, почему нельзя было вызвать однократно, а внутри init уже отдельно выполнить процедуры IN/OUT при необходимости. Или вообще делать одновременно (у кого-то так было), т.к. регистр один.

И на выяснение этих непонятных моментов уходит много ресурсов, т.к. рассчитываешь, что чуваки в инетах, пишущие статьи, довольно грамотные (тут нет сарказма) и не будут городить сложные конструкции без серьёзного обоснования им.

2.

Спойлер

Логика ep0_out() мной совсем не осознана.
Опять же повторюсь - это мне непонятно (возможно, из-за неопытности), а не "код кривой".

а) Непонятно, почему необходимость чтения "setup-пакета" базируется на косвенных признаках, взятых из предыдущего запроса, а не из более прямых из текущего (например, признак USB_EP_SETUP, который используют все, включая ST).

б) Ход логики вокруг переменной bytesread мне вообще показался крайне запутанным и непонятным.

в) строчка "if( !setup )return;" вообще вызвала у меня лаботамию, т.к. вообще не понял её функциональное назначение там. И дело вовсе не в надписи "костыль", а в том, что я вообще не понял, по какой логике Вы её туда вставили. Что там вызывается два раза и почему с этой строчкой это лечится. Сюда же ведь прерывание нас не просто так привело, а мы его просто игнорим. Я даже потратил много времени, чтобы попытаться с этим разобраться, но безуспешно.

----------------

Ну и таких нестыковок там прям очень много.

Спойлер

Опять же, это всё субъективное. Я прекрасно понимаю, что возможно просто не хватает опыта у меня, чтобы это всё понять. И в этом случае, конечно же, более подробные пояснения очень помогли бы.

Очень прошу воспринимать не как критику. И, тем более, не воспринимать как моё желание поумничать. Пишу только ради обратной связи, не более того. Извиняюсь, за многабукв.

[jcxz]

[uquote="Cliff",url="/forum/viewtopic.php?p=4739618#p4739618"]Очень прошу воспринимать не как критику.[/uquote]Боязнь критики - верный признак самовлюблённого чайника.
Адекватный разработчик должен не только не бояться критики, но должен приветствовать её. Во всех серьёзных проектах должен быть этап критики от оппонентов. И в хвост и в гриву. Это называется: "защита проекта". И если проект её не проходит - его следует немедленно закрыть или направить на переделку.
Неужто никто тут не защищал дипломы, диссертации, рабочие проекты и т.п.?

[COKPOWEHEU]

VladislavS, ну, как минимум снять флаг запроса...

Что-то мне кажется, алгоритм должен быть несколько сложнее. Не просто же так этот флаг выставился.
[uquote="Cliff",url="/forum/viewtopic.php?p=4739618#p4739618"]Вы совершили ту же ошибку, что и в модуле от ST, разделив вызов инициализации точек на IN/OUT. В результате пришлось писать внутри usb_ep_init() несколько больших блоков "if(dir_in)". При этом, какой-то код вообще дважды выполняется.[/uquote]
Имеется в виду, если комплементарная пара точек используется в одном и том же девайсе? Так ведь никто не гарантирует, что это будет именно комплементарная пара точек. Этого еще можно ожидать в CDC или MSD (и то если нет двойной буферизации). Но в HID, в Audio устройствах направление всего одно.
Ну и в любом случае, это код инициализации, он выполняется единственный раз при подключении к хосту, так что задержки в нем не критичны.
В самом стандарте USB точки IN и OUT никак не пересекаются. Строго говоря, даже в реализации от ST теоретически можно ep1 назначить на EP2R, а ep82 на EP4R. Но руками я такое даже не пытался тестировать.

а) Непонятно, почему необходимость чтения "setup-пакета" базируется на косвенных признаках, взятых из предыдущего запроса, а не из более прямых из текущего (например, признак USB_EP_SETUP, который используют все, включая ST).

Вот в этом мне еще предстоит более подробно разобраться.

в) строчка "if( !setup )return;" вообще вызвала у меня лаботамию, т.к. вообще не понял её функциональное назначение там. И дело вовсе не в надписи "костыль", а в том, что я вообще не понял, по какой логике Вы её туда вставили. Что там вызывается два раза и почему с этой строчкой это лечится.

На то и "костыль", что на момент написания я толком не знал почему этот код вызывается дважды, и вот таким дубовым способом от этого избавился. Там не было теории - только метод тыка.

Я даже потратил много времени, чтобы попытаться с этим разобраться, но безуспешно.

Жаль Могли бы и не рассказать...

Очень прошу воспринимать не как критику.

Вы на представляете как тяжело порой получить вменяемую критику. Она ведь куда ценнее пустых комплиментов.
Да и вообще, мы на техническом ресурсе. К чему здесь эти извинения и расшаркивания, которые только отвлекают от сути.

Неужто никто тут не защищал дипломы, диссертации, рабочие проекты и т.п.?

На дипломах сейчас не валят.
В общем, Cliff, VladislavS, спасибо за критику. Сейчас я хочу разобраться с USB-HS, надеюсь и порядок обмена в целом станет более понятен. Тогда и допилю эту библиотеку.

[Cliff]

[uquote="COKPOWEHEU",url="/forum/viewtopic.php?p=4739677#p4739677"]Так ведь никто не гарантирует, что это будет именно комплементарная пара точек[/uquote]
Дык это всегда решалось конструкцией типа:

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

ep_init(num:1, type: BULK, bufin: 64, bufout: 0);

Ну или вообще делим на три вызова:

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

ep_init_type(num:1, type:BULK);
ep_init_in(num:1, bufsz: 64);
// аналогично out при необходимости.

А в вашем варианте:

usb_ep_init(num:0x00, type:USB_ENDP_CTRL, bufsz:USB_EP0_BUFSZ, hnd:ep0_out);
usb_ep_init(num:0x80, type:USB_ENDP_CTRL, bufsz:USB_EP0_BUFSZ, hnd:ep0_in);

складывается ложное впечатление, что для IN и OUT можно указать разные типы.

Это всё, разумеется, на вкус и цвет... Но статья позиционируется как обучающая, и вот из личного опыта могу сказать, что обучение по такому варианту - довольно тяжело. Остальные все фрагменты - аналогично.