Работаю над собственным драйвером для USB в STM32 , что-то мало материала. 99 % как скомпилировать готовый пример. Кто занимался аналогичной задачей? В принципе значительная часть уже сделана.

Что имеется в виду под "драйвером USB"? Виндовый драйвер для своего USB-девайса?

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

Мне понятно, что имеется в виду драйвер в микроконтроллере. (Ни под что )
Понимаю и поддерживаю желание топикстартера. Но помочь, увы, не могу.

Тема пообщаться или о чем?

А в чем проблема? Через libudev + libusb все решается. Главное — чтобы systemd чертового не было на компьютере, а то поцтеринг та еще свинья, спокойно может очередную гадость подкинуть.

Чем не устраивает кейловский пример?

То, что находится в МК в этом случае, принято называть "стеком". Так исторически сложилось

Я занимался. Достаточно долгое время.
В итоге есть платформонезависимая библиотека. К ней подключаются файлы драйверов для различных МК. Один файл - один модуль и один заголовок.
Сейчас есть драйверы для AVR XMEGA, AT91, STM32 USB, STM32 OTG.
STM32 OTG дался труднее всех. Есть некоторые отличительные нюансы, к примеру, для F107, F407 и L4xx в плане инициализации Device Core. Это те, с которыми работал.

Сам Ка(е)йл называл такие вещи драйверами, еще и макроопределение ввел STDPERIPH_DRIVER.

Под стеком, исторически, подразумевается оболочка и API к ней, которая знать не знает, на каком МК она выполняется. Все что ниже - драйвер.

Не, драйвер эта такая штука которая управляется менеджером драйверов и может быть динамически привязана и отвязана от процесса.
Т.е. физически набор функций со строго единообразным верхним интерфейсом для любой периферии.
У Keil-а отродясь такого не было.
Не все RTOS такое имеют.
Потому как в embedded это излишне, там нет нужды динамически менять и управлять драйверами.
А потому автор должен был написать по простому какой набор функций он хочет реализовать, а не туманить насчет драйвера. Эти функции там на пальцах пересчитать можно.

lwIP что по Вашему? Или FatFS?

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

Обычно это все таки называется библиотекой под МК, хотя иногда и стеком

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

Я даже скажу, что использования термина "драйвер" крайне вредно для TC.
Вместо того чтобы написать всего две специализированные функции read_x и write_x и остальное разрулить прямым доступом к периферии без всякой унификации, он будет сочинять API, которое сам забудет через месяц.

Вообще дурацкое это слово — "драйвер". Я только драйверы шаговых двигателей могу вспомнить. Где еще в природе это слово употребляется? На компе с железяками работают модули ядра (если их сразу в ядро не вмонолитили). На железяках крутятся прошивки. Где драйвера-то?

Эдди, вы когда-нибудь ставили Виндовс на голый комп?
https://ru.m.wikipedia.org/wiki/Драйвер

Может, здесь?

Тьфу-тьфу, с этим говном дела не имею!

Просто какой-то осел модуль ядра драйвером назвал.
Бывает. До сих пор встречаются ослы, которые директории/каталоги/справочники называют "папками". А мамок им не завезли случайно?

Это ортодоксальный фанатик, какая винда? О чем вы... Спросите еще, как диск С отформатировать

Драйвер - всегда была программа, являющаяся мостом между аппаратным устр-вом уровня ядра и программой уровня пользователя. В МК таких уровней, как правило, нет, поэтому название "драйвер", как-то не совсем корректно.

ОС часто есть. И приложение, использующее ОС. Вполне допустимо назвать "прокладку" между приложением и аппаратным ресурсом - драйвером. Можно и как-то иначе, не возражаю.

Если под драйвером понимать то, что в МК обеспечивает работу USB интерфейса, то у меня написано свое под STM32 (назовем USB стек+некая HAL прослойка, хотя с платформонезависимостью я особо не заморачивался). А в чем собственно вопрос?

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

Ну так автор наверно хочет узнать что же входит или должно входить в состав "своего"
Расскажите что у вас там "своё".
Хост или дивайс вы сделали, или может OTG?
Покажите список вызовов вашего API между аппаратурой и фреймворком. Это ж не секретно?
А также между фреймворком и классами.
Или если нет у вас такого деления на уровни, то расскажите почему.
Покажите список классов которые вы реализовали.
Покажите как сделан адаптер к RTOS, как реентерабельность обеспечена и т.д. и т.п.

Нате, глумитесь.

У меня свое все , включая RTOS, графику, математику и т.д. Касательно USB реализован USB device, host/OTG мне не интересен, потому не реализовывался.


Реализованы CDC и аудио устройство, может быть сделаю еще Mass Storage. Деление на уровни есть - нижний уровень общается непосредственно с аппаратурой, ядро реализует обработку базовых запросов и обеспечивает обработку запросов классами, классы взаимодействуют с первыми двумя уровнями, полная изоляция не делалась. Ставилась задача сделать не универсального монстра (таких хватает), а маленький модуль под конкретные задачи. В итоге три VCP и аудио устройство (стерео in/out) у меня занимают:
- базовый модуль (HAL+ядро) 5.2кбайт флеша
- CDC класс (виртуальный ком порт) - 1119байт
- Аудио класс - 456байт флеша

API между классами и стеком несколько нетрадиционен по части стандартных запросов, они реализованы через "карты" обработчиков (по типу того, как сделана обработка событий в MFC/ATL/WTL). Поэтому у меня нет аццких switchей Также все дескрипторы сделаны через макросы, так что нет необходимости подсчитывать их длины, порядок байт и прочую ерунду. Например строковые дескрипторы:


И их обработка:


Разные языки поддерживаются в таком же стиле

Также и с другими запросами (типа выбора интерфейса, параметров CDC, параметров аудиодевайса и т.д., а также стандартные запросы дискрипторов устройства, конфига и т.п.).


Стек изначально рассчитан работу с моей RTOS, потому никаких никаких адаптеров не делалось. Реентабельность обеспечена обычными средствами RTOS - критическими секциями, семафорами и т.д. Без RTOS он не работает, почему так я уже объяснил выше.

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

У меня тоже - почти всё своё Кроме RTOS разве что. Хотя и к ней тоже порт - свой, ну ещё кой-какие её корректировки.
А так и USB-device (когда нужен) - свой, и TCP-стек - свой, и графические библиотеки - тоже свои, о математике и прочих фильтрах и не говорю...


Это как я понимаю - массивы указателей на обработчики? Они у Вас во флешь или интерактивно в runtime-е в ОЗУ создаются?


"Аццкие" switch-и если они действительно аццкие, компилятор как правило превращает в эти же самые массивы указателей. Если возможно.


У меня тоже так же сделано. Только имена макросов другие


Я иногда делаю на callback-ах такое взаимодействие. Например: в TCP-стеке так сделан вызов обработчиков протоколов, обработчиков событий для сокетов и т.п.
Поэтому оно никак не привязано к ОС (или к её отсутствию вовсе).

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

Я бы TC предложил не делать "своё", а отрефакторить в пределах разумного какой-либо хорошо документированный USB фреймворк.
Вот допустим в MQX есть отличная документация и полные исходники USB стека для Device, Host(EHCI, KHCI), OTG. Имеет реализации всех востребованных классов HID, CDC, MSD, Audio, Video, Composite, RNDIS
Десятки примеров законченных приложений. Полная интеграция в RTOS, файловую систему, TCP стек и т.д.

А все что "полностью своё" это будет как правило очень примитивно с урезанной функциональностью, не документировано и непереносимо даже на уровне компиляторов.

Ага - вон тут в соседних темах товарищ на букву Д (не будем показывать пальцем "рефакторит" всё и "рефакторит" чьи-то шедевры.
Да и так полно тут "рефакторщиков" которые только говнокодом из тырнета живут.
Чем больше смотришь всякие "примеры" тем меньше хочется их рефакторить или вообще как-то использовать.

есть лицензия, которая запрещает использовать MQX где-то кроме фрискейловских процов.

MQX идет с лицензией разрешающей ее использование только на чипах от NXP.
Также нельзя публиковать исходники MQX от своего имени. Но модифицировать и делиться ими можно.

The license agreement from NXP only permits distribution of the provided code in object form only, and only if that object code is integrated into a physical device that contains an NXP processor. Насчет делится загнули как-то. В общем не отрицая положительных качеств MQX стоит заметить что на нём стоит вендорлок.

Вы логику включите.
У них форум есть с обсуждением комьюнити версии MQX. Они там ее модифицируют как хотят. Как они это делают не делясь исходниками?
А также эта фраза говорит, что скомпилированные библиотеки под чипы NXP с MQX могут выкладываться свободно.
А привязка к узкому семейству чипов это даже хорошо, не будет ненужных веток и фрагментации.

Ну и правильно


Нет, макросы разворачиваются прямо в код из цепочки if/else и выховы функций без использования указателей.





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

То что они не собираются наказывать своё комюнити, в тех случаях когда они считают нарушения незначительными это одно. А вы, к примеру, выкладывая что-то завязанное на MQX на тот же гитхаб - нарушаете лицензию, это другое. Поймите нет второго сорта лицензионной чистоты, когда вы почти "соблюдаете" лицензию. Либо ваш продукт белый в плане лицензий, либо он их нарушает и вы находитесь из-за этого в зоне риска. Это как с электриками которые нарушают ТБ - не все сталкиваются с последствиями своих нарушений, но это не значит что так поступать правильно.

Ммм, давайте не будем называть недостатки достоинствами?

При чем тут электрики если вы плохо поняли лицензию.
Вот у меня выложен стек USB.
Абсолютно лицензионно чисто.

А недостатком привязка возможно была до того как объявили о i.MX RT. А теперь это только достоинство.


Уважаемый, если вы тут хотите продавать, то что лежит бесплатно на каждом углу, то имейте совесть. И не флудите в форуме.

Премного благодарен! Многая лета.

В книге 'Making Embedded systems' описывается шаблон программирования МК под названием 'драйвер', ну это так.
Залез в USB-FS-Device_Lib_V4 и ужаснулся, мрачное нагромождение файлов и не понятно по какому принципу.
Меня интересовало как можно подойти к проблеме.

Общая схема, два конечных автомата, один автомат отвечает за переходы между состояниями USB устройства, а второй за сборку управляющих запросов из отдельных транзакций. После сборки сообщения , передаётся первому автомату и служит событием, которое может изменить его состояние. Когда смоделировать поведение устройства оказывается затруднительным одним автоматом, то оказывается просто смоделировать несколькими конечными автоматами, взаимодействующими друг с другом передачей сообщений.




Но при ближайшем рассмотрении выяснилось, что обработку управляющих запросов от хоста невозможно представить одним конечным автоматом. Схема сложней. После выполнения транзакции SETUP нужно раскодировать конфигурационный пакет. По результатам расшифровки выбирается один из некоторого множества конечных автоматов, отражающий запрос. Ниже граф переходов для запроса GET_DESCRIPTOR c несколькими стадиями данных. Транзакции выполняются аппаратурой автоматически, по результатам выполнения выставляют флаги. Хост инициирует тр. setup, из сост. I переходит в S, готовит буфер USB для следующей транзакции от хоста и т.д.

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

И ещё вопрос для специалистов. Могут ли быть вложенными управляющие передачи? Например, началась передача setup и не завершая её хост начинает новую? Из разных источников разные ответы, по-моему полная ерунда. То что хост может внезапно закончить начатаю передачу, это знаю. А вот вложенные передачи? Тогда нужно складывать контекст. Да и какой максимальный уровень вложенности? В "USB complete" написано что вроде как могут быть вложенные.

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

покурите библиотеки libopencm3, unicore-mx (клон) - может и не понадобится вам пилить свою обертку

Я попрошу Вас, как модератора, не флудить в ветке! Вы не одного поста по теме не написали... Как обычно, в прочем.


Заблуждаетесь. Совершенно один конечный автомат.
У меня описан вот так:



На чем я учился - во вложении.
Вложенных передач нет. Есть стэйт машина, любой шаг влево-вправо - сброс.

Есть книга:
Михаил Гук. Шины PCI, USB и FireWare
В ней хорошо описана работа USB.

В конечном счете примерная схема взаимодействия (у меня):
Обязанности драйвера USb периферии:
1. Обеспечение инициализации периферии USB устройства. Сюда не входит инициализация тактовых частот и портов ВВ. Этим занимаются целевые драйвера МК.
2. Обеспечение отключения периферии USB.
3. Обеспечить подключение устройства к шине. В основном это возможность отключить/подключить встроенный пулл-ап резистор (если имеется) и дополнительная инициализация модуля USB-
устройства (если требуется).
4. Вызов библиотеки верхнего уровня (для энумерации устройства и специфичных для класса вызовов) через ТРИ вызова (SETUP, DATA IN, DATA OUT).
5. Предоставлениеотдельного интерфейса для ЕР0.
4. Обеспечить корректную установку адреса устройства. В разных семействах МК есть нюансы при установке адреса устройства.
4. Предоставление приложению интерфейса прямого ввода вывода через конечную ЕР.
5. Возможность, если требуется, дополнительных обработчиков типа Resume, Suspend и т.п. и связи их с приложением.

Обязанности библиотеки:
1. Надежная стэйтмашина через три вызова от драйвера (SETUP, DATA IN, DATA OUT).
2. Возможность подключения обработчиков запросов от специфических классов.

Это не стек. Это няшные хидеры

Лучше всего все описано в документе usb_20.pdf который скачивается с сайта usb.org. В главе 9 машина состояний во всех подробностях, а в главе 8 ответы на вопросы про то как осуществляется передача данных.

В своё время интересовался USB , даже опубликовал результат своих изысканий
https://yadi.sk/i/kQfoeUJ8iicDi
Чем плохи доки по стандартам? Они объективно очень громоздки в силу их специфики, там предусматриваются все варианты событий, какие только возможны. Например если смотреть стандарт по HID, то умопомрачительно, а кто знает, что такое custom hid (наиболее используемый на практике), тот рассмеётся. На практике можно многое отбросить, скостить углы.
Основу моего проекта составляют идеи предоставленные здесь:
http://mcu.goodboard.ru/viewtopic.php?id=40
Может модератор не удалит сей ценный материал?

Вы идете совершенно неэффективным путем.
Если нужен эталон как правильно писать под USB в embedded то всегда смотрят у Micrium-а.
Он делает исходники специально так чтобы начинающие могли легче понять как все внутри устроено.
И только у Micrium-а документация действительно объясняет как работает их софт.
Нажмите для просмотра прикрепленного файла
Диаграмма выше как бы намекает, что вам до своего "драйвера USB" как до луны.

Нажмите для просмотра прикрепленного файла
А эта диаграмма показывает слои.
У Micrium-а драйверы действительно являются драйверами.
И как видно драйвер у них это даже не половина дела.

Справок где берут Micrium USB, документацию на него и какая у него лицензия не даю.

За информацию и отклики благодарен всем, рискну выложить схему реализации, может кто-нибудь ещё подкинет идей.

В цикле мониторятся флаги событий. GLOBAL_SM - мониторит RESET, SUSPEND и пр. Группа TRN_SM собирает из отдельных транзакций запросы управления, мониторит флаги транзакций передач управления. После транзакции setup, выполняется парсинг пакета конфигурации (выделено голубым), остальные секции не реагируют, состояние автомата фиксируется в глобальных переменных. По транзакции IN выполняется соответственная секция кода, состояние фиксируется в гл. переменных. Транзакция setup общая для всех передач управления, а дальнейшая реализация зависит от парсинга конфигурационного пакета из этой самой транзакции setup. В секции setup устанавливается указатель на функцию реализующую конкретный запрос и далее эта функция вызывается каждый раз при выполнении последующих транзакций пока запрос не закончится выполняться. Думаю схема ясна. Обработчик транзакций передачи данных прост, по сравнению с управляющими, поэтому пока не рассматривается