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

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 были куплены эксклюзивные права вместе с поддержкой-сопровождением одной не нашей конторой, которая с ней выпускает девайсы тиражем несколько десятков тысяч в год (видимо на каждом углу у них не получилось найти ), так что вопрос продаж меня совсем не волнует, уж поверьте...

Сообщение отредактировал Шаманъ - Aug 7 2017, 18:36

И ещё вопрос для специалистов. Могут ли быть вложенными управляющие передачи? Например, началась передача 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. Возможность подключения обработчиков запросов от специфических классов.

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