1. Готовый или самопальный?

[Arlleex 173]

Просто интересно. Если готовый, то какой?

[Eddy_Em 1]

Т.к. нормальных готовых нет, то только самопальный.

[jcxz 232]

26 минут назад, Arlleex сказал:

Просто интересно. Если готовый, то какой?

Много лет на разных МК пользуюсь USB-device-стеком из примеров IAR (для процессоров LPC17xx). Только оптимизированным.

Он достаточно прост, и в то же время - имеет всё что нужно: Ядро стека находится в одном файле (usb_t9.c), дескрипторы - в другом (usb_dev_desc.c), файл low-level-IO процедур - в отдельном файле (usb_hw.c), а все надстройки профилей - для каждого свой отдельный файл, подключаемый при необходимости (какие нужны и если нужны) (hid_....c, cdc_....c и т.п.). На каждый новый МК нужно переписать только low-level-IO.

 

PS: Вот и сейчас - только что портировал его на XMC4xxx, взамен слишком громоздкого родного.

[Arlleex 173]

3 минуты назад, jcxz сказал:

Много лет на разных МК пользуюсь USB-device-стеком из примеров IAR (для процессоров LPC17xx).

Вот и мы его за основу взяли...

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

[jcxz 232]

13 минут назад, Arlleex сказал:

Вот и мы его за основу взяли...

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

Да если внимательно почитать его (параллельно оптимизируя), то становится понятно, что в usb_t9 (главном теле стека):

USB_SetupHandler() - эта процедура вызывается из low-level-ISR процедуры при получении SETUP-пакета. От неё растёт вся обработка этих SETUP-ов (энумерации и все стандартные запросы и запросы профилей).

Ещё там должен быть обработчик фазы данных для IN- и OUT-запросов по ep0 и фазы статуса. Вызываемый также из ISR. Название не скажу - оно у меня уже всё переименовано в моём стиле имён.  

Это и составляет основную часть usb_t9.

Также там есть мелкие обработчики событий RESET, INIT, WakeUp и пр. вызываемые из того же ISR.

Вобщем чтобы разобраться, нужно посмотреть что и в каких случаях вызывается из ISR USB (который в usb_hw.c).

 

PS: У меня этот стек работает(-ал) на LPC23xx, LPC17xx, LPC4370, OMAP L137, а теперь ещё и на XMC4500.  

[GenaSPB 11]

Quote

Брал готовый. Но перепилил настолько, что он стал самопальным

Готовый stm32 из последних кубовских. Оказалось работает вплоть до stn32mp1. Так же компиляция под  renesas rza1 со с специфическим low level. И полностью своя генерация дескрипторов в озу с автоматическим подсчёт ом размеров. Зборово помогает при разбирательствах с новыми классами и позволяет на старте определятт конфигурацию и делатт специфическиф дескриптор. Как пример серийники вычитывать и вставлять в строковые дескримторы.

[jcxz 232]

51 минуту назад, Arlleex сказал:

Вот и мы его за основу взяли...

Похоже я Вам соврал.  Сейчас проверил - за основу в последних проектах я взял USB-device-стек не из LPC17xx, а из LPC43xx. Так как там уже есть поддержка HS. Но в принципе структура у них похожая, только переименованы файлы: usb_t9 -> usbcore; usb_dev_desc -> usbdesc; ну и прочие подобно.

[mantech 48]

1 час назад, Arlleex сказал:

Если готовый, то какой?

Готовые есть, но понравятся они разве, что "кубистам" и ардуинщикам. Всем, кто делает что-то посерьезнее приходится его пилить и допиливать, не буду оригинален, если скажу, что сам брал готовые и переделывал там от 30 до 70% кода.

[Arlleex 173]

24 минуты назад, jcxz сказал:

Но в принципе структура у них похожая, только переименованы файлы: usb_t9 -> usbcore; usb_dev_desc -> usbdesc; ну и прочие подобно.

А я и сам думал что это одни и те же стеки... usbcore, usbdesc для меня более знакомые названия исходников.

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

Устроено довольно несложно, при некоторой осведомленности в USB все становится более менее понятно, но нет банальной уверенности, что делать при смене МК.

Вот и подумывал я написать что-то свое, подглядывая в любой "народный" простой USB-стек.

 

P.S. В общем, идея в принципе понятна: взять готовое, пошуршать по исходникам и допилить, при необходимости, под себя.

[Eddy_Em 1]

39 minutes ago, mantech said:

сам брал готовые и переделывал там от 30 до 70% кода.

Готовые плохи не только оверхедом (т.к. туда пытаются втиснуть универсальность, чтобы на основе одного и того же кода можно было любые классы USB поднять — а это зло!), но и большим количеством файлов. В идеале USB должен состоять из одного сишного файлика и одного заголовочного.

[Сергей Борщ 134]

1 час назад, Eddy_Em сказал:

В идеале USB должен состоять из одного сишного файлика и одного заголовочного

Это "совет космического масштаба и космической же глупости"? У меня стек, реализующий только виртуальный COM-порт на USB device STM32x0x содержит семь .cpp и десять .h файлов в пяти директориях, не считая еще двух .cpp файлов в самом проекте, где этот стек используется (один - описание дескриптора и второй - работа со стеком). К тому же два заголовочных файла из этих семи у меня используются еще и в стеке для USB OTG STM32F2x/F4x, а две директории с двумя исходниками и тремя заголовочными файлами подменяются другими при компиляции загрузчика без ОС. Самый большой файл (заголовочный с описаниями структур дескрипторов) пока занимает 15 К, пять файлов по порядка 6 К, остальные 1-2 К.  Если я все это свалю в две большие кучи - там не только я, там сам черт ногу сломит. И, кстати, чтобы поднять какой-то другой USB класс, мне надо будет добавить в стек одну директорию с заголовочным файлом и, может быть, одним файлом исходного кода и это (о ужас) никак не повлияет на проекты, собирающиеся из этих же исходников без этого нового класса. Где зло?

[Rst7 5]

Вот прям могу с пылу с жару рассказать про борьбу с USB-стеком. Камень - iMX RT1020. Имею принцип в жизни - писать самому, готовое не использовать, максимум - подглядеть в примеры какие-то опущенные в даташитах подробности.

 

Spoiler

Сразу скажу, что на камень омерзительная документация. Куча умолчаний, куча неочевидных вещей, разбросанных по всей доке, с отсутствием прямых указаний, где поглядеть. И куча банальных недосмотров типа обозначения пунктов в алгоритме буквами a, b, c..., а ссылки в этом алгоритме типа "go to step 5". В свое время приходилось работать с мотороловскими процами во времена 680x0 - тогда у них документация была просто песней. Ну и у NXP тоже всегда была отличная. Я не ожидал, что так будет провально.

 

Я не особо часто бодался с USB, последний раз лет эдак 15 назад делал эмулятор FT232 на AT90USB162. А теперь пришлось сделать ECM/RNDIS устройство. Официальные примеры для этих iMX RT есть, но со страшным нагромождением уровней абстракции, разбросано по куче файлов, местами - плюсы на Си врукопашную, в общем - все прелести.

Довольно быстро все поехало в простом варианте типа суперцикла, без всяких прерываний, просто с проверкой флагов. Затем начал переделывать на вменяемую работу, т.е. прерывания, обеспечение zero copy, минимальные простои и так далее. И в конце концов наступил на мертвое зависание алгоритма добавления нового буфера в цепочку буферов USB DMA на ходу. Алгоритм описан в даташите, более того, именно его реализацию (не без индусских делов) я обнаружил при изучении примеров (после того, как моя реализация не заработала). Убито было несколько дней. Оказалось, что в заголовочном файле с регистрами периферии был неверно описан один из битов в регистрах (не 1<<14, а 1<<12). Обнаружил это совершенно случайно, когда уже начал проверять совсем все. Заголовочный файл с регистрами был взят именно из официальных примеров. Так что официальные примеры, конечно, компилируются, но вот никто их на таргете никогда не запускал и не проверял. Вообще оказалось, что во всей этой iMX-линейке вроде бы и один и тот же USB, но этот бит пляшет произвольно от типа к типу, в каких-то - 12й, в каких-то - 14й, в некоторых это считалось ошибкой и описано в errata, в некоторых нет, в общем - полный хаос.

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

[AlexandrY 3]

24 minutes ago, Rst7 said:

Вот прям могу с пылу с жару рассказать про борьбу с USB-стеком. Камень - iMX RT1020. Имею принцип в жизни - писать самому, готовое не использовать, максимум - подглядеть в примеры какие-то опущенные в даташитах подробности.

Вы просто купились на халявный, но откровенно слабый софт.
Есть хорошие  метрики. 
В i.MX RT USB стеке всего 66 файлов объемом 1,87 Мегабайт.
Для сравнения в Nucleus Plus стек USB занимает 491 файл и 7,4 мегабайта, а в ThreadX  файлов 337  и 4,3 мегабайта
Даже в аскетичном UCOS 110 файлов про USB объемом 5 мегабайт. 

Одно дело трудность освоения чужого кода, и совсем другое поддержка своего middleware. Последнее не оправдывается по нынешним временам. 

 

[Rst7 5]

3 minutes ago, AlexandrY said:

Вы просто купились на халявный, но откровенно слабый софт.

А причем тут "слабый софт"?

6 minutes ago, AlexandrY said:

Одно дело трудность освоения чужого кода, и совсем другое поддержка своего middleware. Последнее не оправдывается по нынешним временам. 

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

[Rst7 5]

26 minutes ago, AlexandrY said:

В i.MX RT USB стеке всего 66 файлов объемом 1,87 Мегабайт.

Давайте, кстати, проверим на вшивость Ваш прекрасный дорогой софт.

Что у Вас в заголовочнике с регистрами от RT1020 описано для USB_USBCMD_ATDTW_MASK и USB_USBCMD_ATDTW_SHIFT?